Presentation: Panel: Who Builds the Frontend Now? (And What Breaks When They Do)

InfoQ Homepage Presentations Panel: Who Builds the Frontend Now? (And What Breaks When They Do)

The panelists explain how AI tools and vibe coding reshape frontend and mobile engineering. They share insights on evolving junior developer roles, managing AI-generated code review fatigue, designing systems for autonomous agents, enforcing architectural guardrails, and navigating economic shifts in open-source software sustainability.

Luca Mezzalira is an independent software architect, consultant, and educator. James Hall is Founder and Director @Parallax and Author of jsPDF. Danielle An is a Principal Engineer at Meta Horizon. Ivan Zarea is Director of Platform Engineering at Netlify. Panel moderated by Ian Thomas, Software Engineer @Meta.

Software is changing the world. QCon London empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Presented by: David Iparraguirre - Senior Product Marketing Manager at Datadog, and Jessica Yang - Product Manager at Datadog

Thomas: We're going to have a bunch of themes that we're going to explore together around the topic of the day, emerging trends in the frontend and mobile.

I just wanted to frame a little bit the landscape of what we're talking about here today, where we have this imbalance between adoption and trust, which is quite drastic. A significant drop in entry-level roles, framing the career growth aspect and thinking about what does it mean to be an engineer joining the ladder or being at the more senior end of the ladder these days. Then, what does it mean for us all if people can go and spend $1,000 in a week and rebuild one of the most mature frameworks in the frontend space with apparently very little effort? The three areas we're going to look at, the changing job, building for agents, and quality and trust.

Danielle An: I'm Danielle. I'm a principal engineer at Meta. My job is about essentially evolving the social gaming platform that we have into the AI era. A lot of mobile development, a lot of UI, UX, scaling into the hundreds of millions of people that use our ecosystem.

James Hall: I'm James. I run a company called Parallax. We help organizations build teams to build tech. I wrote some popular open-source Node stuff in the past, like jsPDF and things like that. We just help people build tech quite quickly.

Luca Mezzalira: My name is Luca. I'm a serverless specialist solution architect in AWS. Why I'm here? Because in the last 10 years, I mastered the idea of distributed systems on frontend. Wrote a book about micro-frontends. Currently, the architecture is embraced by the largest companies in the world. Think about Formula 1, PayPal, all the others. They're all drawing from the experience that I describe inside the book and very often they refer to. That's why I'm here.

Ivan Zarea: I'm Ivan. I am a director of platform at Netlify. My responsibility is hosting everything, including some of your personal projects. I'm on call for some of them. We're also working with a bunch of framework authors, open-source communities, and making sure that things are evolving in the web framework space.

Thomas: A year ago, vibe coding was a tweet. Now Y Combinator are saying that their last batch shipped 95% AI-generated codebases. With that in mind and the changing landscape of entry-level frontend roles, I'm really curious how you're seeing these changes impact the hiring and the training and the landscape for you internally in your companies and how you're thinking about what frontend engineers and developers really need in this day and age.

James Hall: I think we need both ends. We need super senior, experienced people who've got all the battle scars. Then you also need the naive junior engineers who have only known of a world where ChatGPT exists. Because they try things that you would never think to do. They approach stuff in a very different way. They don't have those battle scars. It's like blending the two levels of experience, I think, is really important. I know a lot of people said that the junior roles are going to go away. I'm not seeing that at all. I'm seeing very much a need for it, actually.

Thomas: Have you changed anything around your hiring profiles that you're looking for?

James Hall: Yes. We actually allow people to use AI in their interview process, which is a blessing and a curse. You can sometimes see people really struggle with that, because they're trying to talk to and understand this huge stream of output from an LLM. It can actually be quite off-putting for some people to try and talk through that. Some senior engineers you see quite struggle with it. We've had to be quite pointed about how we test people and do a little bit more whiteboarding, a bit more conversation, like you used to, I suppose. Less of the like, can you code this thing in an editor?

Thomas: How are things looking from your perspective as a senior principal solutions architect?

