Danish Naseer: Hello everyone. You were listening to Suhaib and Ali on how to deploy with Velocity, the keynote session of Prepathon 2026. We are back with another insightful session with Luca Mezzalira and Maud Nalpas. So I would like to introduce them one by one. The topic we are going to discuss in this panel discussion is: Your AI wrote the code, now who owns it? First of all I would like to invite Luca Mezzalira on the stage. Luca is an architecture and AI expert known for his work in distributed systems, micro frontends, and modern software architecture. Luca, welcome on the Prepathon stage. We have multiple developers who are listening to you. So if you can say something to our audience.

Luca Mezzalira: Absolutely. Thank you very much for having me. It’s a pleasure being here, and good morning, good afternoon, or good evening from wherever you are listening to us.

Danish Naseer: Another guest speaker we have is Maud Nalpas. Maud is a Senior Developer Relations Engineer at Chrome, specialized in AI engineering evolution and client-side AI. Maud, welcome to the Prepathon stage.

Maud Nalpas: Hi everybody, very nice to meet you. I’m a DevRel engineer at Chrome and excited for that chat and for hearing what you all think.

Danish Naseer: Awesome. I think we are ready to start the panel discussion. Everyone knows the topic: your AI wrote the code, and now who owns it? I would like to start first with you, Luca. My first question is, AI can now generate a large amount of application code. What changes when the person who writes code is no longer necessarily the person designing the system?

Luca Mezzalira: Yeah, it’s a challenge, right? I believe that code generation is great, but generating more code has never been, let’s say, a good sign of good software. Usually we aim for essential complexity more than accidental complexity. Therefore, it’s very very important that we guide the coding agents in order to move towards the direction that we want to express inside the system. I strongly believe that harness engineering and loop engineering are here to stay. But we need also to leverage what we have learned in the last two decades working in software, and not discarding it up front but instead augmenting our capabilities, and providing the real context that is not present in the code, is present in the socio-technical system, into our harnesses in order to generate the right code. Not just millions of lines of code that don’t mean anything.

Danish Naseer: Awesome. Maud, my question to you: as we know, we just simply need to put in the prompt and we have the code. We can have the prototype very quickly. How do you see teams becoming overconfident about the AI-generated code?

Maud Nalpas: Yes, so as you say, it’s an amazing tool. It’s amazing to see how quickly you can get to prototypes which might have taken days before. So what we see is, I think by default AI agents still take what I see as the path of least resistance. So sometimes the output kind of looks finished, but you look under the surface and actually under the hood it’s really prototype quality, which can mean several things, or sometimes not so much under the hood. But I think by now as a community we know that, because AI really has made its way into our everyday workflows, so we know the risks. Experienced engineers, or even less experienced engineers who are cautious, we know the risks, but I think sometimes we will still ship that, and it’s not necessarily overconfidence. Sometimes it can be a desire to just ship fast, you take shortcuts, and this is human.

And another case is just not having the skills maybe to double-check the AI outputs. We know we’re supposed to, but sometimes you don’t have the skills. My background is web, that’s my expertise, and there are things which historically have been difficult for engineers to do. So if you think about accessibility or security best practices, or even just modern web development, even just modern CSS, all these things, not everybody has the skills to double-check the AI output. And I think it’s really more of a potentially missed opportunity, even more now than it used to be, because now the agents can have access to all this knowledge and help you build things. But I’m optimistic. I can see around us in the ecosystem you have a number of initiatives, like I’m thinking about Anthropic’s agent skills, to help you build solid shippable code. And my team at Chrome is putting together modern web guidance, which are skills specifically to help you include modern web development best practices into your applications.

Danish Naseer: Let’s discuss ownership and responsibility. Luca, my question is to you: when an AI agent makes architectural decisions alongside a developer, who should ultimately own those decisions?

Luca Mezzalira: The developer, without any doubt. The problem is that taking a decision is never a problem. Taking the right decision is the challenge. So I don’t think architecture is meant only for machines. It’s also meant for a socio-technical system. So when we think about architecture, you never look holistically at only the best practice or the best architecture or the best pattern. The thing that you need to find is the least worst trade-off, because architecture and every design decision are all based on trade-offs. Therefore, it’s very important that when you are asking AI, okay, I’m thinking about this, or how would you design these things, you validate that that will work inside your context, because context matters. Not every company is Spotify, Netflix, AWS, Google, whatever you want. Therefore, you need to deal with things that are at your own level, at your own context, that make sense for that.

