Beyond Vibe Coding with Addy Osmani

27:58But it doesn't really feel like you're in control. Yes, yes, you're absolutely right. And I think that whether your gateway into this new world was Vibe Coding or you are a senior engineer and you've been evolving your workflow for AI, there are a few things I think that everybody should keep in mind that can help you get the best outcomes. Adi just mentioned getting the best outcomes. Here's what I'm seeing with AI and Vibe Coding. These tools can give you incredible velocity. You can ship features a lot faster than before, but velocity without precision means you're just shipping more things, not necessarily the right things.

28:34How do you know if what you build actually works? Did that new checkout flow improve conversion or hurt it? Is the feature you shipped helping retention or causing a drop-off? Without precision in how you roll out a measure, you're making decisions blind. That's where Statsik comes in. Statsik is our presenting partner for the season, and they built a precision toolkit that matches your AI accelerated velocity. Here's what precision looks like. You ship a feature to 10 % of users in a controlled environment and see if it's moving your metrics up or down. If conversion drops, you catch it early and roll back before it affects everyone.

29:07You're making precise data-driven decisions at the same pace you're shipping code. Take Graphite as an example. They build granular control and rapid iteration into their development workflow using Statsig. When they roll out a new feature, built-in analytics show exactly how it affects their key metrics. They can see if engagement is up, if the feature is causing errors, or if users are dropping off. They do this with feature gates and metrics working together, and they're running over 300 of these controls rollouts at any given time. During production incidents, this approach cut their resolution times by over 50 % because they could quickly identify which feature flag was causing issues and fix it instantly.

29:43Most teams stitch together separate systems, wait on queries, and try to correlate user segments that don't match. By the time they know if something worked, they've already moved on to the next feature. With Statsik, you have everything in one place. Feature flags, experimentation, and analytics with the same user data. Statsik has a generous free tier to get started, and pro pricing for Teams starts at$150 per month. To learn more and get a 30-day enterprise trial, go to statsic.com slash pragmatic. With this, let's get back to the conversation about AI and development workflows. Understand that, you know, models tend to have finite context windows.

30:15They've been getting larger over time. You probably need to, at some level, adopt sort of a project manager mindset, you know, break tasks into small, verifiable chunks. I've seen a lot of people who will like throw, throw, you know, the kitchen sink at the LLM. It's like, hey, yes, build all these requirements at once. And that doesn't necessarily work the best. So small verifiable chunks, clear expectations, and be prepared to iterate with the AI. Don't just feel like one-shotting is going to give you the best outcome, because it probably isn't. And that decomposition is really pretty similar to planning a sprint or writing pseudocode, the type of thing that we would do in the older days.

30:57And it reduces the risk of context loss and compounding errors. I think that a lot of best practices in software engineering remain timeless, even with AI coding. So caring about modular, testable code, enforcing those code reviews. You know, AI is going to introduce a few new habits, like thinking about the input and output constraints and ceding enough context. But that doesn't mean that you can't get good output from it. it does mean that you're going to have to apply a level of diligence with that human in the loop to make sure that you are setting yourself up for success. The more that you sort of give up your responsibilities to the LLM, the higher the risk is that something's going to go off the rails.

31:40Yeah, and one thing that I heard from an engineer, actually, it was Armin Ronacher, who's a longtime century engineer, the creator of Flask and a bunch of open source frameworks. And he was telling me that he's observed something interesting with engineers who are firmly in control and very confident in their work. He said that he sees they're just seeing a lot more success with AI. And the people who feel that they don't have that much control over their work, over their tasks, they're just assigned tickets. And they also have a bit of a, like, you know, the world's control. I mean, mine said they're freaking out a lot more about AI and what it will do.

32:18And this was so interesting. of it just came to me as we're talking about it because what I'm sensing from a conversation is again a lot of your advice boils down to be in charge understand everything be confident you know that if this thing is taken away you can make progress like no problem it'll just be a bit slower and as long as you have this mindset it feels like everything is easier and and keeping this like you know you're as you said like you still read through the thinking you prefer the models where it explains to you and then you can go back if you wish and you often do it. You read through to make sure to learn.

