Addy Osmani has worked on the Chrome team for 13 years. And if you ever opened up the developer tab on Chrome, you've definitely used the stuff he built. He is also a prolific author. His latest book is titled Beyond Vibe Coding and it's aimed at professional software engineers. Today we go into Vibe coding versus AI assisted engineering and why vibe coding isn't useful for much more than just prototyping something quick and dirty. The importance of understanding what the model does. Why Addie always reads to the thinking log of the model he uses to make sure he fully understands what it did and why before approving changes. New development workflows with AI how things like spec-driven development, asynchronous coding, background agents and parallel coding with several agents are new and unexplored areas of software engineering and many more.

I tend to tell folks that I personally think the vibe coding is not the same as AI assisted engineering. And I feel like that distinction is kind of critical because we don't want to devalue the discipline of engineering and give folks that are new to the industry an incomplete picture of what it takes to build robust production-ready software.

I think the vibe coding is really about fully giving into the creative flow within AI. So very much focused on high level prompting and in many ways forgetting that the code exists. This goes back to Andrej Karpathy's like original definition but it's about accepting AI suggestions without necessarily having a deep review and focusing on rapid iterative experimentation. Personally, I find it really great for prototypes, MVPs and learning.

What I've seen in production teams is that this has been very useful for them when it comes to trying out ideas rapidly and building out an intuition for what the shape of an idea might look like, what a component might look like, what an MVP might look like and that tends to prioritize speed and exploration over things like correctness and maintainability, things that we perhaps care a little bit about when it comes to building things for large production audiences.

To me AI assisted engineering is where AI is this powerful collaborator but it's not a replacement for engineering principles and so in that model it is a force multiplier but it can help you across that whole cycle whether it is with boilerplate debugging deployment but the big difference is that the human engineer remains firmly in control you are responsible for thinking about the architecture for reviewing the mode and for understanding every line if not most of what AI is generating for you and you're on the hook really for making sure that the final product is secure, scalable and maintainable.

Maybe AI is helping you with with velocity, which is which is great, but that doesn't mean that you can sort of shrug off your responsibility for quality at the end of the day. And I tend to think that a lot of people have said that they found AI and coding to be a force multiplier but I found that the greater expertise that you have in software engineering the better the results you can get when you're using LLMs. And I think sometimes if you're new to the industry or you're a junior, maybe there are some what we would consider to be traditional best practices that maybe you haven't had to experience them yet or think about them. Like if you care about production quality programming, you should probably only be committing code to your repo that you can fully explain to somebody else because just expecting that the AI is going to help you untangle whatever mess happens later on is probably not going to work out long term.

I have more recently been focusing on the idea of spec-driven development, having a very clear plan of what it is that I want to build. I think that there are definitely places where I still vibe code, if it's for a personal tool something throwaway. In the old days if an engineer or a PM had an idea maybe we would put together a quick mock, maybe we would put together a wireframe or a sketch or something like that. These days the fact that you can vibe code a prototype and actually show somebody in a pull request or in a chat like, "Hey, here's an even more clear version of the vision that I had in mind for this." I think there's something very powerful to that and I'm loving vibe coding for that.

That doesn't mean that we take the vibe-coded prototype or that code and just stick it in production. Once you have clarity around the vision that you have for a component, for a feature, for a view, you should probably be writing out like, okay, well, what are the actual expectations around this? What do we actually consider to be the requirements? And that will give you a much higher quality outcome typically from the LLM. Because otherwise, if you're giving into the vibes, you're also sort of giving into, okay, well, you figure out the architecture, you figure out like what this should do. And while that's fine for ideation, it's probably not sufficient for production sort of product engineering.

So for me, spec-driven development has been a big thing. I think that tests are great. And if you are open to tests, it can be a great way of derisking your use of LLMs in coding because sometimes, you know, even if you're using state-of-the-art models, you can end up in a situation where maybe the code looks more convoluted than you would expect or maybe your first couple of prompts have been generating really good code and then for whatever reason things go off the rails. But if you can prove that things are working with tests and that if something did go off the rails, it's clearer to you what that was, I think that that can help you keep your project green the whole time.

My team just released Chrome DevTools MCP. I care a lot about quality and I think that in the last couple of years we've seen a number of cases where if you notice that something is broken. I will see a lot of engineers that will just say okay well hey LLM it looks like this button is off or it looks like this thing is not quite exactly what it should be. Go fix it. And that that's again going a little bit closer to just rolling with the vibes. But if you can keep things like a browser in the loop or something that can actually see the page that is what kind of Chrome DevTools MCP and related solutions do. They give your LLM eyes in many ways. So it can see what the browser sees. It can see what's rendering or what isn't. It can detect if there are warnings, errors in the console. Maybe even get a deeper sense of what is broken. And that can just improve the feedback loop that you have.