And sometimes this decision might be, to a certain extent, not the best one that you can find. That doesn’t mean that it’s the wrong one for your context. Therefore, unless you understand properly the context, you cannot delegate to AI, because AI will provide you, based on the information that is available to it, that basically is your codebase or other things. And if your codebase is not polished and well thought out and well designed, it will just continue to build upon it and therefore create more noise and anti-patterns and wrong decisions inside the architecture. Therefore it is imperative that we own the context, we own the architectural decision, and we try to express it the right way with AI.

Another thing that I want to highlight, in my opinion, is that it’s very very important also to socialize architecture, because a design decision that I make inside my team might impact other teams. And unless we socialize that and we share it properly through requests for comments, architectural decision records, and many other collaborative tools that we have learned over the years, that is going to be a problem in the long run when we discuss who owns the decision.

Danish Naseer: My follow-up question is related to, we can see, does code review still work when an agent can generate thousands of lines of code in a minute? Is it for me?

Luca Mezzalira: Yeah, just look. Yes. So I think reviews are still valid. Currently I’m consulting, and I think it’s very interesting the way it’s happening, because we are a small team but still we are dealing with reviews, not probably in the same way that we were doing in the past where you were checking every single line of code. I think it depends on the type of implementation you’re doing. Let me make an example. I think it’s less, if I’m creating a PR for, I don’t know, integrating an SDK, when I know what is the input and what is the output, probably it’s more than enough for me that even if I’m using a not-optimized for loop in JavaScript that is not the one that will squeeze every single millisecond out of the system, it wouldn’t matter, because we are in a position where computers are great, and the solutions are great, and even our mobile phones are way better than when I started to work on mobile phones 20 years ago. So I believe that that matters less.

But if you are in a core domain, what DDD is suggesting, so in an area where you really need to master, which is the main reason why a company exists, then yes, then co-designing with AI matters, and it should be an imperative. Everyone should spend time to deeply understand what you’re writing, not at the line-of-code level, but understanding how it evolves. Especially if you are working as a consultant with other companies. If someone is asking you, oh by the way, do you think that we can add this feature, you need to understand how the architecture works, you need to understand the core part, how you could integrate it without creating an unreliable software or something that doesn’t scale, or whatever other architecture characteristics you want to apply.

So for me, we shouldn’t have one solution that fits them all, based on the shades of our software, where in some parts you need to spend time and understand properly how the code is generated, and when instead you are in an area that is less important, you can have a more relaxed way to handle it, and maybe delegating more to AI. So for me it’s a spectrum. It’s not, oh, we should always check every line of code, or we shouldn’t. Because to be honest with you, we didn’t, even before. There were certain refactors, certain things that were trivial, you don’t even check everything, okay, I give you a stamp, go on. But some others instead are extremely important, because that is the reason why people are buying our software or subscribing to our system. So it’s very very important that we provide the right emphasis to different areas of a software.

Danish Naseer: Awesome. Maud, my question to you: what should developers actually verify before accepting AI-generated code into a production codebase?

Maud Nalpas: Yeah, so 100% agree with Luca’s position, and I think my take is going to be very similar in the end, like with a web angle. So I think as human authors we still own all of the code that we submit and that ends up in production, like 100% of it. So we have to be able to, as a team, because everybody has a different expertise, but we have to be able to explain it, or debug it, or vouch for it, and otherwise it’s not ready to merge.

So to give a couple examples concretely, for a web application, what is core, what is really important to the end user. You’re going to want to be checking security headers and privacy, not necessarily yourself, but a teammate who has that expertise is going to have to make that check. UX consistency, which by the way is also important for security, we know UX has direct impacts on how secure or not an application ends up being. Performance, the performance of the web page, with metrics that have been available for years now like Core Vitals, and for this hopefully teams already have guardrails in place and rules for regression. If your performance really degrades, well, it shouldn’t ship, but hopefully it’s something you already have in place if you’re a web shop for example. Back to Luca’s point on what’s core to your business, if you’re a web shop you really want great performance, if you’re a blog maybe that’s okay. Accessibility, of course, always a big topic. So none of that is really new, but I think there are common traps and there are places where we really cannot let users down as web builders.

