The AI-Native Software Engineer

So, we are going through a pretty big change in software engineering at the moment. AI and VIBE coding are fundamentally reshaping our work, and there is a lot of hype to sift through. Today I'm going to share some battle-tested insights from the trenches for making that transition successfully with some fun learnings along the way.

But before we get started, I do have something I have to share. We've all been replaced by AI. We can finally retire to the woods before they're cut down for more data centers. As you can guess, this hasn't really happened just yet, but the future could look a little bit different.

I've been coding with AI for a few years, and I think the direction we're going in is sort of an AI native engineer. Instead of thinking, you know, AI might replace me, an AI native engineer might ask for every task. AI might help me do this faster, better, or differently in some way. And I think that the future really belongs to engineers who can embrace that collaborative mindset.

Now, if you zoom all the way out, this chart is really the roadmap for the next few years. On one side, you have the classic developer journeys where most of our value came from purely human effort. And then we hit this AI augmented phase where many of us are in right now. And as we continue shifting, we go from augmented to AI first and eventually AI native developer experiences. AI first journeys ask a different question. They ask that, how would this journey look if AI were assumed from the start and not sprinkled at the end? And then AI native DX is where the unit of work itself ends up shifting to agentic workflows.

Now in the future, some say that every engineer is going to evolve from a pure implementer to an orchestrator of agents. Maybe we'll all be managers where human judgment and critical thinking is going to help guide AI towards fixing code towards the right outcomes. Some people are very much already doing this, and maybe we're going to move from how do I code this to how do I get the right code built. There are a lot of solutions already available for this. There's cursors background agent, which can hand tasks off to the background, can be used by engineers, PMs. You can monitor progress on multiple tasks in real time. You can be notified if the agent needs input. There's cloud code for the web. I've been enjoying orchestrating multiple tasks using Jules from Google Labs. There's also GitHub's copilot agent. I use this both on desktop and on mobile. Like if I'm on a hike, I love being able to pull out my phone and just spin up a bunch of tasks on side projects. It's kind of cool.

There's also Conductor for Map, which supports multiple agents. But I do have to ground ourselves in reality. It's sort of unsurprising that startups or people with evergreen code bases are already starting to play with some of these ideas like orchestration. Enterprise is a little bit different. What I hear when I talk to enterprise companies is a lot of skepticism around the readiness of these patterns for large decade old code bases. And I'm excited there are folks poking at these problems. I think eventually the tooling will get to a good place. But just to talk about these pattern changes a little bit more, today most of us act as conductors. We are effectively guiding one agent through a single task. And tomorrow we might be those orchestrators directing a fleet of agents working in harmony towards a shared goal. If you think of an orchestra, maybe you picture something like this. Maybe you picture yourself leading an orchestra of agents. And it looks a little bit like this. But in reality, whoever is very different. Things are evolving fast, but best practices for teams and organizations are still in flux. So we're going to talk just a little bit about that today.

Now multiple developer surveys including Dora and Stack Overflow showed that a majority of us are using AI for coding at work. And what this data tells us is that it's no longer a novelty or an edge case, but it's rapidly become just a standard part of the software development toolkit. What I'd like to say is, you know, there's one thing you need to remember. AI is really not about writing more code faster. It's about building better software at the end of the day. So throughout this talk we're going to explore what better could potentially mean. Now coding with AI is a little bit of a spectrum. Vibe coding is fast and exploratory. It prioritizes speed and experimentation over deep review and engineering rigor. And then we have AI-assisted engineering. It's at the opposite end of that spectrum. And this is sort of the methodical integration of AI into a mature development lifecycle. So that human engineer, us, we stay very much in control and we use AI as a collaborator to augment a more structured process. And the challenge for us as builders is really just skillfully navigating the spectrum.

Just to get on the same page, let's quickly just take a look at developer experience and where AI can help across this lifecycle. This is kind of the baseline loop without any AI interventions. It's useful as a reference to compare where automation and intelligence can be added to accelerate velocity. So typically we're thinking about things like design, coding, testing, building, deploying. So this highlights where AI is most useful during the early design phases. So think about chatbots in your editor for asking questions, iterating, and AI triage tools that can streamline planning and investigation.

