Navigating the Maze of Production Machine Learning | Miguel Otero Pedrido

The transcripts are edited for clarity, sometimes with AI. If you notice any incorrect information, let us know.

Miguel’s path from physics to production ML

Alexey: I'm interested in why we should care about production machine learning when everyone is talking about AI. Should we even care about it? That's one thing I plan to ask. We'll talk about interesting things related to this topic. You've probably seen Miguel on LinkedIn. (0:10)

Alexey: That's how I regularly see him, always wearing headphones, including today. He's an ML/AI engineer who learns and teaches by building. He went from studying spacetime curvature and quantum field theory—it's difficult even to articulate, which reflects the complexity of the subject— (0:32)

Alexey: to creating real-world ML systems, from fashion recommendation engines to complex agentic workflows for insurance companies. I already have a question: doesn't that feel like downshifting? (0:57)

Miguel: It's different. Maybe mathematically it's a downshift, but in terms of contact with reality, it feels like an upgrade. I love physics; that's why I studied it. But things change when you get into research. I was researching gravitation, spacetime curvature and quantum field theory. (1:10)

Miguel: They're beautiful theories if you enjoy the mathematics behind them. I wouldn't call this a downshift. Now I have the pleasure of building systems that affect thousands, tens of thousands or even millions of people at the companies I work for. That's a good feeling in a different sense. Before, I was learning, understanding or developing theories, but it felt different. (1:52)

Miguel: They're very different worlds. Mathematics was helpful when I started in this field, but also a big disadvantage. You tend to focus on the mathematics behind models and algorithms and forget about solving the actual problem. (2:28)

Alexey: I was guilty of that too, because the theory is interesting. I remember learning support vector machines; they have a beautiful foundation. Did you find that nobody really cares about support vector machines? (2:52)

Miguel: Absolutely. I relate to that because it happened to me. When I started with random forests and XGBoost, I wanted to dive into each algorithm's mathematical foundations. Ten years ago, you wanted to find a problem where you could apply SVMs or neural networks. Then the numbers and evaluations told you a simple linear regression was enough. (3:04)

Miguel: It was a huge disappointment, and you tried to justify using more complex mathematical models. I relate to that experience and feeling. (3:44)

Alexey: You went from physics to machine learning. What do you do now, and what is The Neural Maze? (3:55)

Miguel: I have two jobs. During the day I'm a machine learning engineer, but increasingly an AI engineer. I work for Zapier, a company focused on automations and workflows, which is evolving into an AI-first company. (4:01)

Alexey: I've used Zapier for quite some time. It's very simple. (4:30)

Miguel: That's what we try to achieve. With the AI features we're adding, we hope to make it even simpler. I'm on Zapier's AI platform team, behind the AI functionality and features appearing progressively in the product. That's my first job. The second is The Neural Maze, an educational brand I created two years ago. (4:36)

Miguel: Through The Neural Maze, on YouTube, primarily on LinkedIn, and on Substack, where I have a newsletter, I teach AI. I teach production AI that tutorials, videos and courses often skip. I try to distill what I've learned from ten years deploying AI systems to production, from machine learning to agentic systems and many other systems. I want to give subscribers and the community knowledge I don't often see in tutorials. (5:06)

Alexey: I found your YouTube channel and shared it in the live chat. I also linked it in the title. If you're interested, please subscribe. As a fellow educator and teacher, I really like this path. (5:50)

Alexey: You do something during the day, then share everything you learn with people. How do you find time for it? (6:19)

Miguel: It's been a rough two years, honestly. I guess at some point I'll need to make a final decision. (6:34)

Alexey: I did that three and a half years ago. I think it’s more now. (6:41)

Miguel: Even with AI, agents and the promise of productivity, a personal brand still needs a human being. That’s why I can’t multiply myself yet. (6:45)

Miguel: That's the problem with time. I work a lot, and I hope in the coming years I can reduce the workload a little. (7:00)

Why traditional machine learning still matters

Alexey: Agents are certainly helpful. My first question about production ML systems is: why should we care about ML when everything is generative AI? You throw a problem at AI and it figures it out. Why care about machine learning these days? (7:25)

Miguel: Sometimes, when we learn a new tool or technique, we overestimate its capabilities. AI and agents are amazing tools that solve many use cases. But many problems could be solved by traditional machine learning algorithms at a lower cost. Recommender systems are a good example. (7:41)