But there are also things, to the question specifically, what should you check before committing some code. I think right now one thing that has changed is you want to be, you’re not just accountable towards your end users but also towards your team. So you’re going to be checking shared team rules. Maybe you have shared AI agent or coding agent rules, like agents.md or Claude, like what are the repository instructions you want to follow to make sure you’re being a dependable teammate. And of course that’s always been a good practice, it’s also not new, but it’s more difficult to do now. You’re going to keep your changes small. And by this I mean not just the PR size as Luca mentioned, also just PR descriptions. Like I’ve seen things where if your team is still doing, maybe alongside AI-based code reviews, human reviews, which it should, make sure the PR description is actually written to be read by a human.

Because I think things that are super verbose, where I land on a PR and I’m like, what is this supposed to review, how do I reproduce, I think verbosity is a new danger. And sure you can configure that, but defaults are very sticky, and I feel like at the moment the verbosity of it, for agents it’s kind of cheap, if you forget about tokens it’s kind of cheap for agents to be super verbose, but for humans we would never write such a long PR description because it’s so costly for us to write good text. And this is something I would really love to see change. If you’re my teammate, please, and this doesn’t happen on my team, but I’ve seen it around, I think as dependable team members we owe each other to prepare PR descriptions that are actually readable. It’s going to really save everybody some time. So this is another thing I would check.

Danish Naseer: Perfect. Luca, I would like to know your perspective on the same question: what should developers actually verify before accepting AI-generated code?

Luca Mezzalira: Yeah, I mean, not every time, as I said before. I believe that there are certain things that, even if the code is not perfectly written and there is overengineering that happens, especially if you don’t provide the right, it depends how you work, prompt, or product requirement document, or whatever you’re using for feeding your coding agent with information, it won’t hurt anyone. And I always take into account how often I need to deal with that part of the system or not. There are inevitably some parts of the system that have a high rate of change in code at the beginning but then you keep the lights on for the rest of the life cycle of a system. There are others instead where you have a high churn of code because things are changing very often from external signals, could be business, could be the environment, whatever. And sometimes you have many ideas that you want to try and check, therefore even from internal signals like product requirements, new tests, or whatever.

So code is not equal across a system. Therefore I would provide more emphasis, more time spent on specific areas of the system than others. And there are certain areas that, I go back to the integration. Integration was painful because you need to read all the SDK documentation, you need to understand how it works, you need to understand the quotas, you need to understand the limits of the service that you’re integrating. Nowadays it becomes trivial. And I think that is the beauty. But you need to ask the right questions in order to design the proper integration. So first you would do that part, but then code-wise it’s not going to change the world there, even if you have high volume. Now with asynchronous programming and asynchronous architecture you can hide the complexity very nicely, you can reach incredible numbers without much effort.

Danish Naseer: Great. As we discussed about ownership and responsibility, Maud, let’s discuss something related to testing and reliability. You have been looking at AI testing and evaluation workflows. What does a good evaluation process look like when you are testing AI-generated software rather than deterministic code?

Maud Nalpas: Yeah, so I really love that topic and that question, and I think it’s still overlooked by many of us who’ve been writing software traditionally for a long time and now we’re in this new era. But I think there’s a lot between traditional web testing, or general software testing, and AI testing. What you’re going to want to do, if you want to test AI-generated code or even AI-based features which don’t necessarily generate code but might generate text or features that are facing end users, you’re going to want to be combining rule-based evals, which are really deterministic checks and they work really like unit tests. You want to check requirements programmatically, whatever JSON structures or regex checks or contrast rules, anything that you can check deterministically. So you combine that, which works really like unit tests, with approaches for subjective checks that use a technique called LLM as a judge, which is really just a way to come as close as we can to automating human judgment. It’s a bit of a shortcut when I say that, because you can’t automate human judgment, but you can try, and this is the best technique we know today to do that.

So for this technique, LLM as a judge, basically you use a model that evaluates an output against a rubric. A rubric is like a scoring sheet that has been put together by human experts ideally. And so basically you give that scoring sheet to an AI model and say, hey, use that to grade the output with a pass or fail. So for example, for code generation, let’s say you are generating code that is going to generate tool descriptions for a web MCP or an MCP integration, are the tool descriptions unambiguous? This is something you cannot really check deterministically, but you can ask an LLM judge to judge and assess based on the scoring sheet that has been put together by humans. So that’s basically the gist of putting together evaluations.

