Podcast: Educating an Architect: A Conversation with Luca Mezzalira

InfoQ Homepage Podcasts Educating an Architect: A Conversation with Luca Mezzalira

In this podcast, Michael Stiefel spoke to Luca Mezzalira about software architecture as a socio-technical discipline that balances technological design with an organization's social and managerial context. They explored how architectural choices must be adapted to a company's unique culture and team structure rather than relying blindly on universal best practices, noting that friction within a system serves as critical feedback regarding team and technical alignment. Since placing a dedicated architect on every team is unworkable, the discussion highlighted a shift toward an enablement mindset. Architects should be encouraged to act as coaches who empower developers to make decentralized decisions by establishing clear system guardrails and architectural fitness functions.

The best of architectural education comes from collaborative study and shared experiences rather than traditional lectures, allowing knowledge to organically evolve over time. As AI is increasingly used within systems, the architect must identify the areas of high volatility that require the careful supervision and guidance of experienced engineers, and the generic domains where delegation to AI agents can be more safely done.

Play episode Play Related Sponsors Related Sponsor December 15–16, 2026. Examine how senior practitioners run agents, evals, model serving, and AI-assisted engineering in production, including what failed and what changed. Register Now.

Michael Stiefel: Welcome to The Architects Podcast where we discuss what it means to be an architect and how architects actually do their job. Today's guest is Luca Mezzalira, who has spent over 20 years helping engineering organizations make architectural decisions that shape how their teams work and systems scale for years to come. At DAZN as Vice President of Architecture, he led the migration to microservices and micro-frontends at streaming scale.

At AWS, he worked directly with some of the world's largest organizations as their architecture expert, running the EMEA go-to-market strategy for serverless, delivering over a dozen talks at re:Invent and leading whiteboard sessions, event storming and distributed systems design across retail, travel, finance, insurance, media, energy, healthcare, and the public sector.

Many years were spent developing micro-frontends from a nascent idea into a discipline through research, experimentation, leading up to an O'Reilly book aimed at serious teams. Hundreds of organizations worldwide were aided in modernizing and scaling their web and mobile applications with micro-frontends because of his efforts. He has delivered over 350 sessions at many conferences throughout the world. Currently, he facilitates the QCon InfoQ architecture cohorts where practitioners learn how to navigate modern architecture. He is the voice behind the Token by Token Newsletter, the Dear Architects Podcast and the Micro-Frontends newsletter.

His obsession, to use his own words, is taking the hardest architecture concepts and making them impossible to misunderstand. It's great to have you here on the podcast. And I'd like to start out by asking you, were you trained as an architect? How did you become an architect? It's not like you decided one morning you got up, you got out of bed and said, "Today I'm going to be an architect".

Luca Mezzalira: Yes, absolutely. So first of all, thank you very much for the introduction and thank you for having me on this podcast. Definitely you don't wake up and you become an architect, despite I wish it was that easy. I think it's a natural evolution of the engineering role, at least in my time. We didn't have all these different titles, fancy titles that are nowadays in the tech industry. Therefore, the path was fairly well-defined. Either you move into management or you sharpen your soul and you become better and better and better, start to abstract yourself and start to see more problems, more challenges, and so on and so forth.

So I decided to go with the ladder even though a good chunk of my career was also in management, but always keeping an eye on the tech side because even when I was VP of architecture in DAZN, I was very clear with my CTO saying, "Listen, I'm still designing things. I'm still working with the engineers". And in fact, I spent a lot of time even doing pair programming back in the days with engineers despite their view of architecture because the reality is I like solving problems. It doesn't matter at which level the problem is. If I can help out and quickly, let's say pull all my experience to move the needle, I would do that. So therefore for me it was important.

So how I became an architect, what I realized during the years is that the part that I love the most while I was an engineer, it was the refactoring part, mainly because I like a lot, let's say understanding how people implemented something, trying to crystallize in my head if that was a good decision for the situation we were at the very moment, more than six months ago or a year ago. And then I loved at the beginning of a greenfield project, spending time designing, understanding the business problem, understanding the context where I was operating.

And then I discovered over the years reading a lot of books that that wasn't something accidental that I was doing. It was a clear path towards architecture and designing systems that slowly but steadily became my profession. But with some bumps I would say, because as you can imagine, there is a period of your time where you are not an architect, you would like to be an architect, but you are not in the right rooms and you're not talking with the right people. And therefore I created this approach where I was designing on my own and trying to solve the problems that other teams have and trying to see if my ideas were, let's say, similar to what the architects were doing back in the day.

But also being invited or basically asking, begging the architects to be invited to their meetings to understand how they were talking, how they were thinking, basically stealing their secrets to a certain extent. And that helped because obviously after several months I started to give my two cents, people started to pick it up. And so I say, "Hey, it's not a bad idea. What you're saying is a good perspective". And slowly but steadily I entered that role of architect, but I have to say, I don't believe I needed the title for doing the job because even before as a principal engineer, I designed a lot of systems. I designed a massive modernization of a gambling company where I was working.

I was a tech leader of a real money gambling department with hundreds of people in a company called Gamesys that then was acquired in the last few years in London. And there basically I was able to convince the CTO and the architect and my colleagues to migrate to a more, let's say simpler framework for building gambling games. So we moved from nine months to three months for each single game. The morale of the team started to rise a lot. They started to push a lot. There were a lot of benefits of this approach and that was a very nice challenge that I face from the socio-technical aspect. Because before that, I spent a lot of time as a consultant at a company in Italy.

I was a CTO and there basically we helped companies to simplify their integration with ERPs and with crazy projects like working on a Ducati motorbike dashboard or working on a soda dispenser display, stuff like that. So we had these two things that we were pretty good at, the integrations and also let's say embedded devices that were unique deals back in the days in Italy.

Michael Stiefel: That's interesting for two reasons. One, when you mentioned stealing ideas, you recall to me the famous quote of Picasso that says, "Mediocre artist copy, great artist steal".