Miguel: I've worked on recommender systems for five or six years. Some teams default to agents or give recommendations to an LLM system. But when you compare benchmarks, simple matrix factorization or a learning-to-rank algorithm using gradient-boosted trees can outperform LLMs. You also get determinism that you don't get with agents and LLMs, although models such as Jev can now achieve something similar. (8:15)

Miguel: Sometimes I think Jev is amazing because it provides zero hallucinations and probabilities for each category. But we also got that from logistic regression or random forests. (9:07)

Alexey: I was surprised by the attention Jev got. I thought, 'Wait, it's just a classifier.' (9:26)

Miguel: That's my point too. It's amazing they're getting this through a new reinforcement-learning approach. People are amazed you can use Jev as a router instead of an LLM. You could do the same with a random forest or another classifier. It's funny how we rediscover these things. (9:33)

Alexey: Exactly. (10:01)

Miguel: Sometimes we default to the tools we know. Machine learning still offers techniques that might be the best default solution. You may later discover that a complex agentic system solves your use case. But I'd start with machine learning systems. (10:07)

Miguel: A chatbot isn't that kind of machine learning use case. But for a classifier, recommender or credit-default system, I wouldn't default to an LLM. There are libraries and implemented algorithms we know work and give good results in companies. I'd start with a machine learning algorithm, even if only as a benchmark. (10:31)

Miguel: If it's not enough, move to something more complex. People sometimes start with the most complex idea; I take the opposite approach. Maybe it's the physicist's mind, starting with spherical cows instead of a real cow. I like starting with the simplest solution, even a heuristic. If it solves the use case, use it rather than jumping to a multi-agent system with context engineering. (11:09)

Alexey: Did you read Netflix's article about moving its recommender system to an LLM? I was surprised. Recommenders seemed like an area where using an LLM didn't make sense, but it looks like it does. (11:46)

Miguel: That's a good example. They've created a foundation-model approach, which might suit Netflix because of its huge data volumes. Starting a recommender from scratch, it's difficult to find these approaches outperforming matrix factorization. Running it in a Jupyter notebook is also very different from production. In the lab, an LLM approach might outperform matrix factorization, but deploying it will probably be much more expensive. (12:06)

Miguel: The uplift in your metrics may not even justify it. That's something I consider when making these decisions. (13:09)

Starting a recommender system without data

Alexey: Suppose we open an online shoe store and need a recommender system. What do we do? (13:28)

Miguel: First, you need data. Without any data, I'd probably start with heuristics such as bestsellers. (13:33)

Alexey: It's a brand-new store; we've just opened. (13:44)

Miguel: Then I'd probably start with a content-based approach. It's better for the cold-start problem when you have no data. You get information from users, such as gender, age or color preferences, and assign similar attributes to items. Then you match user attributes with item attributes. That's a content-based algorithm. (13:49)

Alexey: Does it work that well? Isn't it basically using search? (14:22)

Miguel: That's it. It works well for cold starts when you have no information. As traffic grows, users interact with items. You can start collaborative filtering, of which matrix factorization is one example. You use the collaborative information from different users' interactions with items. (14:29)

Miguel: You represent each user and item in the same embedding or vector space and find which users are closest to which items. Users and items become embeddings representing preferences as vectors. I'd begin with content-based recommendations, then move to a collaborative approach, probably simple matrix factorization with implicit feedback. (15:02)

Miguel: If I had to choose, I'd probably use reinforcement learning with contextual bandits. It works well for recommender systems, because you can add randomness. One problem is the echo chamber: you send recommendations, the user clicks them, and the model takes those clicks as the actual preference when it retrains. (15:43)

Alexey: You influence the behavior. (16:24)

Miguel: You influence it, and it starts deteriorating. You never show the user anything serendipitous or new; you put them in an echo chamber. Contextual bandits are useful because you can add randomness. Even if one bandit recommends based on preferences, randomness can surprise users with new items. (16:32)

Miguel: You explore the space. It's the exploration-versus-exploitation tradeoff. That's what you achieve with these systems. (17:07)

Contextual bandits and feedback

Alexey: Could you explain contextual bandits a little more? Maybe start with ordinary bandits, then contextual ones, so we know what to look up to learn about them. (17:17)

Miguel: I'd start with basic reinforcement learning. You don't need advanced techniques. You could start with Thompson sampling, which I typically use. You're balancing exploration and exploitation. Contextual bandits don't select items randomly without context. (17:38)