And then you will put this all together in an evaluation pipeline, which is like a testing pipeline really, and you can think of it as layered like a testing pipeline. So you have unit tests, like rule-based tests I talked about, which are deterministic, so they’re kind of fast and cheap. These you can run on every commit if you want. And then you have tests that are more costly to run, these LLM judge subjective tests. So this is a bit more like integration tests. So you’re going to want, maybe for this you definitely don’t want to run them on every commit, so you can do maybe a nightly test or release test. And there’s also a technique, by the way, which I think is really exciting. I mentioned LLM as a judge, so you call an LLM to judge an output, you can do that using a cloud model, but it’s also possible to use a locally running model, which I think is really interesting to shorten the time to response, and it’s an area I’m really excited to see some more emerge there. I was experimenting with this myself and I think it’s really promising.

So yeah, that’s really just a gist of AI evaluations, what we’ve learned on the Chrome team, what we think works well. It’s ever evolving and ever improving. And I’ll paste, we’ve put together some resources, so I’ll paste some of them in the chat for you to learn more. And if you want to chat about evals, please ping me. I’m always happy to chat and learn how you do your evals yourself.

Danish Naseer: Awesome. I can see in the chat there are some good questions. The person is asking, Ali Arif is asking, if AI generates most of the code, who should ultimately be responsible when that code has a security vulnerability or production failure? The developer, the AI engineer, or the organization? I think we can start with you, Luca, then I would like Maud to add.

Luca Mezzalira: Absolutely. It’s not because it was generated by AI, and you didn’t check and you didn’t spend time, that you are, oh yeah, it wasn’t my fault because I just approved the PR. It was exactly the same as before. So when someone was forgetting about an API key inside the code and that was propagating across the web, it was a physical person that you can say, yes, it was John or Jack or whatever, but still the problem was a company problem. If there is a third party that is working behind the scenes with a company and the service is down because of the third party, the company cannot say, no sorry, it’s not my fault, it’s the third party. They say you are responsible for that, whether you like it or not.

Now that’s why also we’re going to change how we’re going to use AI when we are coding. So we are talking about loop engineering, harness engineering, and all the different checks. So it’s not that we forget completely the last two decades, we just need to double down on what we didn’t have time to do, that was planning, designing, thinking about the security part, researching on the feature, understanding product. Because now we have the time, and therefore there is no excuse for me to avoid that part that is the initial part that enables you to then design the feedback back to the code assistant. I’m implementing different types of testing, as Maud shared before, but also if you think about static analysis, you want to make sure that your code makes sense. You don’t want to have a cyclomatic complexity of 50 for every function, you want to have a cyclomatic complexity of less than 10. So these kinds of things matter, and before, we had no time, now we can configure these tools through AI that is way faster, even dependable.

That is something simple that deterministically just changes and upgrades all your packages with security fixes obviously embedded. You can do that configuring, the last time that I tried was 20 minutes for three repositories that I configured Dependabot in the way that I wanted, open a PR every night and receiving a digest via email. There is no excuse anymore. Now we just need to use the tools and understand properly how the software development life cycle works. My recommendation, to be honest, is something that I’m doing very often with customers, is try to map your software development life cycle. Think visually how do I work from the ideation of a product feature to going to production. I can guarantee you that we see so many spots that your team or your organization could tackle to improve the quality of your output generated by agents drastically. There is no doubt about that.

Danish Naseer: Maud, your perspective on the same question?

Maud Nalpas: Yeah, I was just dropping a note in the chat. I’ll agree again. I think the answer to that hasn’t changed with AI really, and generally I’m not a fan of fingerpointing and individual blaming unless you have a rogue actor, or a training issue. I think generally I really like the culture of postmortems, and using, if you have a security vulnerability that has made its way into the product and that has been discovered, well it’s a very good opportunity to review your current processes. Are there automated guardrails that we have, we have so many tools at our disposal today, it’s amazing everything you can do nowadays in terms of security checks. You also have human processes in place to make sure, maybe there’s also a human security expert who reviews the code.

So I think the answer to the question really hasn’t changed. Maybe the pace and the risk is changing. I think also, as MCP has become more widely available and agents are making their way into a wider audience’s hands, we have more security threats that are appearing now. You have all the risk of indirect prompt injection, so all of that also needs to be checked. So if anything there’s more danger, but also so many more tools at our disposal to do the right thing. And I would agree with the framing that there is no excuse. But I think security is difficult and it’s cryptic for a lot of teams. Maybe if you’re a smaller organization maybe you don’t have the in-house expertise, but now you have the tools and ability to learn and ramp up. So I’m optimistic.