Luca Mezzalira: I can tell you that in Amazon, in general, we have a lot of mid-level senior engineers on the frontend side. I speak with a lot of them. Because very often, when they are building their solution, they are looking into implementing micro-frontends.

Therefore, I have the possibility to work with them very closely, even for migrations towards that topic. I think that, at least for us, is not going away at all. Even the CEO of AWS said very clearly, we are going to hire.

The CEOs on the architecture side in my division, we are still hiring a lot of people coming straight from university. We are training them. The thing that I think in Amazon works always pretty well is the fact that we have mechanisms for mentorship and for helping others that maybe don't have the battle scars, James was saying.

That I agree, it's not an easy thing to find. Having a mechanism, being intentional, basically, helps a ton.

Thomas: With the widening range of people building frontends, and this is going to speak directly to what Ivan was sharing earlier, how are you thinking about access to non-technical roles within your organizations, and how that's being coached and developed?

Danielle An: When you say non-technical, are you talking about non-engineers?

Thomas: We're thinking about anybody that might be interested in building a tool. It could be any department. We've had examples in Ivan's talk from people in HR, the CFO. We've got product managers. The list is almost endless as who's got access now and capability.

Danielle An: In my field, like I said, it was more like gaming and immersive content. I work with a lot of artists that are here, designers that are absolutely not coders, no offense, but now who are vibe coding their ideas in a few hours or in a few days. That is really impressive to all of us.

In the content space, it is visual. Games are about if it's fun. Whoever brings the ideas into other people's minds and into other people's hands where you're enjoying it, wins.

It doesn't really matter if you're technical. I think definitely in my day-to-day, I see a ton of opportunities for anybody who is a coder or not a coder. I also think frontend is particularly interesting.

We do not necessarily want the amazing artists to vibe code the trust and privacy issues in the backend. A lot of the frontend development that directly goes to the users, I think this is just a huge amount of opportunity.

Also, vibe coding nowadays, we're joking in the team, we'll just take for granted it's going to work on the frontend for the most part, especially if you're prototyping. If you're trying to get ideas across, you're not thinking about something scaling into the billions where there's lots of account issues and lots of stuff that needs to be worked out. If you want to bring ideas, prototype your app, something you're imagining, something you are stuck in traffic and you think this will really help with that, and you go home and you vibe that, there's just a ton of opportunity for everybody.

People that have the right ideas, even if you're not a coder, you can pretty much use Claude to get 80% there. Maybe you need a little bit of help, you got some coworkers to help out with that. I just think there's a ton of excitement there.

Ivan Zarea: We also see this trend. For example, our UX team vibe coded a NPS survey that actually integrates within our app very well and is not like a third party that is integrated through an iframe or something like that. There's lots of opportunity there for people who are domain experts to actually leverage their domain expertise.

One challenge that I see with that, and for us as a community of engineers or as frontenders is what that done means, because to someone who is not an engineer or doesn't have that engineering expertise, to them it works on my machine, or it works in my Claude is kind of done. Then you either get the engineering team overwhelmed with a bunch of pull requests to review and like, who do you give the comments to? Is the model going to fix them or is the UX designer going to fix them?

Additionally, it creates debt, it creates a mess that we will need to figure out how to maintain. It forces us to get our stuff together and figure out how do we want our frontends to evolve given that there's a lot more people contributing to them who are not necessarily the same level of skill. Additionally, that's not only applicable to frontend engineers.

It is very easy for backenders to be like, how hard can React be. I can just vibe code this thing and then you end up with a couple of Redux actions and here you go, what up? As anyone who has maintained a large codebase knows that there's a lot of debt that comes with that.

There's a lot of architectural challenges that comes with that. There's a lot of deep expertise in the frontend space that is not immediately visible and that is hidden behind like, this is the frontend that you build. We do see this challenge as well, not only coming from non-technical people, but also just non-frontend people who do not have that deep expertise in the frontend space.