Luca Mezzalira: Absolutely. That's my mantra.

Michael Stiefel: This also brings to mind because in order to steal something as opposed to just copy something, you actually really have to understand. One of the things I found is that there are many people who are developers and have this idea that the next natural place to go is architecture, which can be false because as we know, there are many other paths, but also the personality of an architect is very different from the personality of the developer. Developers very often have to be very, very careful.

You build a table, if one of the legs on the table is not strong, you can still use the table. But in the software analogy, if one of those legs is not strong enough, you can get into a lot of trouble. How do you change your personality or develop a more broader perspective when you move from developer to architect?

Luca Mezzalira: To be honest, there was a big realization for me that architecture wasn't mainly being the most technical person in the room, more than that being the person that tried to balance the discussion and the decisions that we were making inside the socio-technical system. I tried to stress out this idea of socio-technical system because I think the main community that is currently talking about this is the domain-driven design community more than others because we realized that we are not designing architecture for the sake of technical reason. We are designing for the organization communication structure as Conway's law suggested.

The challenge in general is that when you are a developer, you can go very vertical. I remember back in the days that we didn't have fancy titles like distinguished engineers. There were other principal engineers, in some companies, senior, and there you can find amazing minds.

But some of them were extremely good at their craft, which was writing code.

They didn't want to go around the company, speak with product managers, speak with developers, speak with other teams. They were masters of their craft and they were capable of writing the most impressive C program that works like a charm in any device or they were capable of doing things that other human beings didn't even expect that they were capable of doing. While this role was more looking holistically on the problem space that is not merely the technical one, but also is the social one.

For me, that realization completely changed the way I see technology. Back in the days, I tried to be the most technical one. I really deep dive into several things, let's say at the very low level.

I was doing things that other engineers were incapable of because working in embedded systems is now a walk in the park, every bite counts, every line of code counts.

So you need to put a lot of effort and trial and error. While as an architect, I found extremely fascinating this idea of speeding up things. So how can I design a system that enables others to succeed and to become a better version of themselves? And that was for me very interesting because behind that there was a challenge that lies behind, if you want bureaucracy, different lines of business and different layers inside an organization. And I found this part extremely fascinating because no one wanted to do that, let's say, bothering all these people in order to align them and having... I thought, you know what? If I know what I want to express technically, I cannot express it because probably people either don't understand or don't know that these things could be interesting.

Then many people, every time that I did big things in architecture, they always told me, "Why do you bother? At the end of the day, they are paying you no matter what". But for me, it was the challenge that was very interesting, not the technical implementation, whatever. The challenge of convincing everyone and aligning everyone that we might be in a better place if we do X, Y, Z. And that for me was the reason why I became an architect slowly but steadily and spent a lot of time studying because as you know, there isn't, let's say, a proper training for architects.

I mean, yes, there are TOGAF and all the other different certifications, but it's not that they are telling you how to be an architect in terms of communication, tweaking your language based on the audience that you have, decentralize yourself, understanding that yes, everything is always on fire, so you need to pick the right fire, and all the things that you learn in the trenches over the years, because when you take an architectural decision, it's not materializing next week or next month.

It's something that you decide today, and if you are lucky and you work on a product, it will materialize probably in a year's time or even longer in certain cases. Therefore, if you are capable to create something bulletproof for the future, because you cannot predict the future, but you apply the right modularization in certain areas of your system for enabling the business to evolve no matter what is the direction of travel that they're taking, I think there, there is a lot of novelty and creativity that you can apply on top of your technical skills. Obviously, in order to do that, you need to convince people that your idea makes sense and you need to receive positive and negative feedback.

And to be frank, what I learn over the years is that the feedback, no matter what it is, if it's, sometimes let's say that the communication is not to strangle some people and they don't smooth every corner, but no matter how they are delivering a message, I learned over the years that it's important that I decouple the information from the form of how a person expresses himself or themselves. And I think it's very, very important to learn that I gain over the years and enables me over the years even to understand that in reality there is always something that I can improve no matter how harsh a comment is or how positive a comment is.

In general, feedback for me is a gift and I want to make the most out of it despite its negative or positive, because the negative part is just a step closer to improving your solution. Therefore, if we start to think with this mindset, any kind of feedback is extremely important. I have seen that it became a very contagious mindset over the years inside companies because then people started to behave differently if you don't overreact and you instead try to understand the point of view, put yourself inside the shoes of the other person and trying to make a step towards them more than moving on the other side.

So I think this part of where communication back in days was a soft skill, I always refer as a core skill, no matter if you are an architect with a title or a developer nowadays, especially with AI where let's say we start to have slightly more time for implementing features because the creation of code becomes, let's say, I cannot say a commodity, but becomes let's say easier to a certain extent compared to what was in the past. And therefore, I believe that this architectural mindset that covers not only the technical part, but also the social part will be extremely beneficial for any single tech person that is navigating this AI era.

Michael Stiefel: I am very sympathetic to the socio-technical view of architecture because in my career, I found sometimes the biggest obstacle to going forward is people's inherent dislike of change. And also the fear, and this is very interesting listening to you talk about feedback, that people very often don't give feedback because they're afraid of the managerial repercussions of the feedback. So I think you're right when you say that this is a core competency.

It's not a nice to have, it's an actual core competency. And especially now then you've raised the specter or the benefit, however you want to look at it, of AI where you're communicating in natural language and you have to be very precise in how you write your prompts. So communication rises from a secondary skill to a primary skill.

How do you see the education of an architect in the age of AI, especially when we do not fully understand the technology or where it will go?

Luca Mezzalira: I have let's say a very pragmatic take on the education side. I believe that no matter what your title is, you need to have the skills. I'm witnessing a decentralization approach on architectural practices across the industry, not every single company, but there are certain industries, especially in more modern companies that were born in the SaaS era, I would say. They started to decentralize a lot towards developer sense. But the reason, let's say a formal education is literally, okay, now you need to take care also about that because we don't have architects anymore. There isn't anything provided to them. Also, because I don't believe architecture can be only taught with lectures or let's say frontal education. I think it has to be collaborative.