At a company like Google, we have this very long-term very battle tested way of thinking about software engineering at scale. And with AI, what we've realized is, you know, a lot of that doesn't go away. You still want to care about quality. You still want to care about doing due diligence. The things that I think we've found interesting kind of mimic what people have seen in in startups and other kinds of companies.

So the importance of mastering understanding like what is prompt engineering, right? like making sure that you are constructing the right set of incantations to get the best outcome from an LLM and then context engineering more recently like how can you make sure that you are optimizing the context window to increase the chances that those those outcomes are higher quality. We spend a lot of time thinking about that. Making sure that the right sets of descriptions, details, files, examples, any additional content that is specific to a project that the LLM may not necessarily have in its training data. That has been very interesting and important for us as we've been working through.

I think honestly just the importance of always maintaining human oversight has been one of the bigger learnings. We have of course, like I know a lot of people have run into this. We've of course seen cases where people, very often like external contributors, will sometimes be very passionate about like hey I want to contribute to your project but then they'll use an LLM and submit something that, I think Mitchell Hashimoto was blowing up on social media because he just had enough that people were submitting things that as you said out of good intention but putting way more load on maintainers.

One of the studies that I recently read highlighted that if you are increasing the velocity of code and improvements that can land in the team and you are doing human oversight, the human review is going to become the bottleneck. And that is what teams are starting to realize like, oh wait, we're starting to see a lot more PRs come through, but who's going to review those, right? That does also mean that our workflows may have to evolve. I have seen a lot of talk about like, yeah, why why aren't we using LLMs to also do the code review and that, you know, that that's a little bit of a slippery slope because if the AI is writing the code and you haven't studied it carefully, but the AI is also reviewing the code, are you actually sure about what's what's landing?

For me personally, there are a lot of tools that I use. Some of my favorite ones include using Klein in VS Code. Most of these tools will show you the thinking that is happening behind the scenes as a solution is being built out. And even if that happens quickly, like I will try to go back, scroll through, expand and read through, okay, what was your thinking process through actually being able to build this out? What decisions did you make? What did you generate? And I will review that code before it ends up in a pull request. There's going to be some likelihood later on that I may have to maintain that code, that I may have to make some tweaks to that code that the LLM is not going to be able to help me with.

My experience of this kind of led me at one point to to write about what I called the 70% problem. The 70% problem is really about this idea that LLMs can produce very roughly like 70% of a working application very quickly but they tend to struggle with that last 30% and that last 30% you can consider it like the the the last mile, but it includes lots of different kinds of patterns that you know your audience will probably run across.

Things like the two steps back pattern. So, you know, you have used a couple of prompts to build up something. You give an LLM one more prompt and it happens to go in a completely different direction. Maybe it has fully rewritten your UI or the functionality behind your component. There are very often hidden maintainability costs, places where you're not being specific. You are delegating the responsibility back to the LLM. As we've seen time and time again on hacker news, security vulnerabilities, this is exactly where we see people accidentally, you know, leaking API keys, where there are XSS issues, where there are all kinds of problems because people did not think as holistically about the problem that they were solving and just sort of gave into the vibes.

So a vibe coded proof of concept, you know, is fine for for MVP for that prototyping phase, but it likely needs to be rewritten with production quality in mind. If you're going to be landing this in a codebase where you're working with other people, working with a team and dealing with a real user base of people.

More experienced engineers can finish the last 30% a lot easier and then less experienced engineers get actually a lot more stuck or get this false confidence. Yes. Absolutely. I think that with that last 30% what you will often see junior engineers or interns or new grads doing is they will not really know what to do next beyond just constantly reprompting the LLM to fix the issues and if it's not able to do it they're not necessarily going to have all of those skills just yet for debugging the problem or understanding where the issues are.

So what this speaks to is the importance of having a really good critical thinking problem solving mindset. You know, we always talked about the importance of this for people who are going into computer science. I think that that remains now. But that diligence required to actually read the code, understand the system, understand how all of those pieces connect together, I don't think that that necessarily goes away.