James Hall: I think one challenge is that it sets people's expectations of the speed that you can move in a large enterprise incorrectly as well, because enterprises are set up to do careful checks, do testing, SOC compliance, ISO, all that stuff that you need to keep your organization together. When someone from a non-technical role can vibe code an entire five-step onboarding wizard in an afternoon, they think, surely, we can make the rest of the process happen in a couple of days to get this live, and it's just not the case. This is where we're butting up against legal, compliance, testing, QA, all that stuff. It's like, if you optimize one bit, how do you optimize all the rest of it? That's where we're going to see a real challenge.

Luca Mezzalira: I think very often we try to think about, ok, so vibe coding, therefore I can create software. Coding is a chunk of the software. In the software development life cycle, there is a tiny portion that is called, ok, we need to write some code.

There is the 80% or more of the software development life cycle that is not coding, and therefore we need to be aware of that. I think, probably I'm a boring architect, but we need guardrails that prevents us to arrive to a point where we really think that a PM can write code that is perfectly aligned with all the best practices in the company that can be integrated in no time into a system. We need to be careful on that.

Every context has some rules, every context has some difficulties and challenges. Working in a regulated environment that requires a certain level of resilience, capabilities, throughput, latency, is not the same as creating a website for an expo or a conference.

It's completely different. Very often what I'm noticing with customer backend and frontend doesn't really matter, to be honest, is that they don't ask the right questions. Currently, I think the industry is hidden behind the idea of, we can vibe code whatever.

Yes, but this whatever, it might not be inside your context. For instance, I really like talking with Malte Ubl, the CTO of Vercel, their process where they say, ok, we created V0 for design and developers. In reality, we created for PMs, because their PMs currently, they are thinking about a new idea or a new feature.

They create a mock with V0 and then they pass the ball to the developers, but they create strong guardrails on that. You have an idea, you can show how it would look like, how it should feel so you can realize what works, what doesn't, and that's the first feedback loop that we have.

Then we have the second one that is moving into production, and production is not straight away what, let's say, is just some code. Production is way more because there are a lot of checks. Probably you can tell quite a lot of stories operating Netlify at a scale that is incredibly difficult. It's not a walk in the park.

Thomas: I saw an interview with Peter Steinberger, the OpenClaw creator, who said that one of the things that his tooling has provided is the access for people to contribute, and the overwhelming nature of PRs that he gets on his project is overwhelming. The thing he does is he doesn't take them verbatim, he takes them as prompts and intent, and then translates that into what his vision of the product should be. Do you think this is potentially a way of working that we should be doubling down on or is this something that we're seeing as a nascent practice so that PMs and designers and folks can have their input but it's taken as a guide rather than the final artifact?

Danielle An: I feel really passionate about this one, because again, I think gaming is just about if it connects with people. Usually, so much gaming content is the first 20 seconds, are you interested or not? If you're not, you have moved on.

I think a lot of what you're talking about is how do we bring prototypes into production, and this makes the product actually sticky. I think right now, probably at every company, what we see is everybody's like, look at the shiny thing I did. Day and night, 24/7 with Claws and stuff like that.

I think what's tricky is that everybody can build to a certain depth. Like, this is cool, but it's only cool once, it's only cool for the first minute. Then going beyond that, which makes it something that lots of people really want in the longer term or lots of people would want even just for days, I don't think that problem is solved because we can vibe code.

I think it just brings a lot of creativity to the surface where anybody can be like, look at my puppy, and I put something on my puppy, isn't that funny? Like, that's great. Beyond that, the next level of creativity that people really want and we all crave, I think still, it needs to be cultivated. Vibe coding just removes a barrier, but it doesn't suddenly make everybody have this genius idea that connects with everybody else. I think it's a bit of like a bubble, a little bit of a hype.

Thomas: How many people are working in consultancy versus in an in-house team building a product? Given what you said before about expectations have been reset to be super-fast, what does that mean for the pricing model for a consultancy?

James Hall: I haven't quite figured that out yet. We still price based on FTEs. I think what it does do is it makes some projects that were seemingly unviable now viable. They might have priced it up, this is going to cost us £2 million. Actually, we could probably do it for $200,000. Why don't we quickly try and do that, test and learn, get an external outfit to do that. I'm trying not to be squeezed on price, but it is difficult.

