The Last Software Engineer

What is up AI Coding Summit? My name is Kent C. Dodds and I'm very excited to talk with you about the last software engineer. No, just kidding. This is a metaphor. It's not actually like it's time for the last software engineer to put in their two weeks notice or whatever. But we want to talk about durable skills.

Now, if we were in person, then I would invite you all to stand up with me and we would do air squats together to get blood moving. But remote just kind of makes that a little awkward. So we don't do that remotely. But if you haven't moved around in a little bit, then you need to get your body moving. Get the blood flowing. It's good for your brain and it'll help you remember what we talk about today. So make sure you do that.

Alright. Did you do it? Great. Let's keep going. This is the work that is to be done. It's the whole thing, and it spans across the two stilts, the stands. And if you don't get the whole job done, then this box is going to fall over. So the work that needs to be done can be done either by you manually or by you using the tools that you have at your disposal. So this is your editor. It's your C.I. and C.D. It's like all of the tools that you build tools, tools that you pay for. All of these tools help you accomplish the work that needs to be done. And in recent years, the tools are doing more of the work that we traditionally have done, which leaves us with less and less to do, but not really less to do. We can accomplish more work. So you can imagine many of these boxes to accomplish more things. So we're not necessarily doing less like I don't know about you, but I feel like I'm working a lot more than I used to. But we're accomplishing more.

But the point here is that the tasks that we do to accomplish the same work have been reduced because the agent is taking over so much of what we do, the actual day to day coding and that sort of thing.

So the question here is, OK, well, what do we do as this continues to reduce? Like, what do you actually do here? And if you were to watch X.com or any other site, you would say, OK, well, it's reasoning. Oh, no, prompt engineering. Yeah. Which prompts have been cracked so we can make prompt engineering hacks and prompt engineering? It's a real thing.

And here's the playbook for prompt engineering. And let's talk to this prompt expert. And I'm spending all day prompt engineering and everything is about prompt engineering. And if you're doing fine tuning, then, yeah, you're missing it. You've got to do prompt engineering. And here's a bunch more resources for prompt engineering. And are we automating prompt engineering now? Yes or no? I don't know. Let's let's automate. Oh, wait a second. Oh, prompt engineering is disrupted. Now we're seeing that there are problems with prompt engineering.

OK, so what's next? Well, oh, no. You know, fine-tuning is actually better than prompt engineering, according to this. So, OK, wait a second. Now SWIGs is saying it's flow engineering. That's the thing that we should be doing and following. Oh, gosh, no. Now we're not even writing the code or prompt engineering anymore. We're not writing the prompts. We're having AI write the prompts now. We're loop engineering. We are loop engineers now. I don't know about you. This is not the end. That's for sure. But I'm exhausted with all of this stuff that we're expected to keep up with.

And it's really irritating to spend a lot of time investing in one particular way or workflow and then only to find out that now that's not the way we do it anymore. It's this way. And this isn't just old man yells at the cloud here. This is just a dude who wants to actually ship good stuff and not spend my wheels on the different activities that I could to actually get the work done. So here's the question: Yes, AI agents are continuing to improve. And that's why we're seeing this rapid evolution of how we use AI agents. But the question is, now, what is the ceiling of the AI agents? How good can these things actually get? Is it really hyperbolic? Or are we going to reach AGI? Are we already at AGI? I don't know. But the fact is that this is the future. We cannot predict it. It could be up into, you know, like straight up to the moon. Or we could be in an S curve. And now we're starting to plateau with the capabilities of these models in these tools. If you'd asked me a year ago how good we would be with our AI coding agents, I would not have predicted how good we are now. And so that makes me even less confident in my ability to predict how good we're going to be in the future. So nobody really knows.