You need to learn the skills of communicating. I think you need to properly design, think that behind the narrow, there is a lot that is hidden and you need to go to a different level of depth. Therefore, even the most technical developer could find some benefit of talking or thinking like an architect because they can better understand the problems of other teams and the company itself. When I think about education for architects, I want to have something that doesn't sound like Katas. I know for instance, Neal Ford is a big fan of Katas and even Mark Richards, they're talking a lot about them. We worked together for O'Reilly back in the days for the first edition of O'Reilly Katas where multiple teams all over the world submitted their projects based on a scenario.

It was quite fascinating listening to them on how they are thinking about the architecture characteristics and analyzing the other proposals was extremely helpful for me. But in general, you need to think more holistically on the complexity, you need to handle that is not merely writing performance code or writing beautiful code at the end of the day. Code is good for reading for people. Then if we think about all the levels of abstraction we have done, probably sometimes we used to be not even the most performant inside the program, but it is what it is, I would say. In general, the education should be, let's say, and so on should be with case studies where we can see how other people have tackled a specific problem.

We also need to understand the context. Very often I've seen in conferences a very interesting behavior from speakers where they were saying, "Oh, we moved from microservices to monoliths because microservices are evil". And once I did an exercise after this talk about moving from microservices to monoliths, and I went to the speaker in private and said, "Listen, can you tell me a bit more about your team structure?" And she was telling me, "Oh yes, because before we were five teams and we have 10 microservices and now we are just one team and we have a monolith". I said, "Okay, but that was an important detail to describe inside the talk. If you avoid that, it seems that the architecture itself, no matter what the context, will have a negative impact".

And I think these kinds of scenarios are extremely important for developers to try to always look holistically about the context and what people are saying because behind an absolute statement, there are always nuances and there are other things that they might not be surfacing in a conversation or in a talk or in a book. So I always tend to understand first the context because I know probably you are quite familiar with the statement, "Oh yes, we are using Squad like Spotify", and many companies are talking about that despite Spotify never implementing that model, the conceptual model that they had. And when you think about this, you say, "Okay, but then what was that? It was a scam". No, it's not a scam.

They aim for a shoot for the North Star and they arrive halfway through and it was good enough or they understood that the effort for putting in place everything like they designed, was too high. But at the same time, they have a specific engineering culture. It's not like there are too many Spotifys in the world. What works is Spotify works as Spotify because Spotify has a certain way to interpret the life of an engineer similar to what is happening in Google, in Amazon or wherever it is. So I think context should drive certain decisions.

And I understood that best practices or patterns and anti-patterns sometimes can be leveraged no matter if we think it's written in a book black and white that is bad for a system or extremely good. You might decide to avoid it for a strong reason. And very often it's good knowing that there are certain things available, but not necessarily embrace every single best practice because it might not fit inside their context.

Michael Stiefel: For example, you mentioned Spotify or Netflix or Google. If you have risk-adverse engineers because that's their personality, that's just as much a constraint in many respects as how many CPUs you have or what your network bandwidth is. This is what I find fascinating about when you talk about context, people have to think of these dimensions as well.

But I also want to get back something that you said before about decentralizing things because one of the things to me that's important to an architect is they are responsible for the things that no one else is thinking about. In other words, you can't write a use case that says make the system scalable or make the system safe. And if you decentralize and you don't understand what the AI is doing, the abstractions can leak all over the place.

I know you're interested in this particular problem, so what kind of advice would you give to people in this world where the AI is doing a lot of stuff, but the AI doesn't know where the abstractions leak?

Luca Mezzalira: To be honest with you, I strongly believe that architects in the current term of the role should evolve into a sort of enablement team like we think about in topologies if we want, like security. For me, the example of security is quite crystal and clear. Usually think about how many security people you have or how large the security teams are inside an organization. It's probably one security architect, 20 developers, something like that. So therefore scaling that part is complicated. Now in architecture though, I tried in the past and I think it worked decently well, but obviously I could push even further. It's the idea of helping developers to make architectural decisions.

Andrew Harmel-Law discussed this part very well in the advice process where you decentralize. Everyone can design something, but then you need to create some guardrails. And from Andrew's book, I fully agree on the fact that there should be a committee that is composed of who is going to consume the API and let's say some people that have expertise that should review the design of a specific area of the system. And these groups of people that are more fluid than a formal architecture team should, let's say, decide the direction of travel. And I really like this democratization of designing architecture in general because I believe it's not sustainable. You cannot have let's say one architect every two teams because the cost will surge drastically.

But thinking about being an architect as a coach where on one side, you help people to ask the right questions and to have the right mindset when you are designing something. On the other side though, I think also there is a problem or a challenge in general on fully decentralizing every single feature that is basically that classic feature that's spun across multiple domains. And it happens every single time. It's like two or three or five per year that you need to tackle. The problem is that there are biases if you are inside the team. So I try to make the best in my team in order to succeed. The gamification of promotions in general in every single company is that the best person will succeed and therefore deliver the most for the company, and so you deserve a promotion.

For me, that leads sometimes to the wrong behaviors inside the organization. Therefore, having someone that can look holistically on the problem and not designing, but helping to rationalize asking the right questions that are not, let's say, too coupled with a specific domain, but they understand the business because they spend more time with the business. They understand the tech because they spend time with the engineering teams and so on. Having these kinds of figures I think will help a ton in companies that have, I don't know, 50, 100 people. Because no matter what, having someone that looks holistically on that will be helpful, but also could be the one that provides guardrails for the entire system.

We were discussing before on how engineers can become an architect. So sometimes there are certain things that you don't have time to do, no matter if AI or not, like okay, I want to create some fitness function that makes sure that my system behaves in a certain architectural way. And I think this is the part that architects can contribute, can own the holistic view of the system, can provide the guardrails, can also surface patterns that are happening inside a specific team for all over the organization. There are a lot of things that in my opinion an architect can still do inside the company, but I would say the time of, oh, you just design, let's say at nine in the morning you start your job, you design the architecture, and then you go and just talk with people, it's shifting a bit.