Then we have the inner development loop where we spend a lot of our time. So coding, testing, debugging. And this can help with just faster code generation, automating tasks, catching errors, ideally before they go to production and definitely before you end up on Hacker News. Here's the full overview of where AI can help with developer experience. This is all of those loops, design, inner, submit, outer, and it highlights just every point where AI can meaningfully reduce toil. AI coding tools are also a spectrum.

My team and I have been using a few of these. You've got plenty of options these days. Whether you are prototyping, non-technical, or you're building for production. We've, of course, also vibe coded a lot. And the real genius of vibe coding is never have to confront the technical debt because you have no idea who or what created it in the first place. As your team go through this journey, you're going to run into skeptics. You really want to turn these eventually into people who can be technical evangelists, people who can have a very grounded perspective on what are AI's weaknesses, what are its strengths, and can we have a very balanced way of how we think about it. We had a few big learnings on my teams, things like AI tools don't necessarily replace expertise, but they amplify it.

And the more skill that you can bring to this as an engineer, the more powerful the results you're ultimately going to get. What about the impact of AI on coding at Google, where I work? Well, across the board, it's already been moving the needle on real productivity. We're seeing pretty measurable velocity gains and faster coding speeds across multiple studies. Whether that is using it as an auto complete for full code gen, for documentation, for testing, for code review, we've generally found that it's able to help us in a lot of ways.

We have many teams successfully using things like Gemini CLI to build the next generation of applications, and we're enjoying it. You might remember, probably three to six months ago, which feels like a very long time ago in AI, when we had prompt engineers. I love this title. It might as well have been called AI code whisperer. Folks would test, evaluate, and iterate on prompts to improve the chances of getting a high quality output. But a smart prompt doesn't really guarantee you great outcomes.

Many of us tried prompt engineering, we tried tweaking words endlessly, but as this iceberg shows, the real issues are often below the surface with mismanaged context. A limited window means that the AI can forget key details, unstructured content can lead to confusion, competing information can distract it, and overloading it can also overwhelm the model. Context mismanagement is often the big issue here. Context is king in this moment. So if you haven't come across things like context engineering, effectively it means equipping an AI agent with everything that it needs to tackle a task effectively.

We're talking about the right files, examples, history, tools, constraints, and the quality of your output is going to be proportional to the quality and relevance of the context that you provide. Many of the tools that we use, whether you are using cursor or client, they make it much easier these days for us to include files, folders, problems, URLs, more docs into your workflows to help with that context that we're missing.

And increasingly you also have other ways, like visual ways, multi-modality, being able to pull more context that can be useful. We're also seeing our tools evolve a little bit because again, those context window sizes can be pretty finite. So some tools, this is Klein, do smart things like automatic context summarization. So when your conversation approaches the context window size, it can actually start to summarize previous sessions so you can free up space and continue working with still the important parts, the important details preserved.

There are also other ideas like a memory bank, which is kind of a structured documentation system which allows you to maintain context across multiple sessions. So Klein, for example, can read memory bank files and rebuild its understanding of your project without you necessarily having to do a lot of manual work there yourself. Here's a great template for context engineering from Anthropic. It's got ideas like background data, examples, conversation history. This type of thing makes for a really great tweet that you will completely forget.

I forget this all the time. I decided to wipe code this into a quick web app that you can also check out. I've also completely forgotten to use this. We just generally need better tooling to handle this automatically for us, and I'm looking forward to our tools evolving in this direction, too.

Spec driven development has become more popular. This is the practice of really just planning before you prompt, and it's about providing that clear context that the AI needs to succeed rather than expecting it to read your mind. There are a few other patterns that drop out of this. Recently, I've seen a few folks using a learnings markdown file, and this is about creating a powerful self-improving cycle where the agent's performance gets better with every single task.

At the end of a task, imagine that you've been prompting it to maybe write a component or make some additions to an app that you've already got. You can ask it to store key insights in a simple text file, and that acts as long-term memory. It becomes an external brain that just keeps getting better and helps steer the agent's performance over time. Other things that we learned. Never commit code that you can't explain to other people or even to yourself. This is a golden rule for production AI coding.

You have to assume that you and your team are going to have to manually change things at some point, and so again, human in the loop, human reviewing the code is going to continue becoming important. I think that reading the code is going to become an even bigger part of the job in the future. We can expect to be spending more time reviewing, testing, explaining than necessarily just typing, so we're going to have to continue building over this muscle.