Thomas: Let's move on to the second topic I wanted to focus on. Stefan's talk was going deep into some of the things behind computer usage of our things that we build. Keen to explore what happens when we realistically now serve two very different sorts of user.

You've got the humans, the people here, and the people that don't have feelings, emotions and cognition, obviously the rest of it, with the agents that are using it. In particular, one thing I think would be interesting to explore is, what does trust mean in this world? Because, for example, if we were to look at a product and the way we designed it, we aim for a polish and a finesse and a design aesthetic that shows quality.

What does that mean when a computer is interpreting it? They don't really have a concept of quality like that. I'm really curious how we need to start thinking as a cohort of people working on these clients and these mobile apps and websites.

What does it mean to serve these two different types of user?

James Hall: I think what makes it good for a user makes it good for an AI. I think you're seeing this wave now of MCPs blasted open the floodgates, people are opening APIs a bit wider than they would have, people are connecting more data sources than ever. Actually, the CLI interface is super handy, because I don't know if you would even try to attempt to write out an MCP JSON blob by hand, you probably wouldn't.

You would write Bash and you would pipe stuff and chain stuff. Actually, is the interface CLI, even if it is a virtual CLI? NVIDIA launched its sandbox CLI this week.

Vercel have just Bash, which is a TypeScript implementation of Bash. Yes, can we create these super nice to use for humans SDKs that are super nice for AI as well? I think we can.

You've seen Playwright MCP is now Playwright CLI, it's just come out. Loads nicer to use by hand. It goes back to all the good stuff that we used to do, like ReadMe driven development, like just keep it super simple, nice and easy to type, and that makes it good for AI as well.

Ivan Zarea: I'm going to slightly disagree here. I do foresee some recalibration happening in the industry where we do realize that there are certain tasks that agents are inherently better at than humans, because of the amount of processing they can do in the time. An example of that is, so I come from a platform background.

I look at charts a lot to see if things are down or not. It's very difficult to teach agents to look at charts and understand them, but that is how my brain works. I would rather teach agents to look at time series data, and they can do that very well.

They can look at a lot of time series data very quickly. This means that we're trying to design internal tooling to, instead of exposing human readable or human adjusted pre-aggregated signals, that actually there's a decision happening in the background of, is this signal going to be valuable for a human in order not to overwhelm the human?

We're able to expose like almost raw data. That is just one example of how I see kind of like, there's an interface that we thought would be better for humans, and actually for agents that there's a better interface. Same thing with some of the CLIs where if a CLI is interactive, it provides engagement for a human, but actually a simple long command is better for an agent. I do think that there's going to be some recalibration happening in exactly what you said about how do we define quality? Because this new cohort of users perceives quality in a different way. That doesn't mean we have to stop caring, but it just means caring for a slightly different audience.

Thomas: Trust signals are going to be massive. I'm curious about Danielle's view on this, because with a little bit of inside knowledge here, Horizon Worlds as a product over the years has evolved to have this very use case. UGC platform, people can come on, they can build worlds, they can build games, they can write the scripting. Then increasingly it's becoming AI first where people can prompt to do that. The AI needs to have access to all the capabilities that a human had. Is there anything that we learn in that journey that would be useful to help more broadly across the frontend and mobile landscape? Are there any key points that we hit where we decided something and then found actually, no, different ways is a better way?

Danielle An: I slightly disagree with you earlier, because I think that it is true, a lot of information agents can just see in raw format, even just in.md files is different. I don't read.md files as well. They do think differently.

In reality, in particular, you're talking about UGC, when something goes wrong, which only happens in runtime, the agent is not sufficient to solve those all by itself. You do bring a human and the human has to work with the agent at the same time, if something is not working. I think if we design things to be either more agent things in binary chunks or whatever else, but the human comes in and doesn't think that at all.

You're creating this barrier between the human and the agent collaborating when something goes horribly wrong. I think for UGC, things always go horribly wrong. Like the skirt is not tucked in and only under certain lighting, you would see a problem that looks like it's very inappropriate.