Danish Naseer: Awesome. So audience, as we know we have an architecture expert, AI expert, Luca with us. My question to you Luca: AI can produce code that is technically correct but architecturally wrong. What are the architectural signals developers should look for?

Luca Mezzalira: It happened to me quite often in the past six months, that I asked for one thing and when I was reviewing the code I said, okay, why? But very specific things. Once for instance I was creating a cron job and I asked to write some code on a Lambda function, and it structured the code with a hexagonal architecture. And I said, okay fine, I wrote about that several years ago when I was working at AWS, and I described how it works in Lambda, but I didn’t expect that it would use that implementation on that Lambda. I said, listen, but this is completely overengineered. I had to do a refactor because that was solved in 50 lines of code moving data from A to B, and that was pretty much the purpose of the Lambda function.

That’s why very often I say it’s very very important you understand what you want to express inside the system. The best way for me to validate that the architecture is there is starting from an architectural decision record that forces me to answer a bunch of questions, write them down, and feed forward my coding agent with what I want to express, because if I don’t do that it will do whatever it wants. And then I can also use the same ADR to check on the other side, when the code is output. I can add a review agent that says, okay, take my ADR, this is the output, does it match, does it not match, what is changing, what is the drift, and stuff like that. That is how today I’m working. Before I was more naive that, you know, I don’t provide an architecture but I didn’t expect to have something extremely complicated or completely overengineered. Because if I would go ahead in that direction, the next Lambda it will be based on the exact architecture that might or might not be wrong. But the reality is what I want to express, and every architecture has characteristics behind that, and I want to be balanced around what I want to use and when. So using a single way for doing everything, for me, is wrong, because there are so many nuances that we can express inside software. So let’s use them properly and try to understand first what we want to express, then trust me that if you use a reviewer to check what the output is against something that you produced, it would be top-notch.

Danish Naseer: Awesome. As our audience is mostly developers, let’s discuss the developer’s changing role as well. So my question to you Maud: for developers who are starting to work with coding agents today, as we also hear, like “AI will take my job,” what is the one skill they should develop that AI will not make obsolete?

Maud Nalpas: So I think it’s an opportunity we have in our hands, and we see the power of the tools that enable us to generate AI code. And I think Luca also described the fact that we have more time on our hands, although it doesn’t always feel like that, because so many more things are possible, so you end up building a ton of stuff, not necessarily what you should be building, but what you can build. But I think in terms of our changing roles, I think we’re living it right now. I think we’ve moved from typing code to already orchestrating agents potentially. So what’s going to be really important, what’s going to remain really important, is critical thinking. Think critically about what is it that you’re building. Take some time to use the agent as your sparring partner and think together, what is it you’re designing. Have that conversation not just with the agent but also with the team around you.

The second bit, sorry, I think you asked me about one thing but I’ll add one. I think evaluation, AI testing, is such an important skill. I feel like it’s still underrated, or maybe overlooked at the moment. And I understand, I think there’s just so much going on in the ecosystem that maybe it’s not given the attention it deserves. But I think as more AI-based features and AI-generated content makes its way into the hands of end users, this is going to be a growing topic for sure. And finally, UX. Agents can help out, but I think human empathy and UX is something that, I could be wrong, we’ll see how the opinion ages, but I think it will remain extremely valuable. So basically I think those are three things, but that would be my answer.

Danish Naseer: Awesome. So my question to both of you, and I would go first with Luca: would you rather have an AI agent write 90% of an application that you review, or write 30% by yourself and understand every line? Going first with Luca.

Luca Mezzalira: Ideally the former, but in order to achieve that I need to create a harness that will help me to create confidence in the output that it generates. I don’t mind writing code. The thing is, I think there is a feasibility to govern that code properly, but it means that there are a bunch of things in different disciplines that I need to master, or at least understand, and then I iterate on them till I reach the point. Secondly, sometimes you need to write more code than the AI, not because AI would do a better or worse job than you, but because you need to understand what’s going on inside the system. I strongly believe that not every single line of code is equal. It depends on the area of the system, and therefore there are certain areas that you need to spend more time on than others. Even in a future, maybe you can say infrastructure as code, easy, that’s just configuration, it’s a YAML file, so you just check that everything is working, maybe you add a linter to make sure that everything is secure and locked down. But at the same time you might have some specific feature that requires a bit more challenging implementation, and you want to lead that part. You might not write all the lines of code, but you want to co-design that part of the system together with your coding agent.