32:51Plus, it's kind of fun. You keep learning professionally. You keep getting better every day. Absolutely. Absolutely right. I'm reminded of, you know, AI is just another tool in your tool belt. You know, we've gone through so many different moments over time of engineering and developer experience getting a little bit better with every generation. You know, when I was coming up, I remembered getting excited when templates became a thing. You could generate code? What templates do you mean? Oh, no, just downloading templates for ideas, for UI, for, you know, starting off. Oh, on the web, right? Yeah, on the web.

33:31And this was just the simplest of things. It was like a zip file, right? Somebody else had created it. Okay, so I've improved my starting point. And then we got stronger command line interfaces, scaffolding that type of thing and then you didn't have to worry about the exact starting point and i feel like this is just taking us a few steps forward like it's making it easier for us to bootstrap a solution um that that kind of works but still requires you to really understand what you are putting into your code base shipping out to users and and not uh you know uh getting rid of your responsibilities at the end of the day.

34:08I find that, at least for me, in the last year or two, going back to first principles, as always, has helped a lot. I've been working a little bit more closely with the Google DeepMind team on Gemini and its coding capabilities. And that has been a really good reminder for me of just understanding how a lot of these things work behind the scenes. If you remember that, you know, what is training data? Well, it's very likely going to be looking at permissively licensed, you know, code that's on GitHub or out on the open web. The patterns in that code are probably going to be reflective of, in many cases, like lowest common denominator.

34:51Things that maybe just work, are they going to be the most secure, the most high performance, the most accessible? Possibly not. And so if you remember that the training data itself still requires a lot of work to actually get things to a place where it maybe is of production quality, you sort of start to set your expectations a little bit lower when working with LLMs. You realize like, yeah, it will probably do a better job than me just copying and pasting snippets of code from somewhere else, obviously. But I still very likely need to do a level of manual work or a level of diligence on top of this to get the best outputs.

35:32Yeah, it reminds me a little bit of 10 years ago or so, 5-10 years ago, we used a lot of stack overflow because when you search for something, it was there. And so, for example, for email validation, like you would search, like, how do I validate an email address? There was a stack overflow question and it had like 20 answers. One of them was top rated. It was a regular expression. And what I did, and I think what a lot of people did, is I just copied and pasted because I cannot be bothered to define exactly the regular expression of emails, which is a lot more complicated than just things. So I just kind of, and if it was for nothing important, it kind of worked.

36:06But there were then complaints and like flags raised that a few of them, not this specific example, but they were insecure or they didn't account for edge cases. And a lot of devs, again, when you were in the mindless mode or it didn't matter or you didn't know better, you did that. And I guess we're going to have the same thing at larger scale. Like why did the bug, bug happen? And you're going to look back at the history. Yeah. Someone just looks good to me for, for that big pull request that was in the end generated by an AI. I think that this is, this is very much a smaller, um, point, a side discussion point, but I've seen a number of cases where people will now say, you know, hey, do I still need to use third-party libraries if I can just prompt a very slightly smaller version of a solution myself?

36:55Which reminded me exactly of this Stack Overflow copy-pasting the top response thing. And if you're a senior engineer, what you realize is, well, hold on. That also means that you are now taking on the responsibility of making sure that this is future-proof for security issues, for all sorts of platform issues that could happen. If you're relying on a library, it's perhaps easier for there to be a central point of leverage where those fixes can be made and then deployed out to people. If you own all of these different patterns in your codebase yourself, that also means that you're taking on that responsibility.

37:27Can be totally okay, but it's something that I sometimes see people just not being mindful of, of requiring a little bit of extra work. And I feel this is where we just need to remind ourselves that it's just engineering, right? It's trade-off. Do you take on the responsibility and the risk of maintaining this thing and the fact that it might have missing edge cases or whatever, or might not work correctly or securely, or do you take on a dependency, which has its own problems, right? There's now dependency, security, et cetera. But speaking of the need for software engineering, What are some new workflows, some things that we have not been able to do before as software engineers that we can now experiment with that you might be trying out with these AI tools that is just like is brand new?