I feel that we need to do more than just design architecture. Usually at my team in DAZN seven years ago, I was saying 70% of your role is being empathic with the people that you need to work with and 30% is being technical, not being the most technical one, but being technical and understanding what's going on inside the system. And the empathic part for me is going across the organization, understanding what's coming, trying to fit this information into the team so they will be able to make the right decision.

And if someone is making a decision, you can raise these things and say, "Yes, by the way, you know the thing's two months time. We need to implement this specific feature and we'll invalidate this specific decision for this reason, that reason, this reason". Because at the end of the day, developers with this shift left movement that we have seen in the last few years, they have a lot on their plate.

Now maybe with AI we can delegate a bit of the code creation, but still we shift left for the DevOps part. We shift left for security. We shift left on architecture. We shift left on writing code obviously. And if you think about early 2000, you were writing code, you wrote the test, and then you're thrown on the other side of the fence for someone in the DevOps team that you didn't even know the name of the person that will be basically pushing your code in production. That is a completely different world now.

Michael Stiefel: What you're saying, maybe I'm pushing the analogy too far, but in academia when you're doing your research, learning to be a PhD, you have a thesis advisor. And the role of the thesis advisor is to ask the right questions. In other words, to look at what you're doing, see the weak points and ask the right questions.

They don't do the work for you. They don't do the research for you. They don't do the development for you.

They don't even do the architecture for you. But they're there to say, "Did you think of this? Did you think of that?

Do you realize the business people are thinking of this in two years?" And that is, I think, what you're saying about the role of an architect. They almost become a super mentor. They still need their technical chops, but they're the super mentor, which then raises the question, and I know you've talked about this before, if you're using AI agents, you have the difference between knowledge and purpose or wisdom.

What do you think of that statement?

Luca Mezzalira: I think agents are a very interesting tool and for certain use cases, I would say that might be pertinent. Would they fully replace architects? Depends on the project.

So there are small projects that, to be honest, don't need much design. If you have, I don't know, 10 requests per second, you can write the worst code in the world, you can show everything inside the virtual machine or container because of the traffic, because nowadays we are operating in amazing machines, it's very unlikely that it's going to fail miserably. And then we might argue that my lack of resilience, my lack of scalability and so on and so forth, but there are certain projects that don't need any of those.

Obviously we are talking about small projects, so this is probably the long tail of software. But when you are in mid-size, large organizations, there is a lot of context that is hidden over the years.

Sometimes in documents, sometimes in people’s heads, it's complicated. So facing the context is very complicated. There is also a systemic problem on all of these that obviously we have a limit on tokens, we have a limit on context window, we have a limit on summarization.

We have a probabilistic system that the majority of the time might recommend the right things to do, but not all the time. There are a lot of things that are inside of this agentic revolution and not let's say against them. I think they can help drastically, but I still think it's very important that tech and product and business talk together in order to understand what we are building.

Because if we don't understand what we are building, then we cannot feed agents or whatever else with the ideas. And on top of that, if you see the evolution of this revolution, we started with the MCP that didn't have any authentication.

Now, I don't recall any game changer APIs or techniques that forget completely about security. We are seeing multiple attacks in different ways on, I don't know, packages that are deployed on open source projects, people that are installing agents in their computer, giving them access to their credit card or their email and whatever it is. So I think we are exploring a lot that is great, but sometimes we forget about the fundamentals of software.

That is a bit of a shame because yes, we need to stress out these things and see where we land with that. But there are certain things that now are a baseline. You have a baseline on how security should be a system.

If a system leaks a credit card, it's basically instantaneously in all the newspapers in the world. There are a lot of things that we need to take into account.

And that's why I believe that architects or human beings in general are still very valuable in the software chain. It's not that we'll be fully replaced. They'll augment the capacity for them and also have more time for thinking in my opinion, but I don't believe that every single role will be fully replaced by AI today.

Michael Stiefel: So if you can think of a specific example, if one comes to mind, because the change is happening almost so fast that humans can't understand what's happening. I mean, this is the problem with the regulatory framework. As Donald Rumsfeld famously said, "It's the unknown unknowns that kill you". Do we even know as humans where we have to be in this chain of reigning in the probabilistic AI agents?

Luca Mezzalira: I think currently we are testing it out. If you go to conferences nowadays, you see different approaches. It was very interesting for me to listen during QCon London, two different approaches. One was to delegate everything to AI and let's focus on input and output. While the other one was augmenting the software development life cycle with AI, both of them claim incredible results. Both of them provide some trade-off that you need to embrace. One is obviously trust in the first example. The other one is more, okay, we move the needle not 10X, but maybe 2X. And I think this is a very interesting moment where even during the keynote, one sentence that stuck with me was, "We are all juniors in this new revolution despite your level of expertise or experience".

And it really resonated with me because if I think nowadays about where we are in AI, just in the last few months, in the software development life cycle, it became the AI DLC that was proposed by AWS claiming that how we designed the software development life cycle over the years was mainly for human beings. Now we need to challenge certain practices that we had like Scrum or two-week Sprint, stuff like that. And they proposed this idea of bolts, let's say a different approach and more tailored for AI. We have seen a Gas Town that made a lot of noise where basically it's just an orchestrator for agents and is self-healing and doing whatever it needs to do for building software, burning, I don't know how many tokens.

The creator claimed that he never saw a line of code or what was produced by AI because sometimes if there is a bug, it tries two, three times, maybe the bug reappears, but it's fine because the speed trumps the perfection. And I would argue, we started to see some glitches. I don't know if you have a similar experience in very well known applications recently that have some bugs that never were exposed before. Nowadays, we start to see some more glitches. So I believe we are still trying to figure out where is the role of humans. I have a mental model that I'm currently using and it seems that at least for me it makes sense that it's basically leveraging domain-driven design, sub-domains type, in order to decide how much human in the loop I want to have.