Miguel: They have context—that's the name. The context includes features of the user and items, plus the user's recent search history. You put that information into the contextual bandit and recommend based on it. (18:16)

Miguel: Then there's another bandit that's completely random. Imagine two boxes. To generate a recommendation, one box might be a random forest that ranks items, while another contains a random model. There's a probability of the recommendation going through either box. (18:53)

Miguel: If it goes through the first box, the recommendation comes from the random forest using the user's features. Through the other, it's random. You could create as many boxes as you want: one based on recent activity, another on bestsellers for a particular gender. You can combine them. (19:16)

Miguel: Contextual bandits learn the probability of sending each user's recommendation through these different bandits. You get that in real time, which is cool. (19:48)

Alexey: I was recently a victim of this on Twitter. Suddenly I saw Manchester United tweets, although I'm not interested in football. You mentioned context: perhaps it assumed that because I'm male, and football is popular, there was a chance I'd be interested. (20:07)

Alexey: Twitter started showing those tweets to see how I'd react. (20:32)

Miguel: That's it. It's difficult to learn human reactions because, if we don't like something, we usually scroll past rather than explicitly give thumbs-up or thumbs-down feedback. That's important for people building recommenders. You mostly get implicit feedback, such as scrolling past or clicking and going back. (20:40)

Miguel: Implicit feedback can be hard to measure, but there's much more of it than explicit feedback. I don't usually click thumbs down. If I like something, I click thumbs up. (21:05)

Alexey: In my case, there were too many Manchester United tweets. I wondered what was happening because I didn't want them. First I scrolled past, then decided it was enough and used 'don't show more.' (21:26)

Miguel: Absolutely. YouTube does this too, mixing new things into the feed. Twitter recently released its algorithm. I think it also uses an LLM to rank the feed. (21:51)

Alexey: It uses one for ranking the feed? (22:09)

The four-stage recommender architecture

Miguel: Yes, for ranking. It's not a bad decision. Production recommender systems typically follow a four-stage design. First is candidate generation, with algorithms such as matrix factorization or word2vec. (22:15)

Miguel: NLP models can also work well. If you're following a user's session and predicting the next item, they work well. These cheap algorithms generate candidates. You don't expect highly accurate recommendations at that stage; you might want ten candidates from each model and a hundred candidates overall. (22:51)

Miguel: That's candidate generation. Next is filtering. There may be duplicates, so you remove them. If we're recommending movies to a teenager, some contain violence and need removing. You filter the candidates. (23:27)

Miguel: Filtered candidates go to the ranking step, connecting to what you said about Twitter. The ranker needs to be slower than candidate generation but much better in results. It sorts the candidates into an accurate list to show the user. That's where LLMs might fit. In my experiments, gradient-boosted trees often work better for learning to rank. (23:57)

Miguel: This isn't regression or classification; it's a learning-to-rank task with a different objective function. A traditional neural network or LLM transformer might be legitimate here. The ranking stage's objective is the most accurate ranking. (24:59)

Miguel: The fourth stage is the business layer. The business may want to put certain items at the top because they're on promotion. That final layer can change the ordering the ranking model produced. (25:36)

Where LLMs help recommender systems

Alexey: Back to the new shoe store. You suggested a questionnaire for the cold-start problem: users fill it in, and we show recommendations. Would using an LLM there make sense? (26:04)

Alexey: When I ask for points of interest, LLMs can be good at recommendations. In Shanghai, for example, they know places from general knowledge. Could that general knowledge be enough? Is it too slow or expensive? How do we decide whether to take that route? (26:28)

Miguel: That relates to Zapier's recommender. The homepage recommends workflows based on your history, using a traditional recommender model. We considered cheap LLMs, such as the new Qwen family, with useful features and local hosting. In that case, we wouldn't have the same issues around customer data or PII. (27:02)

Miguel: It could fit, but cost remains a problem, and the output isn't guaranteed. Even with RAG or fine-tuning, you can't guarantee the output is in the catalog. You need many checks and tests. I think LLMs are useful for two things in recommenders. The first is synthetic data. (27:38)

Miguel: The second is natural-language explanations of recommendations. That's how we use them, and I like that LLM or agent layer. It can recommend shoes and explain that you liked similar shoes two weeks ago or looked at related boots. (28:11)