Danish Naseer: Maud, your opinion on that question?

Maud Nalpas: My opinion is going to be, it depends on what I’m building. If it’s a prototype, whatever, I think it’s okay, unless it’s the age-old adage of, you know, starts like a prototype and then it ends up in front. But if it’s a prototype it’s fine, depending on the purpose of the prototype of course. If it’s just to really showcase a feature, I think it’s okay to have 90% written by AI. But generally, for anything that actually ships in production, I definitely take writing at least 30% myself and having 100% intellectual control. Again, not as an individual necessarily, but as a team. It’s not to push over the responsibility, but it’s just to highlight the reality that we still work as teams. So a single individual cannot possibly have all the skills and expertise necessary to audit every single line of code. We need to work together on that. But core business logic, yeah absolutely, you want to have 100% ownership, so it’s a good idea to write some of that code. And in practice, I think this is what we’re observing for most of us who are working with AI day-to-day, you do end up writing some code, and it’s a good thing.

Danish Naseer: Awesome. My last question to both of the respective panelists: what responsibility should never be delegated to an AI coding agent? Starting with Luca.

Luca Mezzalira: Well, never delegating, I think, the architecture decisions on how you want to structure certain things. I would rather that be a human providing them, because we understand the context. Because if we see it in a vacuum, I need to implement something simple like a service that sends an email to a user, in a vacuum you can implement it in a million ways, and probably there is a best way, but it might not fit your use case. And your organization is a snowflake, whether you like it or not, and very often replicating what another organization way larger than you is doing is not the best way for you. I have witnessed talks from people saying microservices are evil, microservices saved my company, and everything in between. And similarly for monolith, modular monolith, whatever other technology you want to put, it’s exactly the same thing. Why? Because we are working in an empirical system or environment that is software, where with the same requests or requirements we can build in completely different technologies, and both of them are right or both of them are wrong, and we need to accept that.

Therefore, the only way to make sure that what you are building is what your business needs is understanding the context. And now there is no excuse anymore, because time is there for understanding the business, understanding product, understanding our users, and understanding all the things that are needed in order to build our software. So now is the best time, in my opinion, for building great software with the help of AI.

Danish Naseer: Perfect. Maud, your response?

Maud Nalpas: So the question is, what should never be delegated, what cannot be. Just taking a step back about what cannot be delegated, it’s accountability towards your end users. So again, on the web, I’m going to bang that same drum, but that’s really core to what we do, is safety, security, UX, trust, which by the way drives business too. It’s not just for the sake of user trust, which is also a noble goal in itself. So accountability towards your end user, you cannot delegate. You still own 100% of the code you ship. And another thing I was ending on earlier, I think, accountability towards your teammates.

At the moment there’s a bit of a craze with that discourse of the image of the solo developer with their army of agents running and their super powerful Claude setup, and they can do the work of a 10-person team. That’s quite popular, and it’s a thing, but mostly we’re all still working as teams. So most of us, we work as software developers working with other software developers, or with UX designers, or with product people, with DevOps. We’re all the system, and I think we’re all accountable towards each other, and you cannot delegate that. So this accountability is really core, I think, as a software developer, but also in all other functions of a digital product. Product folks have a lot of tools at their disposal to maybe produce more design documents, but they need to be solid and readable by humans as well. So I think that accountability really is on the whole spectrum of the tech jobs.

Danish Naseer: Awesome. Thanks so much for the answer. I can see there are people already asking a few questions in the Q&A session and in the comments as well, but I think we are right on time. We have another activity lined up. I would request both of you to stay active in the chat so people can get answers to their questions. So there are still a few questions that you both can answer, and I would again thank you both for attending this panel discussion. We can conclude this panel discussion and leave it to the audience if they want to discuss something else with you both. The chat option is here, the Q&A option is here, we have both Luca and Maud in the chat option, so you can ask your questions. We are completing this panel discussion here. Don’t go anywhere, we will be right back for the amazing activity. As you know, there are not only sessions and panel discussions, we have giveaways and activities as well. So stay tuned. We will be back with our first activity of Prepathon 2026. Stay tuned. We will be back.