So if it's a core domain, it should be heavy on the human in the loop parts. Let's take Netflix as an example. Netflix, for instance, as the video player and the catalog as a core domain because the reason why Netflix exists is that you can watch your favorite movie or series on any device at any given time and it's completely up to you to decide when and what you want to use to watch this content. So that part maybe you need to be more careful in my experience, especially when we talk about the broadcasting and streaming, it's not a walk in the park.

There isn't much information out there, so you need to test different things, especially with live content, and therefore you need to have a human in the loop and you need to think and try and try on different devices. There are a lot of unknowns that you need to figure out. When you move let's say further down the line, you can have support in domains like personalization.

Personalization is nice, it's great to have. Everyone expects that, but I don't think anyone will scream if they see exactly the same movies from the day before if personalization service is down. So that means you already provide different architecture characteristics to this domain and also you can apply different AI characteristics.

You can delegate slightly more to AI maybe than before. It doesn't mean that you should apply a mild code review approach, but you can be more flexible.

While generic domains I think are something that you need to do, and even if they're not perfect, you might be happy with that. A classic example in Netflix could be payments. You need to pay in order to watch the content, but payment itself is not, let's say, the reason why Netflix exists. There is no key differentiator compared to Prime Video or DAZN or whatever else. In that case, if it's integration and is basically taking the Stripe SDK or wherever other, I don't know, Zuora's SDK or other payment SDK, and you need to integrate inside your code, there is not much novelty there. So you just need to take some data to integrate your SDK, retrieve the receipt ID of a credit card that paid for a subscription and send that to the rest of the system.

So if I start to use this model with AI, you can see clearly that as I use it for architecture where I can apply different characteristics and in the team topology side where I can have, let's say the strongest developer, most experienced developer on the core domain and maybe having some of them spread on the others, I can do the same on AI. I can start to say, by the way, maybe on these domains here, even if they're not perfectly written and there is maybe, I don't know, a bit of lack of test or whatever, but they seems to work and they don't harm anyone, I might be able to be more indulgent and provide more delegation to AI. While on the core side, I want to have full control. I want to understand how things are evolving.

This is probably a high rate of change, so code volatility is important. These kinds of things usually are top of mind for me at the moment when I'm thinking about where humans will sit in this world. And if you see also on the AI side, what we are trying to replace as soon as possible, we're talking about HR in large organizations, we are talking about customer support. And even with them, we need to keep some of them because there are some critical things that AI cannot do as well as human beings. When you start to look into the social aspect, even in large organizations, they cut basically the smallest departments, even the one that is the key ones. So that probably tells you already where the mindset of the C-suite is at the moment.

Michael Stiefe l: You don't actually want to have an AI agent lay people off, at least not yet. What do you think of the idea from a governance perspective? Every time you have an agent, the agent must check into a table to make sure it's not been turned off. In other words, if you have a rogue agent, you should always be able to shut that agent off at any time. And so there has to be obviously some element of governance in here, whether the human is in the loop or not.

Michael Stiefel: So this is a question I've asked a lot of people and no one has a really good answer for it. So I'm not expecting any revelatory flash, but if AI is doing all these easy tasks, and these are the tasks that developers used to become apprentices on, how are we going to train the next generation of developers and how are they going to develop their intuition to understand what could work, where the abstractions break down? Because this is what bothers me.

Luca Mezzalira: I'm with you on this one. The best answer I heard so far is from Kent Beck. We were talking about pair programming for ages and mob programming for ages, and now it's more important than ever, exactly for this reason.

Obviously every single team is very unlikely to be composed only by senior engineers or distinguished engineers. There is always a variety of titles and experience in the team. Therefore, considering that the code generation is becoming faster because we don't have to write every line of code, we need to, let's say, review the code that is produced by AI, that means we have some time to let people grow inside these things.

So if, for instance, in the past, in every company I worked at when I was an engineer, we always have this rule that two people should review a PR.

And I think this is even more important now because if we do that, the more junior person usually provides this feedback on the code generated by AI and the more senior person as well, so you can learn asynchronously on that part. At the same time, you can use pair programming and mob programming to understand certain things. I remember vividly my times as a principal when we were organizing mob programming with the tech leaders on every single team, and we were like a dozen of people more or less inside the room. And the discussion you might think is like, "Oh yes, but it's just a waste of an hour for everyone". But the discussions were so deep and so interesting overall, moving from, I don't know, shall we integrate generators inside the system or shall we do X, Y, Z?

And analyzing all the trade-offs and all the other things, that is where you really start to learn things, having these experiences that nowadays you can call community of practices or any other, let's say, office hours. There are plenty of names or occasions to have regular cadence of this kind of discussion. And I think we need to continue to do this because at the end of the day, we are doing all of this not only for delivery shipping features, we need to deploy production, we need to understand the observability, we need to know that when at 3:00 AM we wake up following the round book, we know exactly how to solve a specific problem. So there is way more that is not just code generation that we need to think about and AI can help in all of that.

And I think we can potentially even accelerate the learnings for people because if you start to chat with AI and you provide, let's say, some decent RAG system on how we are used to working on a specific product, I think people can learn and onboard faster than it was before. But at the same time, we need to remember that architecture always thought that it's an enabler for an organization. Therefore, when you choose microservices over monolith or vice versa or distribute modular monolith, you are signaling that you want to see certain characteristics inside the socio-technical system. If I think about this, it means that even with agents, the architecture we are going to choose matters.

And it will help people to think about if it's a microservice, we provide all the bells and whistles inside the microservice with, I don't know, retries, exponential backoff and gracefully degrade the system, all these nice things that very often people don't have time to build, we will be able to fill even in production but not impacting the system. And I think these kinds of things help people to gain their battle scars in the trenches and then learn from them despite the fact that they didn't write every single line of code because in the past we were used to write a portion of the code, but we didn't write every single line of code. Because in a team, I take a task, someone else takes another task. I'm comfortable reading the other person's code because we try to keep the same style.