38:11Yeah, I think for me, the thing that I'm most excited about seeing evolve is this idea of asynchronous background coding agents. A number of teams playing around with these ideas at the moment, Jules, Codex. We also see GitHub experimenting with some of these ideas as well. 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 a very interesting idea. If we can do that without merge conflicts in a way that is easily human verifiable. So again, going back to that human in the loop. I think that's very interesting.

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

39:41I'm excited about that. I think that the jury is still out on exactly what is the surface for being able to, you know, if you are the conductor of this orchestra, what is the right surface for you being able to manage all of these things? and what is a realistic number of tasks for you to be managing at the same time? Because even I, a number of people have shown off like, hey, yeah, I've got like 20 different terminals open and I have quad code running in half of them and then Gemini running in. And it's funny, but the reality is that you only have a finite amount of attention. And if you are going to be actually putting in diligence into your code reviews and into each of these workflows, you are probably only going to be able to do a couple of things at the same time.

40:30It all comes back to multitasking best practices. But I'm interested in that. I'm interested in seeing where that goes. Another thing that's very interesting is vibe designing. I'm seeing that part of product engineering, product development evolving a little bit. It was very exciting to see 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.

41:12Yeah, I heard an engineering leader or design leader at Shopify said that her team, every designer on her team, so not all of Shopify, has Cursor. And what they do is they create a figment design and then they ask Cursor to implement it. And then they show it to engineers. And this is not saying ship it. It's just more, we now have something interactive that we can work with as opposed to just what they used to do, which is sharing a figment design. And I was like, huh, this is something I've not heard before. Like, truly. Like all designers or at least on a team using the developers were like, I couldn't imagine designers using Visual Studio code for, I mean, I can imagine them being able to open it, but I couldn't imagine them.

41:53It's just not built for them. So this was really, really interesting to hear. And again, this wasn't some vendor advertisement or anything. Yeah, shout out to the Shopify team. Honestly, I feel like a number of them have been very open to sharing what's been working out well for their teams. And I've enjoyed following their story. I think that more of these patterns spreading is going to depend a little bit on training, on governance, on like clear boundaries between what is prototype code and production. But already being able to turn something static into a semi-functional like prototype is very cool.

42:29Are we going to see like everybody using cursor? I don't know. I think that I, at least for me, I see folks being able to accomplish the same outcomes from the tools that they spend the most time in or the bridges between tools getting better over time. But I still think it's very, very exciting. In the same way, we're also seeing lots of good conversations about PM and EM roles changing. PMs maybe spending more time on problem framing and metrics and policies for agents, EMs spending more time on evals and safety reviews and really enabling their teams to work with AI confidently. It won't change accountability for outcomes, but I am seeing a lot of good discussions about the need for taste in product engineering.

43:16where that's going to be what differentiates people. Because if anybody can, you know, look at what you've built and can use prompts to accomplish, you know, a similar set of functionality, the taste piece is going to continue to be very interesting for folks to focus on in the future. You and I have talked about sort of juniors and seniors. 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 write specs, decompose work, understand system architecture, review effectively, I think that they're going to become even more valuable.

44:02And that last 30 % that we talked about, I think it's leverage, not just busy work, but I actually think it's leverage. And a lot of surveys have been showing that trust is in a cautious but optimistic place at the moment. But that cautious piece speaks to the need for that human oversight remaining pretty central. Yeah, and if I think about, I was just thinking that when it comes to this idea of parallel agent, I don't think it's ever been done in the sense that as a developer, you were never able to do this. I mean, we couldn't even kick off and talk with natural language to a machine that would spit out code that actually compiles.

44:43Like I think this is new as well, but the fact that you can do it with multiple, it's not happened before and programming is a very, you know, you're in the flow, you work on one problem. When you stop working on it, you switch over, you get your context almost like the stack clears, you know, you load the new thing. It kind of feels like it, right? But on the other, when I think back to who are the best senior engineers I know and what do their days look like? Well, they're on a team with a few mid-level, maybe some interns or new grads and they're working on their stuff and then they're the ones who get the slack pink saying hey could you please unblock me so they context switch review the code you know like like criticize it or they block out time and they're review review review and like for every kind of senior slash often these are tech leads they have like a few people who are you know they're not agents they're people but they just review their work and they kind of orchestrate them a little bit on the stand-up, you know, they're in the planning meeting, they nudge them, they mentor them.