If somebody tells you this is the way it's going to be, without acknowledging that, like, they don't actually know, then I'd be suspicious. I need to look into it. So is it eventually going to be where the AI just does all the work, and we aren't valuable in that case at all? That is a big question. I don't think that we can actually answer this question. And honestly, I don't think it's a useful question to get an answer to anyway. Because what are you going to do in that world, like, where there's nothing left for you to do to get the work done?

And, I mean, that's a little bit depressing. I think some of you can relate to me having—I've had two existential crises, and maybe like two and a half at this point since the beginning of this year, thinking, okay, what do I do? And what is my future? What are the things that I'm going to be able to do in the future? And so what I kind of concluded was, okay, let's pretend for a moment that it is possible that eventually all the work will be done by AGI. That is not really useful to plan for. Who knows what the world is going to look like, what my role will be there. So what if we take a step back from that?

Well, the AI, like, if it's not able to do all the work, then of course it's going to fall over. There's going to be some sort of slice left over. There will be the last software engineer who's still filling in the gap. What is that last software engineer doing? That is what you are doing. What's happening in that slice? And if we can answer that question, then we can know, rather than chasing all of the things that are going on in the software world of how to use agents and whatever, that continually change and the agents continue to evolve and take more of our work so that all the stuff that you did before is not necessary.

If that were to happen, we take a step back, there's a thin slice of stuff that is probably valuable today and will still be valuable then. That's what we want to learn. And that, my friends, is what I am going to tell you is called judgment. Or I kind of encapsulate this in the term of product engineering. So it's still a discipline of software engineering, but there are a lot of pieces of software engineering that are being eaten by AI.

And I think the more human side of software engineering, which is the product engineering piece and judgment, that's the side that will be the slice that's left over when we're done. So let's talk about this. I have a metaphor that I really like. That's this quiver of arrows. So I've got a quiver on my back full of arrows and I've got these different targets that I'm going to hit. And somebody tells me, OK, hit that target. And I've gotten really good at hitting targets. Like, look at this guy. He has spent countless hours getting so good that he can fire an arrow through a ring and hit the bullseye. Are you an eagle-eyed bow hunter?

We're taking into account the wind speed and everything else so that we can nail that target every single time. And the change that's happened in recent years is that where we used to have a regular bow and arrows, and yeah, the technology for the bow and arrows would improve. We've seen a recent massive change into arrows that are effectively like homing devices where it's going to hit the target every time. Now, we're not quite to that point. There's still a lot that you need to do. And at this conference and others, you're going to have to or you'll learn a lot about what you can do to still improve the aim and actually hitting the target.

But because we have this, we now get a new shooting range. It is filled with targets. You can hit anything. Some of them are moving. They're targets that you never would have imagined trying to hit before we got to this level.

Now I've got a little fun illustration for you. Have you heard of the Patriot Arrow from Robin Hood Men in Tights? Let's watch this really quick. Okay, so maybe our agents aren't quite that good yet. But maybe they'll get that good eventually.

In a world where your agent is like the Patriot Arrow that is just going to hit the target no matter what. The question of how good you are at aiming at the target is less emphasized. It matters a lot less. And the question of knowing which target to aim for is a lot more important.

So I've got a podcast called Become an Epic Product Engineer and I've got a lot of guests on there that have some really great insights. I'm going to read a couple of the quotes from them to you here. So Wayne Allen said building the right thing is downstream from building the right thing. It doesn't matter how good your solution is. If you built the wrong thing, nobody's going to use it. It doesn't matter. And he gives a really great example of a product that he worked on that they spent millions of dollars on it and nobody used. So definitely listen to it.

Then he says product engineers care about customer experience and the commercials of the product, not just tinkering with tech but getting an outcome. So that's what your job is now. You should actually care about getting an outcome and measuring the things to determine whether the outcome is good. Building the right thing is a lot more important than building the thing right. They're both matter. But if you fail on one then you fail on the whole thing. So build the right thing first.