In general, I believe, yes, it's a challenge, but I don't believe we should be desperate straight away. I think the community will figure out the best way to handle that. And the companies, to be honest, I've seen many that are still hiring juniors and I'm extremely happy to hear that because the reality, this is, let's say, the future of our society. So we basically leave with everything that is digital. I don't remember the last time I went to a bank, probably 20 years ago. Nowadays for me, everything is an app and my bank is an app.

Michael Stiefel: Well, your safe deposit box is not quite an app yet, but I remember there was a study where developers tried to use AI to help them understand, and there was another control group that didn't use the AI to understand. The two groups essentially learned at the same pace. There's no physical difference from them, but testing afterwards their recollection, those who learned with the AI had significantly less retention.

Michael Stiefel: So I think what you describe, there is evidence that this is the way you have to go. Not only should you go, but you have to go.

Luca Mezzalira: Of course, because obviously it's a more shallow way to implement a feature. You provide, let's say some specs, and if you don't check the code and how it's written, you just accept blindly what is behind that. You cannot master it.

The mastering part is trying, making an error, let's say start to bang your head on the wall, try to figure out if there is a better way to do specific things. That's why at the beginning I said I love refactoring because refactoring is exactly that. Give me something chunky and complex and I will unwind it for you.

And that process is extremely important. I strongly believe that AI should be an accelerator and a companion, but we need still to improve our craft no matter what. Otherwise, it's very difficult for anyone to think, "Oh, but this is just code".

It's not just code. There is way more behind that.

There is the optimization on specific things that will drive the behavior inside the browser, or there is an obstruction that helps you to, let's say, integrate in new systems very quickly. There are a lot of ideas that people have that are difficult to express just with a business process because unless you are there and you say, "Okay, so I know that they need to have code portability, so let's try to figure it out what is the best way? Should I apply an adopter here?

Should I use hexagonal architecture there? Should I decouple the environment from the business logic? How am I going to do that?

How can I create portability? How can I update a library when there is a change on multiple systems?" So there are a lot of questions that still developers need to answer that are not merely, oh, this is the spec of implementing a feature. Therefore, I think it's still a valid concern and we need to learn how to do these things properly.

Michael Stiefel: Just to pick an example that I remember more than once in my career, paradoxically, the optimal thing to do is actually to de-optimize. And that only comes with experience and understanding exactly what's going on.

Luca Mezzalira: Completely. I remember vividly when my CTO told me, I remember everything is on fire. You just need to pick your fire.

And in a large system, I was handling like 550 people in the tech department. I cannot be stretched to cover everything in different locations and so on. So you pick your battles.

So you decide that certain areas of the system deserve your attention, certain areas. People are good enough for handling that situation on their own. You just need to check that everything is fine.

And the worst case scenario, you create a system that either is self-healing or hides gracefully inside the trenches. Even with integration within a system, we were designing in a way that if something that we don't understand because it was a third party that we integrated failed, we just hide it and we create all this logic for enabling people to move on but not compromising the platform.

And I think these kinds of discussions are extremely important and I honestly value a lot of discussion. That's why architecture for me is very interesting because there are experiences from other people coming from other industries that can provide you with completely different angles that you didn't think about because you weren't exposed to. And that's the part that I love the most.

Michael Stiefel: Now's the time when I like to get to the architect's questionnaire. It's always interesting to me to talk to people who have experience in the architecture area and get their take on the more, I don't want to say softer side, the more human side. What's your favorite part of being an architect?

Luca Mezzalira: So in the last five years in AWS, basically I work as a consultant if you want, where I go to customers where they have a problem, I try to figure out and understand the problem and then apply architectural wisdom in order to solve the problem and then line it up with AWS services, but that's basically what they do. I found extremely interesting this context discovery. So understanding the dichotomy of teams and the balance that they have.

And I have let's say a set of questions that develop over the years that helps me a lot, especially because I go in in a meeting and I might not know what the company is building. So I start to understand how many teams there are and are involved in that specific project or feature. I try to understand the resilience standard that they have.

I try to understand the SLAs and SLOs or all the other things.

And this discovery of the context is very interesting because you start showing the customer or the team the holes that they have or they didn't think thoroughly on something. And sometimes you discover that in reality they are optimizing for something that no one asks for and that creates an enormous complexity that is easily solved without adding any configuration on the product, reducing the stress towards the architecture and lowering the bar to something that is more accommodating if you want. Very often when I hear, "Oh, we need to do near real time data", it's near, it's one minute, it's 30 minutes, it's one hour. There are customers that one hour would already be a huge win. Customer that within one minute they start to say, "It's not too fast for what we need to do".

Then I apply let's say techniques like event storming, Wardley mapping and all the other things that for me, going to a customer, I have no clue what they're doing, how they operate. Running an event storming session was mind-blowing because in one day I know exactly how the things are working at a high level and I know how the system could be designed or could be broken apart and I can start to stress it out and start to layer up some of the technology that they are using.

Michael Stiefel: What is your least favorite part of being an architect?

Luca Mezzalira: So there are certain designs back in the days that I couldn't bother much with. I mean either because they were too simple or because they were too skewed towards a specific area that wasn't, let's say, super strong or whatever. I remember for instance, the authentication part, authorization part.

When you have done the first time, you are excited. It's the first time you do that. The second time, "Okay, I applied what I learned.

Great". But after the seventh time that you're doing that, "Again, authentication authorization. Can I delegate something?" These kinds of things become a bit tedious after a while if you have multiple systems and if you move between companies as well.

So that part is becoming a bit tedious. So yes, I know that this is important, but can someone else do that?

Michael Stiefel: Is there anything creatively, spiritually, or emotionally satisfying about architecture or being an architect?

Luca Mezzalira: I think emotionally it's one of the most amazing jobs that I've done in my life because when you are capable with a decision or making let's say the right call and you discover again over years, enabling the company to grow, obviously you are just a cog in a large system, but still, you know that that decision was your decision. You say, "Okay, yes, we should go in that direction". And you see the feature that is going there or the system is going there live.