A lot of those things, I think, require you to think like, what did the agent need to understand that a human needs to debug? What also it can do that I don't care about at all, like data is not compressed or whatever, don't tell me that, just fix that. It was more something that is very visual, very runtime, very dynamic. Every run is unique. When that happens, I think the agent has to understand what a human needs, what a human is going to debug with, and how is a human going to look at this information, and help the human understand that. I think that's really important in our work.

Thomas: Given some of the things that have happened in Amazon recently where there has been agent accelerated SEVs, is there anything that we're learning about why agents can help us to make bad choices that we can put guardrails in, thinking more holistically in the way that we're building our guardrails and systems?

Luca Mezzalira: I don't have the full visibility on all the things that we are doing inside the engineering side, because obviously, as you can imagine, Amazon is a company with 1.8 million people. As you can imagine, it's difficult to have visibility on everything. That said, I think currently we are using heavily in general in our processes, agents.

We are betting on AI heavily. We also developed Kiro as a fork of Visual Studio Code and CLI. We started to see, especially internally, a lot of tools bubbling around, built by engineers or by architects for helping us to increase the understanding of our business.

In the latest few months, I've seen more tools than ever that started to bubble up in our npm repository of AI tools. The thing is, obviously, in order to operate properly, you need to have all your house in order. I have a few friends that were working in Meta and they explained to me how everything is automated, everything is well-suited.

I think Amazon grows organically. There are certain areas that work better than others. That's normal.

Therefore, I think AI can augment or potentially replace certain activities better in this area that everything is well designed and oiled properly. While in other areas, it might struggle a bit because it will rely on patterns that are already implemented, learn from those patterns, and might not be the best patterns that you can find. For that, you cannot expect that you have the perfect outcome as you think.

You need to first fix the issue, retrain, restart, and move on. This is good learnings for everyone, because the reality is not that AI will be, sprinkle magic everywhere and everything will be super amazing, unicorn everywhere. It will be an augmentation and it will help us to achieve more in a short amount of time.

It can replace certain parts of our job. We need also to think that, again, if we provide wrong input, we are going to have a wrong output, inevitably. They cannot guess what we have in our head or what is intrinsically expressed inside the trenches.

Thomas: That neatly moves us on to the next block, which is, who's responsible? If we're putting these things out there, who ultimately is the person on the hook for all this code that's suddenly exploding into production?

Luca Mezzalira: Claude. We put Claude on call. Whatever is called Claude, it will be responsible.

I strongly believe that we don't have to forget everything that we have done in the last 40 years in engineering. Especially in my experience in distributed systems, one of the key areas is that ownership is well defined. If you don't have clear ownership, then you don't expect that the system will work nicely.

There are certain situations, like when I see large organizations implementing InnerSourcing that is basically open-source practices, but applying inside private repositories or projects where even there you have a team that is leading the project that accepts and revisits certain requests or discussions, like you were mentioning OpenClaw, for instance. I think those are not that are fading away. Now, the thing that I personally think about that is quite hilarious to a certain extent, that I think we will achieve more with the same amount of people or potentially with slightly less people, we achieve equal throughput of the past.

James Hall: Who owns the code that they commit? It's got to be the engineer that commits it, you'd think. That causes a problem with AI fatigue, where you feel like you want to move really quickly, and you're opening PRs, getting colleagues to review, but you're having to review lots of other people's PRs as well.

I think, I can't speak for everyone, but by the afternoon, you're full up now, that's enough reviews, you don't want to look at any more code. In a lot of organizations we've been working with, keeping the PR size really small has been extremely important. In fact, for some high-risk repos, 200 lines is the hard max, and that can be a little bit painful, but, for the right reasons, it's to make sure that everybody understands what's going on in the codebase.

You've got someone else rubber stamping it. We use policy-bot, which is a GitHub project, quite widely, and we have team review and then risk review. It's tricky.

The risk levels are going to be very different. If it's like a conference website, you might be able to just vibe the whole thing. It's probably ok, except for the registration form, maybe don't do that.