Alright, then Dax Rad, also great. He said I've got all these ideas I'm going to ship. The agent's never going to push back. It's just going to match your momentum. And we're seeing this a lot where people are just not being thoughtful about what is being built and are just pushing, pushing, pushing. And it's resulting in slopware, which is not a very fun thing for users to use. We're just throwing things on the wall and seeing what sticks. And that's not very kind to your users. And people are noticing and they're going to follow the ones where the product is actually solving their problems. Will King said you're using AI to bring things for you to use your judgment on.

So give yourself as much information as you can to make a judgment. So that's the point right here is that the AI is not going to take your role as the judgment maker, the decision maker. You can use AI to gather the information you need. Tell me about the system. What are the primitives that are available and the architecture and where the constraints of things and what would be the challenge if we went this direction versus that direction? Like gather all that information. But at the end of the day, you are the one who has ownership over this product. And it's your judgment that's going to decide between one or the other. And if we've all got this tool, the thing that differentiates one product from another is the one that has a team of software engineers who have a really good judgment. So that judgment is a uniquely human skill that is going to differentiate you from everybody else who has the same tools you have.

Deciding what to build. I think I'll summarize it as just being curious. This is a topic that comes up on the podcast a lot. So just being curious. See what problems are there and just trying things out, prototyping and building things so you can feel what they do. And also, do they actually solve the problem for users? So Ruben is really into this rapid prototyping and this is one of the really nice benefits of Agents is that you can do that. Experiment, watch users use it and be curious. Just try a lot of things. But this doesn't mean like shove everything into the product. No, no. A, B, test it, whatever, so that you can iterate with the users. You need to be thinking about how does this software impact that user experience rather than just like, wow, this is really cool solution. Like, dude, to what problem? That's the question you need to ask.

You just have to botch it enough times to know what works and what doesn't work. Judgment calls on what's high impact to get easier over time. And I completely agree with this. There's no shortcut to experience, but there are activities that will get you that experience faster. And that judgment, that design sense. And so not just visual design, but systems design sense. And so you have to iterate a lot. You have to spend a lot of time trying different things.

If you're just doing the same thing over and over again, then that's not going to be as helpful. So Dylan Mulroy, great quote there. And then Jack Ryan, also awesome guest on the podcast. He said what to build, how to build it, when to build it. That's still our choice. Customers don't have to deal with the consequences of being wrong. It's very important for as you're getting this feedback from your users that you don't just take it and turn it into an implementation. Jack has an example in here where they did that and nobody ended up using it anyway. They ghost you. And so you have to be intentional about what you are building and how it fits in the greater product direction and vision. You have to have a vision.

So also really key here. And then Lucas Varga said you own that feature, which means you might have to go and talk to a bunch of customers and understand how that feature that you're owning will ultimately impact things. And you might have to go talk to stakeholders and people that before you were just totally shielded from. So if you've been really comfortable and happy with a product manager standing between you and the customer, those days are over. You really need to be very involved. Now, the product manager can still be primarily responsible for communicating with the customer and other key stakeholders. But if you don't understand where these tickets are coming from and what the ultimate purpose and the vision and the jobs to be done of the software features that you're implementing, if you don't understand what those are, then that's going to be really hard to differentiate yourself from the AI coding agent that you're just sending tickets into. So you need to be very involved in the upstream and downstream effects of your implementation.