It's working. The customer loves it. Everyone that did a great job and whatever.

You become extremely proud of your work. I remember very vividly a couple of years ago when I already left my previous company, DAZN, for a while, the principal engineers from Amsterdam met me in a conference that was telling me, "Look, I have to tell you these things. It's been eight years that we're doing micro-frontends.

We didn't change anything about your architecture because it's still enabling us to have the right level of flexibility while maintaining a solid standing that everyone understands". That for me is the most rewarding sentence that I have for ages because having an architecture that lasts for that long, like eight years, obviously in the past it was different, but nowadays it's mind-blowing, especially because it was extremely cutting edge. No one did the scale that we operated that specific architecture.

I have to create patterns, anti-patterns, the vocabulary of architecture and everything. And having someone that is experienced like this person, they have worked in multiple companies and saying, "Yes, after eight years, it's still there. Still deliver what was the idea".

I still remember that moment.

Michael Stiefel: So on the flip side of that, what turns you off about being an architect?

Luca Mezzalira: So we know that communication is important, right?

Luca Mezzalira: There are certain people in a certain organization, I think it's more cultural sometimes, that they hide behind titles. I don't know. It's probably a me mindset. I'm not saying that other people have the same thing, maybe they do, I don't know. But I don't care about the titles. For me, we are all human beings. We have a brain and you have experience and expertise no matter what. Using that leverage for not fighting on the same table fighting is like discussing on the same table and just, let's say, using your title to shut off the discussion is not something I appreciate.

Michael Stiefel: I totally agree with you. This is one of the reasons why, for example, I have a PhD, but I never put that on my business card. I know people have PhDs and they're on their business card. I don't want it to be on my business card. I either know what I'm talking about or I don't know what I'm talking about. And the fact that I have a degree has nothing to do with that.

Luca Mezzalira: I agree. And there are splendid people that I met over my 20 years in the career, obviously. Sometimes it's very cultural because they didn't expect that I was able to develop or programming or doing pair programming.

And for me it was, "Okay, but I'm one of you. I'm working in the same company. I want to achieve a specific goal that is exactly the same goal that you have".

If I can and I have time, I will cut my arm in order to succeed in specific things because I have this sense of community. You have a degree, I don't. I left school when I was 16, so I learned with the community.

I worked in a factory for a while, but then I studied overnight and not in my language because in Italian there weren't many tech books back in the days. So therefore I have to order from Amazon.com my books and learn English.

I didn't know anything in English. So for reading a book, it took a month or more and slowly but sadly then applied this stuff and these learnings. I learn in this way. I learned with the community where social weren't there or video courses weren't there. You just open a request on a forum hoping that someone will reply to you. And because obviously it was everything in Italian, you have a subset of the world that can reply to you. So that sticks with me till now. For me, I tried to do in the beginning when you introduced me, you have seen that I did public speaking and newsletters, podcasts, et cetera.

Because I still believe that there is somewhere someone that is waiting for that content like I was doing back in the days and try to cut through the noise and figure out if my content lands in somehow because I feel lucky that I've seen a lot of stuff in my career and I don't want to hold it honestly. I think it deserved to go out and maybe I learned something new, maybe someone else is learning something new. Either case is a win for me.

Michael Stiefel: This is why I enjoy doing this podcast. I don't need to do this. It doesn't really benefit me much personally, except psychologically and emotionally. I feel that I want this knowledge from different practitioners to be spread throughout the community because as you said, there's book learning and there's actually being in the trenches with the battle scars, and that's where the real knowledge happens.

Michael Stiefel: Do you have any favorite technologies?

And slowly but suddenly I grew with this thing and the more I was using it and the more I realized that I was able to express my architectural thoughts better than just having containers, orchestrators, here and there. Because spinning up a queue was a breeze and I want a broker, I want an orchestrator. Do I need to communicate asynchronously for a chunk of my domain and another part synchronous? I can. I think this flexibility for me was mind-blowing with honestly little effort for spinning up stuff because it was infrastructure managed by someone else. Obviously with these at the beginning, especially with their limits, but when there are limits, usually creativity starts to kick in, so you start to overcome these limits in different ways.

At the end of the day, we were dealing with a platform of three, four million customers. So it wasn't like a small platform that you can find, let's say, that doesn't work. And we have huge spikes of traffic. So designing things was challenging no matter what we were using, even probably with serverless sometimes slightly more, but we used a very nice combination of serverless and let's say containers through Fargate in that case, and it was quite a nice combo.

Michael Stiefel: What about architecture do you love?

Luca Mezzalira: I think it's solving problems. That's the part that I love the most about architecture because I was an engineer at the beginning of my career, so I solve a lot of problems through code and I love working on unconventional places like embedded systems, for instance. You have some quirkiness that you didn't expect. Then moving to mobile when the iPhone and Android came out was extremely interesting. I remember when we were working in gambling, some games didn't work as expected inside certain Android browsers, especially with Android 2, Android 1, because the browsers were so fragmented that even a simple CSS implementation like unload the CSS didn't work because it wasn't implementing in the browser.

So you start to have this fragmentation, that kind of problems that I had in engineering, now I translate into architecture and it's even more challenging because now there isn't one dimension like, "Oh, the browser doesn't work". My feedback group is very fast. Here, the feedback loop is way longer and therefore experience, trial and error, learning from others, just chatting with other people, try to figure out the different ideas, see which one sticks better, maybe running a POC, document this thing, understand why a certain decision was made in a certain period of time. All these kinds of things for me are extremely fascinating. I found a lot of pride in doing this job.

Michael Stiefel: Conversely, what about architecture do you hate?