Danielle An: What I observe a lot nowadays is that engineers are not actually reading the code at all. When they check in, the other engineer also didn't want to read it, so they just all assume if it has passed, I just move on. Of course, like you said, that's ok for maybe QCon Conference, but that's not quite ok for a lot of things, like Meta, for example, does. I'm curious how you guys are enforcing that. It just seems impossible to enforce. I just see engineers fly by diffs like 20 a day, like nobody read this. It's like thousands of lines. How are you dealing with that?

Ivan Zarea: More specifically in our organization, there's a couple of things. On one hand, we also have helper bots that help review things. Also, we're investing in cross-service knowledge context that allows for bots to review things in a way that is context aware of how it affects other things.

It's like a review with larger context, more like an architectural review. Finally, we're doubling down on in-person whiteboarding. We are a distributed company, so that makes it very difficult for us to meet.

We do see that right now the speed of shipping has increased. That means that we need to be even more focused about drawing boxes and arrows and more disciplined about that. That is where the review and the brainstorming and the magic happens.

Then the code implementation is a byproduct of that.

James Hall: I'd agree with that. Something else that we found quite useful is getting different models to do the reviewing than the models used to write them. Gemini for review, let's say, and Claude to write it. Gemini, we would write a file for it, which is based on the last hundred or last thousand PRs that have been merged. You can get Claude to just go and grab all the comments and all the nits, each team have got their own style, and try and encode that as well as possible into the review guidelines. Then when someone's reviewing it, it looks and feels like that project. It doesn't look like it was written by Claude.

James Hall: Only for review time. Maybe it doesn't.

Ivan Zarea: If you've ever had a conversation between a Gemini and a Libra, then you would understand that they do not work well together.

Thomas: It's interesting, I guess to a point you made earlier, Luca, about that we shouldn't forget about the things that have happened in the past. I think the DORA reports from the last couple of years just reinforced that. We see now that, yes, there's greater throughput, but the size of the batch is bigger.

We know from many years of research that that leads to poorer engineering outcomes. It comes back to that tension again between the engineers may have had this training and this experience. There may be a new batch of engineers that don't get that experience, which is partly what this Anthropic report around debugging skills reducing in more junior engineers because they're more AI friendly.

Also, the whole cohort that we've talked about before about people who are not engineers at all don't identify as that. There's a big drop in people that self-identify as a developer now deploying to the platforms. I think there's this tension there that we still need to find some way to resolve, but it isn't clear to me what that path forward is.

Luca Mezzalira: Personally, I have a mental model usually applied with every enterprise customer that I follow. Again, I'm working mainly with enterprises, so take with a pinch of salt. If you're working at a startup, the practice could be different.

In my case, usually is a matter of understanding the team system and then understanding the socio-technical system. Plus dividing the system in subdomains and categorize them. In domain-driven design, there is this idea of core, generic, and supporting domain that you can assign characteristics to.

At my previous company, when I was working in DAZN, that is a live sports streaming platform, we categorize the whole system in these subdomains and we assign capabilities. We assign a certain seniority of developers based on the domain that they were working on. These things help us also to define these practices.

Because if I'm thinking in a generic domain or in a supporting domain, very often you buy more than building because are less important.

If you think about payment for Netflix, nowadays they build their own payment gateway, but in the past they didn't. They were just aggregating PayPal, Stripe, and all the others. This is integration.

The type of engineering practices they apply and the way you use AI could be heavy. While if you are building on the heuristics of the video player, that basically for a company like Netflix is the most important thing, because it's the reason why it exists, there you need to be careful because you cannot have heuristics that are changed randomly inside the video player because it could affect the experience for the user. As you can see now, if you start to segment your software into subdomains and apply different characteristics and approaches, then you start to have high throughput in certain areas and maybe you are more careful in others.

If you replay exactly the same example in banks, usually that's what happens. You start to identify certain areas that are more critical and you apply different techniques compared to others that are more lightweight.

Ivan Zarea: We do have a bunch of things here breaking in practice due to AI-generated code, and I'm curious, you mentioned that AI can cross-review itself or a different agent can review itself. Are there any practices like that or emerging trends that you notice with regards to security or like a red team, blue team type of thing? What are your thoughts and what do you notice with regards to security and securing the tooling that we build?