Vibe coding is a gift for prototyping. I think that static mock-ups often look good, but they're not really interactive, and that has limited feedback that you can get from the true user experience. So we have really enjoyed using this for prototyping. There are some companies that have really, really leaned into this idea, like Shopify. So Shopify had sort of company-wide change management around their use of AI across engineering, product UX from the top, and what they now have is design dev handoffs that are a little bit different.

Voice dictation also changes the way that you can vibe code because you can use your voice much, much faster than you can type, anywhere up to three to five times faster. AI is a multiplier, so what helps the human can help the AI. So invest in tests, CI, clear documentation before you really expect very big gains. Tests are ultimately a huge safety net in this moment. They really do risk your use of AI for coding.

When I first started hearing about this idea, I thought this works great if you are working remotely in your own office, and terribly if you're in any sort of open office situation. But of course, they now have vibe coding by whispering, which is also available. So you can just whisper your way to your MVPs. It actually works pretty well. AI is a multiplier, so what helps the human can help the AI. So invest in tests, CI, clear documentation before you really expect very big gains. Tests are ultimately a huge safety net in this moment. They really do risk your use of AI for coding.

So if things start going off the rails for any reason, you're going to know sooner. I talked to a lot of teams who will say this is all great if you have end to end tests already. What if we don't have those tests? Do we just use AI to write them? And you can. You just, again, need to make sure that you are keeping humans in the loop to understand like what tests are being generated? Are they sufficient? By the way, this looks like a mother mocking their child for some reason, but at least they're safe.

The promise with AI was sort of the step change in productivity and what data, I love reading white papers, I love reading research, but the data shows is a little bit more nuanced of a reality. What the latest data shows is that usage is high. It continues to go up, but trust is sliding. Favorable views about AI for coding dropped from 70 to 60 percent in the last two years and 46 percent of people actively distrust AI accuracy. This skepticism is not necessarily a bad thing. It's a sign of this area maturing. Models continue to improve. Agents continue to improve. However, we do start to learn about where things can go wrong.

But models continue to improve. Agents continue to improve. However, we do start to learn about where things can go wrong. So when things go wrong with VIVE coding, you have VIVE debugging, where you have no idea how the code works or really how to fix it. I thought I'd give a shout out. On my team, we very recently released Chrome DevTools MCP. And this is to help your AI coding assistant sort of see and interact with a live browser. And that means that your agent can see what's rendered, it can look at the console logs, it can look at network logs, automate performance optimization. It can find issues with any broken layouts. There's a lot of power that this unlocks. If you're coding with AI, maybe check it out. Might be useful. But back to the data.

So at the individual level, the lift from AI productivity is real. Developers using it can see anywhere up to 21% more tasks completed. People are merging on the edges anywhere up to 98% more pull requests. We will talk about pull requests more in just a second. But a very significant number of developers will say that AI has a positive impact on their personal productivity. Some will even say that when we're talking about positive impact, that it can feel that the AI writes better code than they do in some cases. Now, when we're especially talking about common problems, average problems, I could certainly see that being true. And there are people who will say that it is extremely increased their productivity. This shows maybe it's about 10% to 13%. And there'll be people who say it's slightly increased their productivity. So close to 41%. And that last largest group really suggests incremental benefit from AI across the workforce.

Now we get to the fun stuff. Here's the paradox. We sped up code generation, but human verification did not scale with that. Pull request times have increased in some cases by anywhere up to 91%. PR sizes are also exploding.

If you have reviewed a completely AI generated pull request, maybe you've seen that there are cases where people will be making all kinds of changes that are not needed to many, many more files than are required. So PR sizes have exploded anywhere up to 154%. This is soaking up a lot of those individual gains that we were just talking about. The system moves at the speed of the slowest step. And today, that step is review and validation.

Developers are describing this common pattern. AI suggestions are often plausible, but they're not always correct. And 66% of people call this their biggest time sink. 45% say that debugging AI output is more work than it is worth. And this connects directly to those longer reviews that I was just talking about. Quality gates and validation are now the critical path.