Alexey: With collaborative filtering, we get a vector without knowing what's in it. The LLM can look at the history and make sense of it. (28:50)

Miguel: Exactly. It could look at the vectors, with metadata, and explain why something was recommended. Recommendations are useful, but understanding them improves the service. People want to know why. (29:02)

Alexey: Back to the shoe example: suppose I'm not technical and ask Claude to build a recommender. Would it know enough to follow your approach? Have you experimented with that? (29:28)

Miguel: I think it would do a good job. It gives sensible results and approximations, and I think it would help you see that you need to start simpler. If you explain that you have no data, it's aware of cold starts, content-based approaches, collaborative-filtering tradeoffs and the four-stage design. (30:00)

Miguel: For deployment and services talking to one another, I'm not sure it would do it perfectly. But for the actual plan, you'd get decent results. (30:40)

System design, foundations and comprehension debt

Alexey: Does that mean we don't need ML engineers anymore? (30:55)

Miguel: We still need them for design. The strength of a machine learning engineer isn't implementing scikit-learn or PyTorch anymore. It's similar for AI engineers: ask Claude for a RAG system, and it can create one from scratch. For both roles, the strength is system design. (31:02)

Miguel: Even with a four-stage blueprint, you need to decide where to deploy it, how to use candidate generation and reranking, and whether it should be streaming or batch. Those decisions still belong to the ML engineer. Whether to use agent memory, RAG or an LLM wiki belongs to the AI engineer designing the system. My response would have been different three years ago. (31:37)

Alexey: Maybe even six months ago. Even with Opus or Astra, their choices can be questionable. Sometimes they make very suboptimal decisions because they lack the big picture. Using a PyTorch model doesn't make sense if a heuristic is enough. (32:30)

Miguel: Absolutely. Sometimes it's our fault because we didn't provide the context. I like 'questionable,' because that's the value of AI system-design engineers: they design systems their agents implement. It's more important than ever to know system design and question what new models output. (33:18)

Miguel: You need to question it and request another implementation. If you passively accept everything an LLM produces, then ML engineers aren't needed anymore. (34:11)

Alexey: We teach ML Zoomcamp, an introduction to machine learning engineering. It's the sixth cohort, and I haven't fundamentally changed the content since the first. Scikit-learn from five years ago is still scikit-learn today; Kubernetes is still Kubernetes. People remain interested in the course and learning the theory. (34:29)

Alexey: Is it still relevant? Do I still need to understand logistic regression or tree-based models? Is learning these things important for ML engineers? (34:59)

Miguel: For me, foundations matter. AI is good at getting from A to B much faster, but not at defining A and B. I tell it what those points are and how I want to get there. It implements that efficiently, perhaps in an hour rather than two weeks. (35:20)

Miguel: My decisions depend on solid foundations in those things. I know when logistic regression is needed and when it's enough, so I don't need a random forest. I could ask Claude, but there's comprehension debt: how much decision-making are you willing to delegate to an agent rather than understand yourself? (36:07)

Alexey: The system works, but I have no idea how. (36:52)

Miguel: Exactly. If it fails, you could ask the model what to do. But you lose the big picture and overfit to the system by asking Claude for changes. You keep evolving a system you didn't understand initially, and comprehension debt grows. People may say an agent will fix it, but eventually it will explode. (36:58)

Miguel: You built a crazy neural network with custom losses because Claude told you to, although a simple scikit-learn logistic-regression import could achieve the same. I think your cohort is useful, and I understand why people want these courses. (37:32)

Alexey: An example outside ML: I get an AWS bill that's twice last month's. Agents decided on a large Postgres instance when serverless DynamoDB was enough. Now I'm paying three hundred a month. Sometimes it's useful to let them explore the direction I want, (38:03)

Alexey: but their route isn't necessarily a straight line. You can fly from Berlin to Munich, which is fast but expensive and involves waiting. Or take a train with less hassle and lower cost, even if it takes thirty minutes longer. (38:46)

Miguel: I fully agree. (39:22)

The changing ML and AI engineering roles

Alexey: I don't think these cohorts are going away. Sponsors aren't interested in ML engineering because it isn't a hot AI topic. They won't sponsor the course, but I keep it because it's close to my heart. Looking at what the market wants, VC money is driving the current interest in AI. You also work as an AI engineer. (39:31)

Alexey: How was that transition? Did you wake up one day and realize you were an AI engineer? (40:31)