45:40So in some sense, I feel like seniors already do this. And if I had a magic wand saying, like, who would I expect in a few years' time to be able to manage multiple agents? Well, the senior for sure. Like new grads probably, like, I mean, I feel that will be a stretch for them, but they're not expected to have that. They don't have the expertise. So I wonder if some of these skills are somewhat transferable in the sense that And, you know, that senior, why could that senior do that? Well, because they understood the code base. They knew what good looked like. They were always thorough on their reviews.

46:12They never let things slip. They call out even the smallest thing. I completely agree with you. 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, you know, mentorship was always a big topic. And we talked about, you know, especially for folks who are joining a new team, the importance of like pair programming. I think we're going to see, you know, perhaps even situations 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.

47:00And really, again, using it as an additional tool in their arsenal to be able to help build up confidence and awareness of how the full app actually works. We're also seeing some interesting discussion about, you know, potentially new roles or refinements of roles, things like forward deployed engineers. I'm seeing interest in, you know, developers who are a little bit more embedded with customers who can build features rapidly with AI while feeding back requirements. And that type of thing might blur the lines between, you know, the developer, PM and designer roles a little bit. I'm interested to see where that may end up going.

47:39And I'm also interested in how, you know, just generally speaking, AI engineering is going to evolve how, you know, we approach education. Whether you're in high school or you're in college, like, are we going to be teaching people prompt and context engineering best practices? What does that all actually look like? How do we continue to enable people to think with systems design and engineering in mind? But I'm very excited where the education side of this goes. So one area that we've talked about was code reviews and how it's really important. It's a bottleneck and we should review the code.

48:13one thing that i'm kind of noticing on myself already is when i use these ai tools may that be cloud code or or agents or or even just the autocomplete i have a tendency to do tap tap or accept or just like accept all the things especially when i'm working on something that i mean it's it's not the most critical thing in the world and it's kind of it's easy and especially after i started to trust that it gets it right most of the time in the end i know i'm going to review but i find myself losing a little bit of criticality i'm not as critical you know the second day and the third day and and when i was the first time when i didn't trust this thing and i worry a little bit that with code reviews the same could happen you know lgtm looks good to me i mean i understand that's a google has it and built in as a as a feature in your code review tool which is a really fun tool as i understand but there is this risk there's always when there's risk, of course, that like you just kind of like, it's a lot of work.

49:11It kind of looks good and you're not looking critically. How do you think, especially on, you know, like proper teams, we could battle or we could do this kind of fighting against, like, yes, giving it a proper review, especially if we haven't written the code that much. Because I feel with writing the code, you have like two reviews. One is you're writing your own code. You're typing it out, which we're not doing as much anymore. And then someone else gives a review knowing that it was you who typed it out. I mean, it's always more fun to write code than to read and review it. Yeah, a little bit, right?

49:44Yeah, and I think more and more of our job is going to become about reading and reviewing code. There are a few ideas that I've tried to suggest to folks. Things like, you know, 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? Being cheeky, I would probably say like, yeah, I'm just going to go, you know, use Olama and a local model and I'll be totally fine.

50:31I will find some fallback. But 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, you know, relying on the AI. The models are going to continue getting better. Their ability to take in sufficient context from your code base is 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 it's 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 ten times and it still hasn't solved the problem you're gonna 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 i also think that there's a little bit of value in you know, doing some game theory around this, teams or individual people are probably going to start leaning on AI to do more of the code reviews to keep up with the, you know, pace and velocity of change coming in.