James Hall: AI is quite dramatically bad for security because the hackers are using AI and also people on the other side are using AI to generate quick prototypes using like Supabase. When AI gets stuck, the first thing it does is switch off the security problem. Like row-level security on Supabase or something, like it'll just flip that off immediately.

That's where hackers come in and they're using AI to quickly blast lots of endpoints because people that are new to building apps, they don't realize that let's encrypt certificates, broadcast as a transparency log, and as soon as you publish them into the internet with an SSL certificate, hackers are at it already. Bots are trying to poke it, prod it, all the rest of it. LLMs can very quickly see if they can go sideways and do other nasty things across your infrastructure.

Yes, it's like gasoline on the fire, isn't it? It's both ends. I don't know if this is a good fix.

Claude reckon they've got a new security tool coming out. I don't know if that'll be any good.

Luca Mezzalira: We don't have to forget what we have done so far. It seems, apart from the hype, there's this idea where LLMs are in the center of our life now. I think we need to treat them as a tool more often than not at the moment.

If I think of any other revolution that happened in software, we always treated the new things as a tool. It was part of an architecture. It was part of a software development life cycle.

It wasn't the center of everything. That means we built in the past fantastic tools that enables through different techniques to test the software end-to-end on security side. Now, are they perfect?

Maybe not. Is AI perfect? No.

We know upfront. If we are capable to combine the two things and not creating a mutual exclusive decision, like we want to use only AI for doing everything, I think we will land in a very nice place, because now one tool that is deterministic majority of the time because they do static analysis, abstract syntax tree, they do a bunch of checks around the system, you will be able to have the best of both worlds.

I personally believe that in certain areas, despite currently if they are good or not, there is still the need of a deterministic output, that we like it or not. Even on UI, for instance, I strongly believe that there are areas that can be probabilistic, other areas that shouldn't be probabilistic. Some other things, in my opinion, is that we need to look holistically again on the software development life cycle and identify what we accept that could be a drift, that is not the ideal outcome that we expect.

Others instead that we say, hang on, we want to use SonarQube, or we want to make sure that static analysis and cyclomatic complexity reaches a certain point if we still care about code, because that's another good question that was raised during this conference in several ways. I believe that there are still the tools that are still viable and we shouldn't ditch all in one go, in favor of AI.

Thomas: Who has done the thing where they say to Claude or your favored tool of choice, scan all of the network in my house and find the things that have got open endpoints so I can automate them, like my fridge? I think that is both fascinating and absolutely petrifying for me. I think the security question is a really big one.

I just want to touch on this because I think this came up earlier this year and it's a really interesting juxtaposition. This particular example is Tailwind, where you've got Tailwind is more popular than ever because it seems to be like React, a default of agents, and it's shooting through the ceiling of how many downloads it's getting per month. AI has completely obliterated their business model. What's going to happen in this world where the thing that funds the things we rely on removes the ability to fund it? I think this is quite interesting as well from a games economy point of view, where lots of people now have access to things where previously big studios only had the monopoly on it. What do you think about this?

Danielle An: Actually, one of the main things we have is, again, we have artists, we have game designers here, is that in the past, I think artists and game designers were blocked by what an engineer can write in code such that people can experience that thing, whatever the game is. Then, vice versa. Now we can all vibe code in a couple days.

We all did. Actually, you guys are going to see live demos that's all runtime, nothing is baked. When you can do that, it's very interesting.

Should we get money when we publish onto some social platform and a million people played it? The cost probably was clawed in $200 per person, 5 people, like $1,000. Whereas in the past, even just to ship something like that, you need so many cycles of engineering time, it easily would be 10 times more expensive or even more than that.

I think the bigger question here, I don't know if anybody actually has answers, is how the tokens between the creator of the content and the player of the content and the platform that hosts that content is going to scale up in a way where they all want to do it? If creators don't want to do it because they're not making money, it's going to burn the whole economy. If the platform is like, you guys are all having fun, but I'm not making money, so it's also not going to work.