Miguel: It was gradual and incremental. I never thought 'AI engineer' was a very good term. What's the difference from a machine learning engineer? People typically say AI engineers build applications on pretrained foundation models, while ML engineers focus on feature pipelines and training models. (40:45)

Alexey: That's the distinction I make too. (41:32)

Miguel: Once an ML engineer deploys a model, the role becomes similar to AI engineering. I could fine-tune an LLM and deploy it through an inference server. My transition was easy because I didn't encounter something fundamentally different. AI engineers tend to be software engineers entering the AI ecosystem by using AI tools. If you don't know about training and fine-tuning models, I wouldn't call you an AI engineer. (41:38)

Miguel: You're a software engineer with some AI sparkles. That's what I teach through The Neural Maze newsletter. Eventually AI will become a commodity, like DynamoDB or Postgres. We don't understand all the algorithms Postgres uses underneath. Eventually developers won't understand how Pinecone works underneath either. (42:20)

Miguel: If you don't know how to fine-tune models today, I'm not sure that qualifies as AI engineering. To me, it's software engineering with new tools. (43:22)

Alexey: I have some data points. Every month I scrape AI-engineer job descriptions across the US, UK, Netherlands, Germany and India. I have nine months of data and see a downward trend in PyTorch requirements. Early in the year, forty percent or more of companies required it; now it's below thirty percent. The market seems to be moving toward the software-engineering definition, rather than ML engineers who train models. (43:40)

Miguel: You're probably right. Two years ago I was more in the ML-engineering role; now I'm more in AI engineering. At Zapier we're fine-tuning models and creating a semantic router. I think that's AI engineering, even though fine-tuning is also ML engineering. (44:43)

Alexey: For me, AI engineering is having a model, making requests and handling everything around it, such as evaluation and monitoring. That's what you call software engineering in AI. (45:18)

Miguel: I think that definition is right. But there are discrepancies. Chip Huyen's AI Engineering book includes fine-tuning and RAG in the discipline. It's difficult for me to distinguish the two now. (45:33)

Alexey: We'll see how it evolves when the dust settles in a year. (46:05)

Miguel: When people ask why my title is ML/AI engineer, I say deploying logistic regression or a fine-tuned LLM to production isn't different for me. I'm deploying AI systems, whether they're classification models or LLMs. That's how I see myself. (46:17)

Trace redaction and the AI gateway at Zapier

Alexey: What AI engineering work do you do? You mentioned fine-tuning and semantic routing. Could you describe your day-to-day work? (46:58)

Miguel: I've spent a month on AI-evaluation strategy and observability. One big observability challenge isn't collecting traces with OpenTelemetry. We spent time defining how to collect traces from different services. Once they land in Databricks, you need PII redaction before treating them and fine-tuning models. You have to ensure they're redacted and contain no customer data. (47:40)

Alexey: I assume Zapier has a lot of that. (48:13)

Miguel: It's a challenging but beautiful problem. We create a model, not an LLM, to process and redact traces almost in real time. Zapier users generate around twenty million trace spans per day. For a month, I've been creating a pipeline to fetch raw traces containing customer PII and redact it into a schema engineers can use safely. (48:22)

Miguel: I've also worked on the AI gateway. Zapier uses many LLMs, so we need a common layer for semantic routing. The gateway sends requests to different models through the same interface. We have an abstract representation of Opus, with fallbacks to Azure, Amazon, GCP or Vertex. It's similar to LiteLLM, with an AI gateway and semantic routing. (49:14)

Miguel: Semantic routing matters for cost. You can use BERT or another light model to classify requests and send them to the most suitable model. People think every question deserves a heavy LLM, but that's not true. Routing decides whether a smaller model can handle it. It's a challenging, interesting project we're doing. (49:59)

Miguel: The main projects are the AI gateway with semantic routing, and AI observability for evaluations. We'll use an approach similar to Hamel Husain's error analysis. (50:48)

Error analysis and evaluation of agent traces

Alexey: Could you walk through that error-analysis approach? (51:19)

Miguel: It's simple. Hamel called it 'the revenge of the data scientist,' because you apply a data scientist's mindset to traces. They're not just data you collect; you can analyze and cluster them to extract information and evaluate the system. You manually or automatically annotate traces to check how the agent performed. (51:24)

Miguel: Did it fail or hallucinate? Then you cluster traces into error groups with common patterns that make the agent fail. (52:16)