51:35What are those workflows going to look like? If you have an agent that's saying like, yeah, I reviewed this PR and it looks good to merge in. Are you actually going to trust it? Or are you going to go and do a human level review, even if it is maybe more shallow than you historically would have done, or maybe you're okay with spending 10, 20 minutes or something on the review. Like, what does that work will look like? In my case, even if an agent, an agent telling me that something looks good to merge is a signal. It's similar to a signal of like, okay, well, maybe a junior person on my team has also, you know, given this an LGTM.

52:12I'm still going to probably go back if it's critical enough. Or the CICD passes all the tests, right? It's green, all tests pass. Exactly, exactly. it's a signal. Signals are useful, but you still want to apply, you know, your lens on quality to it and take a look through and just make sure that you're confident. Things like having those tests, having, you know, whatever quality gates that you and your team discuss, like having those in place, all of these are good signals for building up confidence. So the more signals that you have to build up confidence, that things aren't going to go off the rails when you merge in.

52:48I think that's good. But I try to be very intentional with making sure that I'm not leaning on AI for absolutely everything. I may use it for many aspects of my life on a day-to-day, including AI coding, but I still try to make sure that I'm, you know, whether it's 20 or 30 percent or whatever amount of my tasks don't necessarily require AI. I still try to make sure that I'm using my brain to solve those problems myself. And I think that intentionality, like just be proactive with maintaining your critical thinking skills. I think that's going to help people. Yeah. And one of these things of like, you're still hands on two things came to my mind.

53:23One was a cloud code actually recently shipped. You can change modes. You can have explodes learning mode where it explains things. And you have a thing called learning mode, which is it pauses and says, you do this part, which I thought was really clever. I actually turned it on for something that I was building. It didn't work as I expected because it gave me a really weird task to do, But I see the potential and I actually, I actually intended to lean a bit more on that. And I think it's, I hope other tools will also do this as part of the developer. Like I feel, I do want to know that I can do it.

53:55I can do it, but how am I going to know if I'm, if I'm not doing it? Of course, you feel around a little bit with it. I think that is such a fantastic idea. And if somebody is a junior or you are coming in to a code base that you're not familiar with, fight that feeling of the first thing I'm going to do is try to provide value and I'm going to just prompt a new feature into existence. Maybe use the LLM to just explain how the code base works and just spend time like soaking yourself up in the richness of like, what is the code base? How does it work? How does everything connect together before you start prompting things into existence?

54:31I think that using it as a learning tool is a very powerful thing. We need more of. and this is also something what you said new new new joiners using a learning tool i'm hearing from a few companies that they're seeing new joiners onboard faster the ones where they can use these ai tools to explain stuff to them out like the club base is just a kind of a trusted person 24 7 you can ask questions on like a senior engineer who i mean you can ask questions anytime but obviously you don't want to do it like, you know, eight hours of the eight hour working day. Like you're going to keep your limits.

55:07And it's interesting how that is changing the dynamics at a bunch of workplaces that do have these tools. Absolutely. I think that, you know, my hope is that it's going to become a much more standard thing, treating AI as a learning tool. And it's not just for understanding, you know, a new code base. It can be very useful for understanding programming concepts or frameworks or architectural patterns. There are times when I want to be able to bring a feature over from one code base that is very different or written in a different programming language over to another. And I have found AI very much indispensable for those situations of helping me understand one code base and the path to being able to bring over something to a new one.

55:53And so encouraging your team to experiment with AI tools, sharing their best practices, making it a regular thing that people know it's okay to use it as a learning tool, I think is just going to be great for you as leads and managers. And you're also a manager of a team. And as part of this, obviously, you do performance reviews, promotions, help people basically professionally get better. How do you think the kind of your definition or what you're seeing in our team, a definition of a really standout solid software engineer has changed in the last three to four years since these tools have come out?

56:28What is new and what is the same? I think that what is new is the importance. 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. It doesn't matter if frameworks come and go, tools change, 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.

57:14And 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. I think that that has been very much a consistent thing that's been important. I feel like if you are a lead, now is the time for you to be helping your team through this moment in terms of showing that you're OK with learning as well. One of the things that I do every week, actually, is I spend a lot of time. I love reading. I spend a lot of time reading. I will, of course, read your newsletter a lot. I will read a number of different papers, white papers, blogs, watch videos, watch courses, you know, read announcements about what is new in AI, what is new in AI engineering during the week.