Product engineering is the discipline of creating implementation decisions to product consequences. So or connecting the implementation decision to product consequence, both, like I said, upstream and downstream. So where are these product requirements coming from? And how do I make sure that I marry the implementation or the system design, the technical expertise that I have with that need that the users have that we're trying to build this software for? So to be clear, the product engineer is not a product manager. These are distinct things. Your technical expertise is definitely needed in this space, but you're not able to just take tickets and turn it into implementation. We're moving closer to what you would historically have thought is the product manager's job. So one or a couple of the things that distinguish a product engineer from a product manager is that the product engineer asks questions like what job is the user hiring this for? That sounds like a product manager question, but no, this is a you question now. And then the corollary to that being, how does our current system serve that particular use case? What are the gaps that our system has? How will we know this worked? What are the observable outputs of our system, and how can we improve those so that we know that this worked? And what must we not break as we make changes to those things, and how can we make sure that those things don't break through tests or some other validation? Who loses if we ship this? So there are other users who are going to be impacted by us adding a button here, and let's make sure we understand those tradeoffs. So we've got metrics for our app. Is that metric a proxy or the actual outcome? These sorts of questions you need to be able to have the answer to as a product engineer. And how do we undo this if we're wrong? Being like A-B testing, I think that this is becoming a lot more valuable in this age where we can ship things faster and iterate a lot.

You don't want to just ship a bunch of slop to all your users. You have a particular set of users that you're trying to solve their problem. You A-B test it and let them play around with it so that once you know for sure that you're solving that problem, then you open it up to everybody else. And then it makes it really easy to undo it.

You're like, no, no, no, we did this wrong. Okay, so let's talk about all of the claims that I just made. What if I'm wrong about this? What if instead of, you know, like going up all to the moon, we are just about to plateau? Well, the good news is that being a good product engineer is something that is useful, even if you're still firing with regular arrows at targets just like this. Being able to know which one of those targets to hit and which will be the most valuable is really actually quite useful. And making sure that you're hitting the right target and that you're hitting it in the center, that's still very, very useful.

And honestly, it's the hallmark of history's greatest software engineers. So you've got Drew Houston, who is like, you know what? I'm going to make our sync, but simpler. And you've got Paul Butchett, who's like, you know what? I'm going to make Yahoo, but you never have to delete an email and you can search your emails. That's a product decision. The technology wasn't necessarily better. Maybe it was, but that's not why people got into Gmail. It was because the product was better. And then Kevin Systrom built Bourbon, which was like a four square clone. And then I actually watched users use it and realized that users only really care about the photo sharing. So that turned into Instagram, and a user made a lot of money doing that. And then Juan Com, or Jean Com, built WhatsApp.

And despite everybody saying you need to add all these features, he was just notorious for saying no, no, no. We're not adding all of these features, being very intentional about what he's adding, and got acquired also for a lot of money.

So Sir Tim Berners-Lee, let's go back to the Internet, deciding that, you know what? This needs to be an open protocol. That was a decision. And I think you look at some of these people and you're like, oh, yeah, but they're all like business people. Well, they are now. They're engineers. And this even applies to open source as well.

So open source is a product. The web standard, it's a product. You have to convince people. And so even if you're working internally, then what you're building is a product for the users that you have, which are internal. So are you going to be the next great product engineer? Maybe you don't build a product that everybody has heard of, but what you're building does still matter in the realm of your context and the users that you have. And you need to be thoughtful about that.

So I've just got a couple of resources for you. The Last Software Engineer. This is the blog post version of this talk. I also reference the Become an Epic Product Engineer podcast. You should definitely take a look at that. And Epic Product Engineer is where I'm doing training on how to become an epic product engineer. So you take a look at that as well. And with that, I'll just say thank you so much for listening. And I hope that you take these arrows that can hit the target every time, maybe in the future, and make the very best products that you possibly can. Have a good one. See you later.

Welcome back. Well, first of all, thanks a lot for your talk again. That was really great. And I think that's one of the hottest and maybe most important topics for the last year or so. So thanks a lot. That gives a lot of food for thought. And while we are waiting for a few questions, I have one. Basically, that's the continuation of your talk. We are observing how the world changes, especially for us, deaf engineers. And that's really a lot. And you said it yourself. So I wonder from your experience, do you see this hype around AI techniques and even maybe software? Is it converging into some direction? And if you see that, maybe you can tell us a little more about it. What are the mainstream products maybe you see and things like that?