AI shines in low-context situations, handling predictable patterns, writing generic functions, treating AI as a junior engineer, and focusing on greenfield code, boilerplate, unit tests, docs, prototypes, and MVPs. However, in high-context novel problems, strong supervision is required due to the need for deep context. AI struggles to hold extensive architectural decisions or informal business logic without studying code bases and team workflows over time. Humans should lead in ambiguous requirements or logic spanning multiple systems.

I think that this can free up experts to be able to focus time on more design work, integration, tricky edge cases, just building more polished experiences. Where it struggles right now is high-context novel problems. And this is where deep context is really required. And if you are a team building anything non-trivial, this is going to require strong supervision. So it can't necessarily hold a decade of architectural decisions or informal business logic in its head without studying your code bases, without studying your docs and how your team has been working over time.

In security-sensitive areas, the risk of subtle mistakes continues to rise with this. Any time that your requirements are ambiguous or logic spans multiple systems, again, humans have to lead and AI should be assisting. Our first priority is really mitigating skill erosion. We have to use AI to accelerate learning in our teams, but not necessarily replace it. This requires rethinking our core teaching and mentoring processes to ensure that engineers at all levels are developing and maintaining fundamental problem-solving capabilities.

This leads to something that I call the 70% problem. AI can get you about 70% of the way towards solving a problem, whether it's generating a full application, generating an MVP. But that last 30%, that final mile, is the hardest part. For juniors, that 70% is still very magical. It can feel very magical. But for seniors, that last 30% is often slower than writing the code from scratch yourself. So AI can help us close the demo gap quickly, but shipping to production I think still belongs to humans. Sometimes, that last 30% is something that the seniors see and the juniors don't, just because they don't know what to necessarily look for.

But for seniors, that last 30% is often slower than writing the code from scratch yourself. So AI can help us close the demo gap quickly, but shipping to production I think still belongs to humans. Sometimes, that last 30% is something that the seniors see and the juniors don't, just because they don't know what to necessarily look for. In other words, the juniors can send that 70% off as a pull request, as if they were done. And it then means that the actual hard part can end up falling into the code review, largely being done by seniors, cleaning up mistakes that no human would have necessarily made. Or perhaps humans would make them. But it is meaning that, again, we have to rethink how we're approaching code reviews.

We don't like talking about AI's impact on the job market, but I think it is going to impact us in some way. 54% of leaders expect AI to reduce junior hiring in some way over the next couple of years. It is commoditizing the easy parts, forcing us to think about how the value chain is evolving to more meaningful work. This could mean, potentially, fewer entry-level roles, or that junior roles evolve to focus on things that AI couldn't do quite as well. If you're a tech lead, a manager, a leader, I think we're going to have to continue thinking about how we develop talent to make sure that we don't inadvertently dry up our talent pipeline, because we are going to need those juniors to become seniors at some point. I still think we're going to need a lot of senior engineers.

One of the first things we can do is try to evolve code reviews into more learning moments. I've heard of senior engineers sending back pull requests where it's clear that AI was used but the person didn't really understand what they were doing. When a junior submits an AI-generated PR, the review kind of becomes one of your primary venues for mentorship. You can ask them Socratic questions that force them to explain the AI's output. You can help ensure a level of understanding and not just functionality. Those reviews become more about comprehension rather than just correctness. I've suggested that maybe we evolve pair programming into trio programming. It keeps the senior expert in the loop, but it ensures and assumes that the junior is going to be using AI in some way to leverage speed.

Everybody's learning, quality ideally stays high, and we void isolation problems that pure AI assisted work can create. It's still collaborative human AI teamwork. I've been suggesting in my teams that we try out regular no AI challenges. This is another thing you can do to ensure critical thinking skills don't evaporate. You can help keep your team's skills sharp by designating a day of the week or even a certain type of task on your backlog where you just say, maybe we don't use AI for that. It just reinforces that it is an assistant. It is a tool, but it is not a replacement for thinking. This is essential for building resilience when AI fails or is not necessarily available.

AI often produces code that passes basic tests, but may lack robustness. Its baseline is usually, well, it works, I guess. It kind of renders in the browser, I guess. But again, those code reviews are important for checking edge cases, performance, security, correctness, whether it is still matching your team's best practices and patterns. And our human role is really about ensuring production readiness and standards. Speaking of standards, this is what safety standards looked like back in the 80s. No belts were fine. We just had vibes, which is not completely different to what we have today.