One thing that I'm kind of noticing on myself already is when I use these AI tools, may that be cloud code or agents or even just the autocomplete, I have a tendency to do tap tab or accept or just like accept all the things, especially when I'm working on something that I mean it's not the most critical thing in the world. And I find myself losing a little bit of criticality.

There are a few ideas that I've tried to suggest to folks. Things like for certain features or certain days of the week maybe you intentionally try to not lean on using AI or an LLM and just try to see like okay well can I still solve some of these problems myself to preserve your critical thinking skills and force you to think about okay well let's say that all of the top LLM providers were down for the day what would you do?

The reality is that I do think that it's going to continue to be very important for us to be able to think through how things work, be able to problem solve without necessarily relying on the AI. The models are going to continue getting better. But it is going to take quite some time in my opinion before you're going to be able to fully trust that in every situation whatever requirements you throw at it is going to be able to get it right. And if you get stuck, if you're trying things out and you've tried it five, 10 times and it still hasn't solved the problem, you're going to have to solve the problem yourself. So, I think that being able to force yourself into situations where you're testing and retesting your critical thinking skills are going to be important.

Yeah. I think for me the the thing that I'm most excited about seeing evolve is this idea of a synchronous background coding agents. A number of teams playing around with these ideas at the moment. I think that the idea of you being able to delegate parts of your backlog and have a system be able to implement that asynchronously is is a very interesting idea. If we can do that without merge conflicts in a way that is easily human verifiable.

I have been finding that that is very much already in a place where if you are having one agent work on writing or updating your tests or you have a number of agents working together on trying to migrate your codebase from one version of a library to another or a version of a dependency to another that they're pretty okay at doing that kind of work right now. Smaller changes like there are lots of things that we all have to do like adding dark mode for for example the smaller kinds of changes where maybe being able to delegate those kinds of changes to as agents are are going to get very very good.

Another thing that's very interesting is is vibe designing. I'm seeing that part of product engineering, product development evolving a little bit. Was very exciting to see you know, Figma's MCP moving a little bit closer in this direction. Things that allow designers and developers to work more closely together or to at least enable designers to be able to take their vision and turn it into a functional prototype, something perhaps a little bit closer to code that can then be productionized and is not just a one-off demo.

I think that, you know, there's going to be interesting times for new grads, versus seniors. You know, AI definitely raises the floor, but it also raises the ceiling, too. And, juniors are going to be able to get moving faster, but, seniors who can, you know, write specs, decompose work, understand system architecture, review effectively, I think that they're going to become even more valuable. And that last 30% that we talked about, I think it's leverage. Not just busy work, but I actually think it's leverage.

I completely agree with you and and I think that there's a lot to be said about how developer education in teams may also evolve for this moment. Historically I remember when I was coming up, mentorship was always a big topic and we talked about the importance of like pair programming. I think we're going to see, you know, perhaps even situations of of trio programming where it's a junior, senior and the AI and maybe the senior is going to be there asking you to explain the code that the AI is generating in some way or walking you through how that code perhaps connects to other parts of the system.

I think that what is new is the importance you know we one of the things that I have found has always held true is the importance of being a lifelong learner. That has always remained true doesn't matter if frameworks come and go tools change you know the industry evolves being a lifelong learner and being very open to trying out new things failing building up those skills I think that that remains very very important.

The people on my team that I think were the most successful early on at leveraging AI for coding and for product engineering were the ones that went in with this mindset of I am happy to learn new things to try out and to have this growth mindset and if it doesn't work that's fine at least I've tried it out at least I understand the constraints and maybe I'll try out different models for these different use cases in the future.

What's your favorite programming language and why?

My favorite programming language is JavaScript. This is not for the personal reasons. There are probably better programming languages. I like JavaScript because it enables anybody on the planet to be able to build and ship something to the web in a way that doesn't require gatekeepers. It it's very open. And I think that there's something very liberating about that idea.

What's a tool that you really like using and what does it do?

I would say that one of my favorite tools at the moment is probably Bolt. Bolt is one of those vibe coding scaffolding tools that people can use. They very recently added support actually for being able to use custom agents. So you can use clawed code for example to build your vicoded app and the output is generally very high quality great designs.

And finally, what's a book that you would recommend?

So, the book I'm going to recommend is one that I think covers career paths and best practices for software engineers in a in a way that I found very compelling. It is by you. It's the software engineer guide book. Genuinely an an excellent book. I guess if I wasn't going to of course you know recommend that one I think that if you are trying to learn more about the foundational aspects of AI engineering in this moment there's a great book called AI engineering by Chip Huin that is also worth taking a look at.