I think that dynamic just entirely shifts from there's a budget as if I'm making a movie and it could be $200 million that I already got for my game. It takes 18 months. It can make or break my studio.

To like, ok, so we have cool ideas and it may only take $500 to prompt that. Then, how do I distribute that? How do I get this content to be ranked very high and discovered?

How do I get to the right audience? I think it's going to be very disruptive, but in a very exciting way. I don't think there's any answers yet.

Thomas: What do we think about the Tailwind model?

James Hall: You may not know, but our head of frontend left us to be employee number one at Tailwind back in the day. Brad worked on the Tailwind VS Code extension while he was working at Parallax, and went over to there to build out their premium offering. I think it's super interesting.

I was never able to monetize any of my open-source stuff, even though it's super popular, because I couldn't figure out a way to hamper it to then upsell something else. I think it was always on tenuous ground. You relied on people going to the website, going, I like this pack of this is how you use Tailwind for these problems, and I'm going to drop $59 or whatever, it's inconsequential for a big company.

You get enough of those, and then you can build a team. That's what the Tailwind guys were doing, and gals.

I think they did very well, but I think they were in a quite precarious situation. I do think open source, that classic XKCD diagram, isn't it? It's like there's some thankless maintainer just maintaining one lib that holds up the whole thing.

I don't know if I've got a good solution. I don't think it's going to get any better. It's certainly getting a lot worse.

I'm seeing lots of contributions to open-source projects that are literally just vibe coded by OpenClaw or whatever, and a lot of pull requests on jsPDF and others that are just automatically closed, because it's just like, this is just rubbish. This GitHub open by default, anyone can open a PR thing, they're going to have to switch that at some point, because it's too much. Open-source maintainers have been ignored and underappreciated for a long time, and I think this has just accelerated that.

Participant 1: Do you think we will reach a point where the sheer quantity of code that's been generated and just repeatedly over and over again, that the core understanding is just lost? In terms of like nitpicky kind of, this problem P is here, that that is just completely absent. We have to lean on, ok, I need a general thing to understand this. Like, we all know that one engineer that you give them a bug and they're like, "Yes, I know what file that's in. It's here. I'm going to change that, done." Do you think that that is going to disappear?

James Hall: I think you do find when you're using AI, you almost feel like you're losing your abilities a little bit. I don't know if anyone else feels like that. I do think that muscle memory and being able to remember functions and how things stitch together does go away a bit. It goes to your point earlier about whiteboarding and having a clear picture. I think you just need to take yourself away from a computer, draw some boxes and have a walk, get some fresh air. I think hopefully it doesn't go away, but I could probably see a world where it does.

Thomas: Maybe I can offer a counter point to that slightly. I've had a very similar feeling about owning codebases and knowing about code and being the expert on it for a long time. Then I went to Meta where there is so much more code than I could ever imagine.

I did try for a brief moment to understand it all, but it's not going to ever happen. I think people have to adopt a more large codebase mindset where you're never going to be the expert on everything, but you have to be the expert on finding the information. It's about adapting your techniques to identify and triage and then hone in on something, which again, going back a step is quite worrying to see the debugging trends going backwards.

At some point you reach a point where you can't understand everything anyway, whether you've got AI or not. I think those techniques are really critical skills to develop in the future.

Ivan Zarea: I think this part of the craft is going to die out eventually. I see this trend actually somewhere in a different place. I see this trend in like support organizations, oftentimes where I've talked to customers and I see like, how did their support organizations operate?

What is interesting is that, a lot of the time, support organizations were optimizing for solving numbers of tickets. With an increased influx of tickets, you cannot humanly sift through them. Then the natural answer is, ok, hire more support people.

That actually decreases the quality of your support because then you have like endbrain sifting through this. Then it's a challenge to transition to a higher level where you're not looking at an individual ticket or an individual request and are using data to sift through trends and understand what's happening. I think that this is what we're expecting in our industry as well, where that part of the craft is going to slowly die out in certain areas like FFmpeg, like that XKCD comic that you mentioned.

There are certain areas in which that is still going to continue. As a general rule for most of us, it's probably going to die out.