So I covered a lot today. If that's how you're feeling, you are absolutely right. The important thing about all of this is just stay proactive in helping yourself and your teams along this journey. Our job is to strike the right balance at the end of the day. It is to harness AI speed and capabilities to deliver value faster, but to keep the human element in charge. I think that our creativity, our judgment, and our understanding of user needs is going to really guide how AI is used. So I hope that you found something in this talk helpful. Thank you. Thank you.

Okay. So it looks like the first question is, what has been the top channel for your team in the last 30% challenge? I'm going to rephrase that as what's been the top challenge for your team in the last 30% challenge. I think honestly, it has been defining what do we mean by quality? I think that if you zoom out, a lot of people, if you ask them, what does quality mean? They'll say that there's an aspect of correctness, security, performance, maybe accessibility, maybe good design aesthetics in there. But what is the tooling that you use to figure that out? On my team, we've built a number of tools over the years. Did Lighthouse, we've done Chrome DevTools, we've done CoreEd Vitals, but every single team is going to have a slightly different perspective in terms of what that last mile actually means for them. So I think that defining and aligning on what that bar is for you is going to continue to be very important.

Our next question is, do we think we are losing our intuition depending on a lot of AI assistants? Oh, absolutely. I definitely think that's the case. I am already finding places where I will lean on AI to generate a function block or something. And I was just... I love... We had this quiz right at the very start and I was just thinking, man, I would have done better on this quiz two years ago than I do now. And it's because we are starting to just lean into it. At least with Stack Overflow, you had to go search for the answer. Now it's just being generated for you. And we're hoping you're reading it in some way, but are people actually reading through the code that's being generated? I don't know that they always are. And so I think that we ourselves are going to have to make sure we're following these patterns of human reviewing everything that's being generated.

Do you worry that AI coding encourages a productivity mindset over a curiosity mindset? Absolutely. I absolutely worry about this. I think that very often we get off on the high of, oh my gosh, it generated me a whole thing in just a few minutes. I'm amazing.

Just to try making sure that when AI starts running into problems with solving issues, I kinda know how to go fix it, because otherwise I'm going to be screwed. Exactly. Yeah.

Do you worry that AI coding encourages a productivity mindset over a curiosity mindset? Absolutely. I absolutely worry about this. I think that very often we get off on the high of, oh my gosh, it generated me a whole thing in just a few minutes. I'm amazing. But we are not necessarily... I feel like we've skipped over, oh wait, AI can actually be helpful as a learning tool and as a learning guide.

How do you see the interview process evolving over the age of AI? Oh, that's a spicy one. Yeah. I keep track of all those fun conversations about, you know, Clulee and all these things happening. My personal view is that increasingly companies are going to have to assume that a person is using AI as a tool. Are you actually able to solve problems? What is your problem-solving process? How are you using AI in that problem-solving process? Because it can't be the entire problem-solving process itself. Exactly.

And you can't just have AI stuff the entire code base into the context window. So if we want to try learning about a part of the code base, we'll just say, okay, well, I was told the logic is roughly here. I can go ask somebody, but I'm first going to go use AI to teach me about this part of the code base. And then if I still have questions lingering, I can ask the senior engineers or the person with more experience about those gaps. In that way, you're using it to build your muscle memory and your understanding of how the problem space works before using it to just do all the work for you.

So I think, again, it comes down to what are the patterns and practices and habits that you yourself were enforcing? Yeah. It's almost like a better rubber duck at this point. Yes.