58:01And I will surface those things to my team in a newsletter. I will also surface... Oh, you have like an internal newsletter for your team? Yeah, I got an internal newsletter. I write it every Monday. So I'll be writing it after this. And I will include like, what am I hacking on? What am I writing? What am I thinking? What are the things that I think are important for our team to actually pay attention to? And in this time where, you know, you see so many people struggling to stay up to date, if you follow along on Twitter or other social networks, it can feel very overwhelming. Overwhelming, yeah.

58:34Because every few hours, it feels like something has changed in a fundamental way. And being able to sift through that and help people to just pay attention to what is actually important, I think that's a great thing for leadership to be doing right now, especially if you can guide folks towards, hey, maybe spend a little bit more time poking at this rather than that. I just want to say, I think it's not done because you're also staying closer to the industry, like to being technical. So maybe it's a stretch to say hands-on, but you're pretty close to that just by keeping up with all of this. Yeah, yeah.

59:07And I'll defer to people on my team to say things. But I think that I've generally had good feedback about this. I've even had other execs saying, hey, actually, I'm finding it really hard to stay on top of this. And your newsletter is helping me navigate this moment as well. And so I think that as a lead, being able to stay on top of what is happening at whatever level you're comfortable with or that your bandwidth allows, I think that that can be a really powerful thing for your team and will help you just keep your own skills relatively sharp. You know, we've been talking a lot about AI-assisted engineering.

59:45If your team do have to build out like AI features, a lot of this stuff is also going to continue to be relevant for them too, because you can help connect the dots between what is happening in the industry where AI is concerned that is actually important to their work versus what is not. And that's especially, I think it's exceptionally important in this moment where maybe there are things that they have not had to historically think about. Like, oh, hey, well, Model X is really good at image generation, but Model Y is really good at generating sound. I'm just making things up. But I think that it is really useful for you to be able to maybe highlight some of these opportunities in a more concrete way.

1:00:24And then your team can go off and spend time digging into it themselves. But they're not starting from a blank slate. Plus, I guess you're just showing that, look, look, I'm learning, I'm spending time reading, understanding, digesting, I'm doing some stuff on the side, which kind of gives the permission that it's okay to do it. And if anything, I mean, you know, everyone for themselves. But I would assume that right now, because we are having a big change in this technology it's a new tool a lot of capabilities it should be okay at most companies and most teams unless you're like has done crunch time shipping something like on friday to for for engineers to spend some time experimenting figuring out hey can i use this thing will it work for me you know when i talk with again the folks at shopify they do a lot of this and and in the end actually what what some people think might happen is like well people do less work actually what happens is they do the same work as they did before but they're way more motivated they tried a bunch of new stuff some of it doesn't work and it's kind of a you would think it's a waste but it's actually not it was learning and now they're a lot more confident about what works what doesn't you know they'll confidently say like okay we're not going to use uh ai for to generate this part of the code base for prototyping is great and so on so i feel like everyone's figuring things out so it's it's almost a waste to not get permission and how better way to get permission than to show that you're doing this as well?

1:01:48Yes, yes, absolutely. AI is a tool. Tools that can compress work, I think can also lead to good moments of clarity. And it is faster than ever to try out certain classes of ideas. And I think that that efficiency can also sometimes highlight the importance of our human qualities when it comes to like judging. What should we be moving forward with? What should we be ignoring? What should we be minimizing? I think that trying to embrace AI in this moment, and figure out what works well for you and your teams is a great use of time. I did want to say, if there are folks in your audience who are in enterprise, especially, I know that having gone through this journey, there may be teams who feel like, oh man, it feels like startups are able to move so much faster than we are, or they're able to use all of these great new tools and these models, but we are still waiting on the enterprise-friendly version of these things.