Luca Mezzalira: I would say people thinking that the architecture is a problem while it's not that the architecture is a problem, it's just signaling certain things inside the socio-technical system. Probably you have experienced something similar. You work in a company when the first problem arises inside the trenches is, "Oh, the architecture is wrong". Without even thinking about, "Okay, did we analyze if it's, I don't know, the commits that were wrong, the code was wrong? Are we structured properly for enabling this architecture?" I think let's say it's the most visible thing compared to people, engineers or product, et cetera. Are we structured correctly?

I mean, if I choose to go with Elixir, for instance, and I have let's say a bunch of people that are coming out from university, then probably I need to figure out something that is less complicated to start with. Obviously, if I work on a very complex system and Elixir is needed or I want to use, I don't know, Akka with an actor model implementation, I need to adapt this architecture for a specific context. So in my opinion, architecture is just there for facing good and bad things. Friction, I always interpret as a gift because as a feedback that architecture provides you, it's telling you something doesn't work.

And that's something, it might not be in the architecture space. It could be that maybe we designed one thing that was working in the past, but now suddenly the team grows so much or they split in a way, but the code is still needed to be co-located and therefore the friction arises because probably we over indexed on the teams, we should redesign the teams in order to have better things, not necessarily the architecture is wrong or the distributed system is wrong or the monolith is wrong. I think architecture, all of them are still useful nowadays. There are some of them maybe less than others, but I still believe that having these people that immediately put their things, "Oh, this is too complicated, I don't want to even see", it's not something that honestly turns me on.

Michael Stiefel: And sometimes some people don't appreciate that there was a trade-off that was made. Yes, we consciously made this case not to be optimal because we had to achieve something else. It's that same lack of perspective.

Luca Mezzalira: Exactly. Thinking holistically about the system is the other challenge that happens very often. I think it comes with maturity and experience. It's not, let's say that you have it for free. I probably was similar to those people at the beginning of my career because I didn't see the system holistically.

Michael Stiefel: What profession other than being an architect would you like to attempt?

Luca Mezzalira: The first one I would like to do is street food, Italian street food in London. That's definitely a plan C for me. I was always interested in what I think overlaps with the skillset of an architect to a certain extent, is this idea of advocate or let's say developer advocate or evangelist or stuff like that, because I really love taking complex ideas and trying to unwind in a way that is bulletproof. And I think it's a skill. It's not something that everyone can do. You need to really go deep into that specific problem, understand deeply and remove all the noise, cutting through the most bare minimum implementation, then you build on top of that.

This is something that I really enjoy because recently I just published my second edition of Building Micro-Frontends book, and the feedback that I have most recurrently this time is, "I cannot think of something that is more clear on how you have written this book". Everything that is there is simple and I don't get why people don't get it, but in order to be simple, it's been 10 years that I'm working on that.

Michael Stiefel: Yes, yes, yes. Sometimes it takes you 10 years to get to simplicity, because to achieve simplicity, you have to learn what really has to be there and what is not necessary. And sometimes you only see that with experience.

Luca Mezzalira: Yes. And you need to try and try and try till you are bored of hearing your voice.

Michael Stiefel: Yes, yes. Do you ever see yourself not being an architect anymore?

Luca Mezzalira: No. I would say the industry will decide. It's not up to me.

I can continue till the end of my life, to be honest, because I really love what I'm doing. It's the most interesting thing that honestly I have seen. I had the opportunity after being VP to move towards a more managerial career path, VP of engineering or director or CTO, et cetera.

I ditched those opportunities mainly because I think I still have something to do and to say in the architecture space. And I didn't expect AI back in the days when I took that decision, but I believe now it's even more important that what I've learned, what other people have learned there in the trenches can help new joiners in the industry as well as experienced people to rationalize better what's going on with AI and how much to trust.

I've seen these more balanced approaches of the architectural community compared to the fanboy approach than other companies or communities are doing where, "Ah, we can do everything with AI". Absolutely, you can do everything with anything, but doesn't mean that because you can, you should. And I think it's important that this message lands properly. I started to write a few articles recently on these kinds of discussions that I did at conferences or watching online content and they landed very well with few people that reach out to me saying, "Oh, finally a point of view that is not indexing too much on one side or the other one. It's a balanced approach and it highlights the trade-offs".

Michael Stiefel: When a project is done, what do you like to hear from the clients or your team?

Luca Mezzalira: First of all, when a project is done, we should share that no matter if it's perfect or not, it doesn't really matter. We achieved something, it's a milestone. Personally, I don't expect a thank you or anything. It's not because I feel that it's perfect. I've just done my job and therefore I'm more interested to wait six months, one year and see if we have done our job properly. Therefore, my gut tells me that I'm still nervous even after the release. And not because I'm not confident, it's because I know that that is one part of the game.

In previous companies, I spent, you have no idea how much of my time and during the weekend especially going to the war rooms in different companies to see how the platform behaves live because I found that experience extremely interesting. They were, let's say, watching because it was a sports company, the previous one, they were watching the matches and keeping an eye on the dashboard. I was watching the dashboard and keeping an eye on the matches.

Michael Stiefel: Even if your favorite team was playing?

Luca Mezzalira: Exactly. It doesn't matter. Just saw the New Relic or the dashboard and say, "Oh yes, there is a spike here. What does it mean is we need to check on Monday". Stuff like that.

Michael Stiefel: Nevermind the winning goal was just the cause... That caused the spike.

Luca Mezzalira: It's not a problem. Someone has to win, someone has to lose, so that's fine.

Michael Stiefel: Well, thank you very much for appearing on the podcast. I enjoyed this conversation very much. I think we touched on several important things for the future as well as the present. So I would like to thank you.

Luca Mezzalira: Thank you. Thank you for having me. I hope that this conversation was helpful for all our listeners.

Michael Stiefel: Yes. Thank you very much.

AI, ML, and Data Engineering InfoQ Trends Report 2026

The Future of Web Apps: Will AI Agents Generate UIs on the Fly?

What Does it Really Mean to Program with AI: a Conversation with Joy Ebertz

Future Cybersecurity: Hardware Memory Safety, Automated Governance and Post-Quantum Cryptography