Yeah, I keep track of all those fun conversations about, you know, Clulee and all these things happening. My personal view is that increasingly companies are going to have to assume that a person is using AI as a tool. A few years ago, we would be saying, well, hey, do you have access to the web? Can you use Stack Overflow? Can you use any other sources of information? And I feel like the important part, the thing that I care about most is, are you actually able to solve problems? What is your problem-solving process? How are you using AI in that problem-solving process? Because it can't be the entire problem-solving process itself. Exactly. Exactly. And so I think that the interview process is going to have to assume that you're probably using AI in some way, but if it is an in-person thing, or it is a call where you're monitoring in some way, that the person isn't entirely delegating it to AI, I would be just asking them, like, cool, you generated a thing with AI. Can you explain how this works to me? If we were to have to solve this other edge case without using AI, could you maybe talk about your process? And it's fine if they're using AI to then scaffold the solution out, but I want you to understand how you solve problems across different systems, across different components, across different pieces of your app. And so ultimately, I think that yes, the interview process is going to have to evolve a lot. Yeah, I think when IntelliSense was first created, people were pushing back on it. You don't need to memorize everything, and that's what AI can help you with. Yes, absolutely. So, do you think AI is impacting front-end jobs more than backend jobs? I have an extremely long answer to this. So yes. The reason why is currently, a lot of frontier model teams, so y'all are probably using models from a number of different companies. A lot of those teams, they come from a data science background. They are very heavy on Python. In the last two or three years, they've had to get a little bit more aware of front-end best practices, full stack best practices. But there's still a lot of emphasis on like, well, front-end design. Wait, front-end is a very big topic.

In the last two or three years, they've had to get a little bit more aware of front-end best practices, full stack best practices. But there's still a lot of emphasis on like, well, front-end design. Wait, front-end is a very big topic. You could be, you know, somebody could be using Next.js and trying to build out an app, or they could be using other kinds of things. And so there's a lot of emphasis right now on front-end, just because it is slightly easier for us to be able to build benchmarks around it for model teams to optimize. That is not to say that models aren't good at back-end, but there's still a lot of work to be done on like, full stack applications, scaffolding and development. I think this is a matter of time type issue. So right now, I would say yes, it's probably impacting front-end jobs more, but it is also going to impact those back-end ones probably within the next year or two. Right, makes sense.

Any thoughts on tagging level of AI use for PRs? Yes. I have a lot of people ask me variations of this question. I have people ask me, should we be annotating our individual source files with the lines that AI generated? Should I be annotating components, modules, any of these things? I think that we now have to assume people are going to be using AI and maybe 70, 80%, 90% of it's being generated by AI. This becomes a philosophical issue for especially open source projects, because it's now very easy for people to just throw some code over the fence and feel good if their contribution is accepted. I feel like you need to come up with some sort of policy that tries to discourage people being lazy and encourages them to at least have done a first pass review themselves to understand how it works. So if somebody sends me a PR and it is obvious that they have used AI to not just generate the code, but also generate the summary of what is this thing about, I'm going to call bullshit. And I think that's okay for us to call bullshit on. I feel like we just need to start making sure that there are agreed on practices, whether it's an open source project or a team, agreed on practices and make sure that if we are asking people for reviews, there is some evidence that they've actually thought about the problem. Maybe that means we introduce practices like, okay, well, I could do a very quick first pass review. If it looks like you don't understand it, or you just solved this in the wrong way, sorry, I'm just going to say, you're going to have to redo this in some fashion. But I think for pull requests, I am much more open to people tagging that AI was used. For individual files, I think that's kind of a losing battle, because especially if you're in a team project, it becomes out of date so fast.

If we reduce hiring of junior engineers, what does the pipeline look like to train qualified senior engineers? Absolutely. I think this is a fundamental problem that we're dealing with. We are not going to be able to lean on the exact same quotient of senior developers forever. If you assume that models and agent quality are going to get much, much, much better in the next couple of years, maybe that will help solve some of the problem. I don't think it's going to solve all the problem at all. My personal perspective is that companies who are aggressively already reducing junior hiring are not taking a long-term view on this. As an industry, we need to be much more mindful about reducing those junior roles. We need to keep them in place. Agreed.

Great question. I will say that if you think about this from the perspective of most vibe-coding platforms, there's tons of vibe-coding platforms, a lot of them, when they were first building out, were very focused on, can we get the damn thing to even run. You type in a prompt. It's actually kind of magical that it one-shot works a lot of the time. But they were very focused on correctness and does it run? In the last year, they started to focus a little bit more on design, on performance. I don't think that they have focused quite as much on accessibility. I would say that base models often don't assume anything about accessibility. You're going to be lucky if that's a thing that they're going to optimize for. I would love to see more tools, more platforms, actually focus on in their system prompts saying, hey, yeah, let's make sure that this thing is also accessible.

Awesome. Well, that does sum it up for how much time we have for Q&A, but Addy will be in one of the speaker sessions that you can ask him questions personally and feel free to hit him up. Thank you. Yeah, thank you.