Alexey: Do you ask an LLM to cluster them, or is there a specific approach? We want a concise evaluation data set because each row costs money to evaluate. Rather than including every error, we want a representative sample. Is the idea to take one representative example from each cluster? (52:37)

Miguel: Basically, yes. You have a paradigmatic example representing the cluster. If the cluster is represented by vectors, it would be the average of those vectors. (53:19)

Alexey: Do we use something like k-means? (53:37)

Miguel: You could use k-means with numeric metrics, such as hallucination scores or counts of failed tool calls. Represent traces as numeric vectors and create a cluster center. Then decide which clusters to address. (53:42)

Alexey: For each trace, you run evaluations and get data. You're clustering the judge's results, rather than the traces themselves? (54:08)

Miguel: Exactly. You've annotated a representative sample; you can't annotate millions of traces. You run clustering based on those annotations. (54:22)

Alexey: This 'revenge of the data scientist' uses techniques we've known for years. They've become useful in AI-engineering work. (54:40)

Miguel: Absolutely. It needs critical thinking about agent performance. With traditional ML, it wasn't easy to fool the engineer building it: poor linear-regression metrics were easy to spot. Agentic systems give plausible responses and try to cheat you. (54:51)

Miguel: They give something that looks nearly right but isn't. We need to spend most of our time understanding and applying evaluations. That's where the effort belongs. (55:34)

Alexey: Krishna asks if we could categorize traces using a decision model. I'd rephrase that as: have you tried something like Jev? (56:01)

Miguel: I haven't, but it's not a bad idea. (56:17)

Alexey: It's fast. With multiple judges, I'd need a separate LLM call for each, but Jev lets me put everything in one place. Instead of five calls, I have one, which is faster and cheaper. The results align perfectly. (56:24)

Miguel: That's cool. I need to try it. (56:53)

Semantic routing and model-cost tradeoffs

Alexey: You mentioned BERT for semantic routing in the AI gateway. On Zapier's page, the copilot says to enter an idea. There's no model selector. Is your system choosing the model underneath based on the problem? (56:58)

Miguel: Copilot is one product. I'm talking about a new product we're releasing, Sidekick. That's where semantic routing will be applied, although it could apply here too. As you type, it'll check the message and, with very low latency, identify which model to route the question to. (57:30)

Alexey: Does BERT still make sense for this, rather than a decision model? Is taking a fast, open-source decision model easier than training BERT yourself? (58:00)

Miguel: If you want to reach production quickly, decision models are a good example and justified here. But with millions of requests, a specialized BERT model optimized in a Rust framework such as Candle can cut costs heavily. For a transformer tasked just with detecting a category, I'd take that approach to reduce cost. (58:33)

Miguel: vLLM released vLLM Router. I believe its first version used BERT as a classifier with Candle. In the long term, I'd probably use that kind of custom deployment because it reduces costs, even compared with cheap decision models. (59:48)

Alexey: At the beginning, you could use Laya, a Jev alternative you can self-host, although it needs bigger hardware and a larger GPU and will be slower. Once deployed, collect the logs and train a new BERT model on those predictions. Then it's a hundred times faster and cheaper. (1:00:05)

Miguel: I like that approach; it's what I typically do. Foundation models can provide answers that previously needed manual annotation. From day one, we can give customers a solution that works reasonably well, then distill that knowledge into our own model. (1:00:44)

Alexey: Let's wrap up. I checked your Substack at theneuralmaze.com, linked your YouTube channel and shared it in the live chat. Where else can people find you? Are you on X? (1:01:28)

Miguel: I'm on X as Miguel. LinkedIn is the best place to reach me. Send a message, and I'll reply. (1:02:01)

Alexey: Are those the same headphones as in your LinkedIn picture? (1:02:19)

Miguel: Yes. I'm attached to them. Other creators joke that I might not have ears because they've never seen me without headphones. (1:02:24)

Alexey: Can you show us your ears? (1:02:46)

Miguel: I can. (1:02:46)

Alexey: Thanks for joining us and sharing your experience and knowledge, Miguel. I enjoyed this episode. Thanks to everyone for joining and asking questions. It was a lovely discussion, and I had fun. (1:02:52)

Miguel: Me too. (1:03:09)

Alexey: Have a great week, Miguel and everyone watching. See you around. Goodbye. (1:03:15)