1:02:41And I've talked to teams where they can sometimes feel like we're waiting, we're waiting, we're waiting to be able to try out more of these tools. What I ended up doing in my team was we were similarly, you know, a couple of years ago now, we were similarly waiting for the company embraced official way of doing things, but that didn't stop us from being able to learn. So I encourage people, well, a lot of us are hacking on side projects, right? At the weekends, we can try out whatever, you know, third-party tools, third-party models, our own models, like we can try out and learn and that doesn't have to be a big blocker for you.

1:03:15So you can still help your team along this journey without necessarily having to do a lot of that waiting. So just wanted to let folks know, there are many paths to being able to embrace this moment. Yeah, and I think the consensus is pretty much that these tools will be widespread. They keep changing and they're already contributing to a lot of teams' code bases and people are using it. So might as well just use it because it takes time in the end. And so the earlier you start, you'll have plenty of learning to do regardless. Yes, absolutely right. So as closing, I just have a few rapid questions.

1:03:49So I'll just fire them and then you tell me what comes to mind. What's your favorite programming language and why? My favorite programming language is JavaScript. I thought you might say this, but I wasn't sure. Of course. You wrote books about this. My favorite programming language is JavaScript. And it's 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's very open. And I think that there's something very liberating about that idea.

1:04:25So that is one of the reasons why I like JavaScript probably the most. I like it. I'm always surprised when a software engineer says JavaScript because we know that compared to other languages, it has a lot of limitations. And there's been books written about it. as well. But I cannot disagree with it. I love it. It is true. 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, and I'm biased, I have a book out about this as well, is probably Bolt, Bolt.new. Bolt.new is one of those Vibe coding scaffolding tools that people can use.

1:05:04They very recently added support, actually, for being able to use custom agents. So you can use Cloud Code, for example, to build your Vibe Coded app. And the output is generally very high quality, great design. So I've been really enjoying that. And the team have been, I would say, on the edge of offering some really great integration. So I've been liking this idea that many Vibe Coding platforms are now starting to think about the integration layer. So how can we automate the idea of you needing to use, you know, like a super base or an authentication provider or these other things. You still need to pay, of course, attention to all of the code that's being generated.

1:05:43But being able to remove more of that setup friction, I think, is amazing. And I guess the fun fact on Bolt.new is they started off as a company called StackBlitz, who built a really cool online editor, really advanced. And then they moved over from that to Bolt.new. So there are software engineers behind it, again, who really know their craft. Yes, yes, absolutely. And finally, what's a book that you would recommend? So the book I'm going to recommend is one that I think covers, I would say, career paths and best practices for software engineers in a way that I found very compelling. It is by you.

1:06:19It's the Software Engineer's Guidebook. And of course, I'm playing to the crowd, but it is genuinely a very, very sharp book. From all the reviews that I've read about it, other people have also found it to be an excellent read. It's on my desk, but we didn't talk about this, by the way. So this recommendation came just as a surprise to me as a stout. Thank you. Genuinely an excellent book. I guess if I wasn't going to, of course, 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 Huynh that is also worth taking a look at.

1:07:00very, very well reviewed, a very, very thorough book. And I also recommend folks check that out. It's such a good book. I feel if you know the concepts there, you're pretty well off. And if you don't know them, you're probably going to be, you know, still finding your way. So big plus one for that. Addy, this has been great. Thanks so much for doing this and this really awesome conversation. Well, thank you. I really appreciate it. I hope the folks, you know, if you are interested in this space, Beyond Vibe Coding is out now from O 'Reilly. Hopefully it'll be useful to some people, but it's been a pleasure having this conversation with you.

1:07:33Yeah. And I've been reading the book. I really like how it goes into the practicality. So I can also very much recommend it. Thank you. I hope you enjoyed going Beyond Vibe Coding, pun intended, with Adi Osmani. One of the things I took away from this conversation is how it's really important that as an engineer, we keep understanding exactly what the LLM does and why. And if we don't understand it, we just stop, understand it, and then move on. As long as you understand the LLM, you are in charge. But once you stop understanding, it's in charge, and you can kind of become helpless and out of your depth.

1:08:08For more tips on how to get up to speed with AI engineering, check out Deep Dives into Pragmatic Engineer that I wrote, which are linked to the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating for the show. Thanks, and see you in the next one.