Yeah, I think that without any new technology, there's going to be a lot of chaos around what we're playing around with and trying to do. And the challenge with AI or a challenge with AI is that it seems like it's a new technology every couple of months. We just got Fable 5 back. And that has been – my ambition is a lot bigger than it was before with the sorts of things that I ask AI coding agents to do. And so I do expect eventually we're going to get to some point of normalcy. But right now, it's just it's really chaotic. And the advice that people give you on AI workflows and things are great for today, but likely going to change in the coming months, which is why I'm so interested in teaching durable skills.

Totally. That makes a lot of sense. I actually see some of the questions appear right now. Let's start with the first one. It became so easy to copy ideas. So what is your take on that? So imagine someone has a brilliant idea, but people just copy it in a weekend. I guess continuing the question, would it be still relevant to even try your own ideas? Or maybe it doesn't deserve even time spent? Yeah, you know, I'm afraid to say that my answer will probably not be what lots of people want to hear. And that is – there are a couple of facets to this. One, distribution and marketing are going to be a big differentiator. And so that, yeah, often that's going to require money for advertising or whatever as well, or buy in from influential people. But then the other thing is, even with AI, even with fable level models, you still need to know how to build good primitives. You can't just take the technology we have right now and give it to a non-technical person and expect them to be able to build maintainable, long-term software. They just aren't able to do that yet. So yeah, I think eventually maybe the AI is able to build maintainable software by itself, but that's not where we are right now. If we get to that point in the future, then as I showed, like all of those targets that you have an option to aim for, I don't think that anybody will be able to aim for every single one of those and fire at everyone. And part of the reason is technical. I just think it'll cost too much. But the other part is you only have so much time and energy to – or your users only have so much time and energy for attention. And if you aim for every single one of these things, then your distribution channels are going to get tired. And so people will still have to pick and choose the ideas that they implement. And right now, if the models are so good, well, why don't you just reimplement Google and beat Google at their game? I think we can all think of some reasons why that wouldn't work out. And I think that those sorts of things are going to continue.

That's awesome. Totally. I see there is one popular question in the chat right now. As a lead, any ideas about how to instill this mindset into my team? Yeah, great question. So one of the challenges here, one of the most important, or one of the skills that will help the most with that is ownership and accountability. And that is really hard to instill in people. I mean, it's definitely a learned skill, but this comes down to the culture that you have on the team and the hiring. What ownership means is that somebody is going to look at a feature and feel like they have the power and autonomy and permission to own the whole thing and be responsible for the outcome.

And also get credit for it. And they'll just feel like it matters a lot for that feature to be successful, which is very different from the ticket takers of the past who would just take an issue, implement it, and then move on to the next one and not really care about the upstream or downstream effects of what that implementation was about. So how do you instill that mindset? First, you tell them, and then you give them the autonomy to be able to own something. And hopefully over time, people start taking some ownership.

Yeah, great one. Ownership and accountability noted. Yeah, let's go to the next one. To narrow it down a little if we can, where do you see the role of a software development engineer in tests going? Oh dear. So I've been teaching people how to test for over a decade. Testing is, I think, a really valuable thing. I would say that most software engineers are moving into like a factory engineer, software factory engineer, where you're building. And honestly, this is always what we kind of called our what we're doing or what we're trying to do is build a better factory. It was just that the pieces of our factory were manual labor from humans. Now we're automating a lot of that.

And so for the testing side of that, one of the really important parts for an agent to close the agentic loop is to make it so the agent can verify its changes. And so an engineer who is focused on testing would be focused on building out really great primitives for agents to verify their work. And I think that software developers should be using agents to help accomplish that. But that's the time and tokens that they're spending. Yeah, absolutely. And I guess to finish this line of thought, a similar one but more about your experience. What was your biggest challenge in adopting your pre-AI product engineering skill sets to the ever-emerging agentic coding world? I think that so many of the skills that are kind of latent skills that you don't really know you have that just kind of naturally come from experience become really valuable and important with AI.