At Google, 75% of the code that they ship to production is generated by AI, but they still have engineers. So what are the engineers doing while they're over there? What are the durable skills that will keep you employable and valuable in the world of software development in 2026 and beyond? That's what I want to talk about. So this actually comes from an article that we're going to look at later. But for the last 10 years, I've been teaching you all how to build excellent quality experiences for users and implementation has kind of taken a downturn in how valuable or scarce that actually is now because AI assistance. And who knows what it's going to look like a year from now. Certainly I didn't predict a year ago that agents were going to get as good as they are now or AI coding assistance. And so I have no idea how good they're going to get a year from now. But there are skills that were valuable 50 years ago that are valuable now and that are going to be valuable as long as our industry exists. And that is what I want you to learn. And I want to talk about some of those skills that you need to focus on and develop in yourself to make yourself still employable and valuable going forward. And so quickly, those are problem clarity, domain depth, judgment, could versus should, user empathy, feedback loops, systems thinking, agent fluency, and ownership. So let's talk about these in some groups. So I've got the clarity and judgment group here. So the clarity idea is that you need to be able to turn some vague prompt or some vague requirements, some vague product, whether you're building a new product or adding a feature to an existing one or solving some sort of bug, whatever. It's a vague idea in somebody's mind. You need to convert that into some solution. And that is a tricky thing, but it's a skill that is really valuable, very employable going forward into the future. You also get a lot of value out of having deep domain depth, understanding the domain really deeply. And this is something that will provide a ton more value than the software developer that just takes tickets and implements them, really understanding what are the jobs to be done by the user? What's the actual problem? I see these three different problems, and I could implement solutions for each one of them. But actually, if I take a step back and I understand what the job to be done actually is, oh, okay, I can actually implement a single solution that solves not only those problems, but actually a whole host of other problems that we didn't even know we were going to have. So this isn't just some generic sort of, oh, yeah, learn cybersecurity or whatever, but like really deeply under, and not to say like you can learn cybersecurity to be really valuable right now, especially, but like really deeply understanding the domain, whether that be healthcare or FinTech or DevTools or whatever, whatever it is that you are currently employed at or whatever domain you want to be employed in, understanding it deeply. And it doesn't have to be something where you are the user. We don't all work at DevTools companies. You could work at some biotech lab and just really understanding what the people in that domain do and the problems that they're facing is going to make you a much better judge of the software that you should be building, which is the next skill here. And that's judgment. Agents are really good at telling you, yeah, we can do that. Sure, of course, like, okay, it's going to take, and maybe they might predict it's going to take three months. And I'm like, no, man, you're going to do this right now. But they can say, yeah, we can do that. But humans are the ones who decide we should do that. This is the skill of judgment. In the Become an Epic Product Engineer podcast, I'm going to reference that a bunch here. One of the episodes with Wayne, he said something that has just really stuck with me. He said, you want to build the right thing before you build the thing right. And that is a really valuable skill that you have as a human that an agent just doesn't have. You don't know whether or not something should be built. And that's the value that you can offer even as agents continue to get better at building in general. Really, you should not be optimizing what should not exist. You should spend your time optimizing solutions that should exist. And it's your judgment call that will help you to push back on the wrong tickets or to just really understand what the problems are so that you're building things that should actually exist. Okay, so how do you do this? How do you develop like problem clarity and get really good at that communication? How do you develop that judgment? You do this by being in the room where those judgments are made, where those decisions are made. So there are rooms where this happens, where you get that ticket, like find the upstream from where your ticket is coming. And say, I want to be there when that ticket was created, when it was decided we needed to do that. And maybe you were there. Maybe it was sprint planning. You know, go even beyond that. Why did we decide that this is a priority? And you can just say, I just want to sit in the room. I'm just going to listen. Like, I don't have to participate necessarily, right? First, I just want to understand what the problems are that we're trying to solve and develop the right vernacular and understanding that domain. You need to like ask, get yourself in kind of a loop. This is something that Jack Ryan on the podcast also said is like, you loop around. Why is that a problem? And why is that a problem? Like, why are you trying to do this? This is something Aaron Francis also said. What are you trying to do? Like, what was the expected behavior? Why did you expect it to behave that way? And why didn't it behave the way you expected? Or what was it about that? And so maybe you can change what you built so that the expectation is more natural. You understand what it's doing. Or maybe you could expand what you're doing to handle that case. But like understanding the core issue. This is like the work that you do before the ticket exists. It's before the prompt is sent. And so that will help you develop clarity around the problem space and judgment on what you should be building. Next thing I want to talk about is I want you to put yourself in user shoes. You need to develop some empathy for the user. So even if you're not in the room with the user, just put yourself in the user shoes. And then try to get in the room with the user. Try to watch the user use your stuff. And if it's painful to watch, that's great because it helps you know that, oh, man, we really need to improve this. If the user is hurting, you should feel that pain too. And that was something that Dylan on the podcast also talked about. You want to set up a system where user pain is felt by you, whether that be some sort of observability thing or whatever you put in place or just tighten that feedback loop with that user. That's another thing. This is not just like a quarterly thing. It's more of a daily signal. This is something that Dylan set up at another company. He had a Slack channel. I don't know if he set it up, but there was a Slack channel that would just take data from all sorts of sources, whether it be X or Reddit or Discord or whatever, and fed it into a single Slack channel where you could just sit there. And as Jack Ryan, another podcast guest, as he said, he just let it wash over you. And that develops this intuition inside of you. Swizek, another guest, a future episode of the podcast said that support is just a gold mine for stuff like this. You should spend like an hour just sitting with support. And that it kind of becomes a feedback loop so that you kind of figure out what are the things that people are really having trouble with. And so like to practice this, I recommend that you go out to lunch with support, listen in on calls, just ask them, what are the things that people keep asking you about? How could I reduce the amount of time you have to spend fixing people's problems by making it so that those things aren't a problem in the first place? Find all of the different sources where users are providing feedback. Maybe you're building a DevTools company and okay, so that's going to be, you know, maybe some social media, maybe you've got a Discord, whatever. Maybe you're building something for like new moms and they're not necessarily on the same platforms of social media that you're on. But find where they're talking about your product and figure out how you can bring that in as like a daily feedback loop for yourself. And another way you can practice this is just build stuff. Build a lot of things and, but build things that have user signal where you are not the only user. You don't want to just build this in a cave. You want to build this out on the mountaintop and look down at everybody who's using your stuff. I know that metaphor is going in a funny direction, but the last thing, or the next thing I want to talk about is the way that you think about your software. It used to be that you could just take a ticket, implement it, and then go home and be good and not worry so much about it. But there was somebody up there above you in the org chart who was thinking about the system in which you are operating and they're thinking, okay, how do I make sure that Kent doesn't write a test that looks like this because this is a bad test? Or how do I make sure that he writes a test in the first place? Or how do I make sure that we don't ever have this category of bug again? That somebody is you now because you have a bunch of underlings underneath you. Those are the agents that are working on all of this code. Your job is to build the just beautiful system for them to operate within. Your job is to understand that system and to consider every single thing that comes in where now, okay, we've decided we are going to do this. How do we factor that into the existing system? Does this require an extension to the system? Do we need to make this system capable of more? Do we need to make more primitives? Is there a way that we can expand a primitive a little bit to support this thing or do we need to make a separate primitive? These are the sorts of things that you need to be thinking about and this is probably the most valuable skill that you can offer as an engineer beyond what just a typical product manager is going to do. Yes, understanding the people and everything that's typically been the product manager's role. If you don't understand the users of the system and everything, you're going to be a much less effective product engineer. The engineering side of the skills that you offer are really, really valuable if you understand the system. Every module boundaries like the code syntax and stuff like what's inside of those module boundaries, that's becoming much, much less important as agents continue to improve, but being able to visualize all over your code base how the different pieces are put together, how they communicate, how those things are tested, you are the architect. It is your job to verify that outcomes match intent and I think that agents are going to help us do this, but you do need to be the one that's thinking about that and making decisions around that. That's one skill that you need to develop. Also like closing that implementation loop, again, you used to be the junior who was working inside of somebody else's system and now you are the senior or the team lead over this army of agents that are working inside of your system. How much do they like it there? Do they hate your system that you've created for them? You can use agents to improve that system and just think about like, okay, how's my testing story? What does CI look like? How is observability? How easy is it for me to spin up a cloud agent that can work on this independently and how well documented is it so that it can find its way around things efficiently? How up to date is that documentation? Do we have harnesses and guardrails and fast feedback for when things go wrong? All of these things are your responsibility. Ruben Casas in the podcast also talked about how important it is that architecture, testing and guardrails, they are more important now when agents are the ones touching the code, not as much us. Matt Pocock has also been talking about and teaching about this a lot recently as well. So maybe in the future, there will be some sort of meta agent that will be responsible for smoothing out this system, but I don't know about that. And certainly today we are going to need to be thinking about these systems. And in fact, even like today, today, we've got this article by Matt AC from InfoWorld that is really, really fantastic. This is where I get the stat that Google's Sundar, oh shoot, I don't know how to say Sundar's last name, Pichai, he says that 75% of Google's new code is AI generated and reviewed by engineers, like that's a sobering stat, honestly. What's interesting is though, they haven't just like gotten rid of all engineering. So what are the things those engineers are doing that is still valuable enough to keep them around? And that's all of the stuff that we've talked about. And Alex here, it talks about, or Matt talks about all of the things that are really, really important. So OpenClaw has just been getting an enormous amount of vibe slop pull requests. And the problem is that because of this, they're skipping the parts of software development that actually matter, like design, judgment, testing, ownership, all of the stuff that we've been talking about. And the reason for that is, and again, here we also have like, you need to be able to understand, maintain, explain, and manage a large software speed of development. It was really the right metric for all of this stuff. There's actually whatever you measure is what improves and moving fast in the wrong direction is not what you want. So the problem is abdication. We've abdicated our responsibility for maintaining a code base, a product. So it's cheap to generate this kind of code where you just, here you go, like tell the agent to do something. It's a lot more expensive to review. And I actually, I think that reviewing is something that we're not going to have to do quite as much in the future as far as reviewing the syntax and the code. And I go ahead and drop a comment if you totally disagree that you're, I can't know you've got to review the code and maybe you're working at like a hospital or something making medical devices. I hope you're still reviewing the code. But if you're working on like some SAS or whatever, I don't think you necessarily need to review every line of code anymore. And I think that agents are going to continue to improve such that you don't need to look at the code. And instead the agent is going to communicate back to you, okay, here is the architecture in which we are operating. We are working within the system, we're expanding the system, we're like whatever. And I think in the future, it won't be expensive to review, but it'll still be cheap to generate and it will be really expensive to go back. And in fact, I think that this token maxing thing that some people are doing is a bad direction and in the future, employers are really going to be thinking about, you know, I don't think that I want to spend $15,000 a month on this engineer, building out whatever or $1.3 million a month on this engineer that's building out all of this AI generated stuff. I need to get down to like what is the product that they're actually creating and oh my goodness, this one engineer who has a really good understanding of the system, whatever, they're able to produce a much better result with many fewer tokens. And so while it may be cheap to generate, I don't know that cheapness is generally applicable to every situation. I think that some people can be a lot more token efficient and that will be a valuable thing in the future too. I think it's valuable even now, literally valuable because you're spending less money. So the assertion that Matt here makes is that the friction is the point, the friction is where judgment lives and this is interesting because I think that we actually don't want friction. The friction is not the point. I disagree with this assertion. The judgment is the point. And so if you can find a way to drastically reduce friction but maintain the judgment, then that is an enormously valuable skill that you should develop in 2026. And we'll talk about how to develop that. So again, talking about bad metrics, the worst metric is percentage of code generated by AI. I opened this up talking about Google and 75% of their code is generated by AI. We don't actually care about that. It doesn't matter. What actually matters is the product that is generated and solving users' problems. And so you might generate 100% of your code, you might generate 0% of your code, but what is the ultimate product? And the speed of development, yes, that is a factor in the user experience. How fast can you respond to a user's problem and build out a solution? Yes, it's a factor. But it's not the only factor. And actually being able to develop the product, that is the metric that matters. And maybe it's not quite as quantitative as percentage of code generated by AI, but it's actually a factor that matters. So that is why this metric is not necessarily the greatest metric to think about. Now, the Dora report of 2025 said something really, or came to an interesting conclusion. AI tends to amplify an organization's existing strengths and weaknesses. Yeah, you know where this is going. If you have strong tests, clear ownership, discipline review, good observability, and fast rollback, AI can make you better. If you have weak engineering hygiene, AI can make you worse faster, hit you in the heart. This is so true, absolutely. And you can actually use agents to improve in a lot of these areas. Now, like clear ownership, maybe not so much. That's a skill that you need to develop in yourself. Discipline to review, I think that agents are actually going to make this a lot easier going forward. Good observability, you can say, hey, agent, help me make good observability. In fact, fast rollback. So you can use agents to help you in a lot of these things. But some of these things are just skills that you've got to develop yourself. And being able to kind of intentionally handle what friction used to give us is going to be a really valuable thing for people going forward. So take a look at this article by Matt, really, really awesome article. I think the basic takeaway is that, yes, the friction was really valuable. We just need to find a way to have our cake and eat it too. Have our judgment and also move fast, as fast as we reasonably can. Speed by itself is not valuable. Speed in the right direction, that's what's valuable. So if you can have both, have both. But if you can only have one, go in the right direction. Another thing that I want to mention is agentic fluency. I think that it's important in 2026 and beyond that you're really good at the tools that you're using. We have workflows, but it's really easy for us to just kind of naturally fall into always looking at a different workflow and iterating constantly on our workflows. We had this same problem five years ago where everybody would ask me my editor font and theme. And it's like, guys, why does it matter? Who cares what that is? I don't know. And so we have the same problem. What agents are you using? What model are you using? Are you using the brow flute? Are you using skills? No I'm not because the thing is that these agents are constantly changing. Every two months you've got some new workflow that it kind of consumes the previous workflows. Are you doing some sort of agent orchestration thing? Well that's like built in to most agent platforms now. And so you don't really, I personally don't spend a lot of time focusing in on those workflows and instead I spend my time just getting really good at my chosen agent. My personal chosen agent is cursor. This is not an ad. They do give me free tokens but so do other agents and I prefer cursor. So I would recommend that you not chase every new free feature every week and instead focus on leverage. Don't make it your identity. So a couple of things I want you to try is whether it's in side projects or in your work I want you to build out your testing and your CI so that you and agents can iterate inside of this system. I want you to think high level about the system. When a new request comes in I want you to think does this require a change in the system? Do I need new primitives? Do I need to expand the system? Those are the things that you should be thinking about before you even write the first prompt. And maybe you don't know and that's okay too. You can ask the agent like here's one session let's talk about this and that like whole conversation becomes part of the prompt. It's a valuable workflow that I have found to be valuable as of today and who knows if that will carry on as far as a workflow but the point is that you need to be thinking about that system. And then building out that agentic loop so that the agent can continue to scale and you can have agents working on this work inside of that system without like kind of stretching out beyond. The last thing I want to talk about it's kind of like the overarching thing of all of this is the role of ownership and accountability. Somebody's got to be responsible for this thing. Somebody has to answer when they say why did this go bad? Why did this go poorly? And that person needs to be you and you need to not say oh well the agent told me this or like try to don't try to pass the buck. Be responsible. Here's why this matters. It's not because now we have somebody to blame when something goes wrong. In fact, your entire organization should be responsible and accountable for all the things that you're doing. The reason that ownership and accountability really matters is because it means that you are going to think you're going to be like you're going to take some judgment. And so that's how we can have our cake and eat it too as far as this friction stuff. We can get rid of the friction but have the good judgment because you know that you're accountable. So when you say yeah I'm going to take over this slice of this feature, I'm going to do the whole thing, this is my responsibility, I'm going to make this happen and if it fails it's on me. That is going to make you really think about okay so what are the downstream effects of this decision? If we add this migration, what can happen if people are improperly migrated or like what does it mean to our customer success team to have some sort of required migration for this? Like you're just thinking about the entire thing, the entire system and the reason that you care so much is because you're accountable, you are irresponsible and that is actually a skill that you can develop. You can actually practice this and this is what makes you slow down. Like everybody on the podcast on Become an Epic Product Engineer, they've been talking about how important it is that you slow down and restraint is a side effect of ownership. And so if you develop this ownership persona or this idea then you're going to be like no I've got to be in that room because I own this feature, I need to understand what the problem is so that when we build it out that it actually solves the problem. I'm not content with just taking my tickets and turning it into implementation. That's not what we do here anymore. Your job is to own it and when it goes bad you own that and you say I'm going to make it right, I'm going to fix this and that is going to make you so much more valuable. It's going to set you apart because so many people don't care about ownership. So you own it. This is yours. You take it. I have an experience years ago and actually this happened many times as maintaining open source. Somebody brought in a pull request for a feature that made sense but I didn't need that feature. And so instead of just saying okay yeah sure I'll merge it, I decided hold on a second. I don't want to have to maintain this. I'm not the right person to maintain this because I don't have the use case and I'm not going to dive in to figure out the use case and be responsible for this so I'm not going to merge it unless the person who is contributing, unless you will commit to helping me maintain this in the long term. And now I'm shifting the ownership onto them but the point is that we need to have ownership. Somebody's got to own this for this to be a long term successful thing. You got to think okay in six months, in two years, what is my life going to be like because we have this feature built into this library. And by thinking about that, the judgment is better. We ended up merging it and they actually took over the project and I was able to move on. So it worked out great but ownership is what made that happen. So a couple of things that you can practice and develop until there are habits. I want you to maintain tests before you ship and merge. Like this is the maintenance test. Will I have to answer for this in six months? If not, then you don't have ownership and you need to either take ownership or just make sure that somebody has ownership so that the project is a success. So that somebody is thinking about that. So that's called a maintenance test. You need to think about that. I want you to think about what does success mean before you even prompt anything. So define what does worked mean. How do you know that this thing actually works? I want you to try and own the entire feature. Not just okay we implemented the feature but what are the downstream effects of that feature now existing in the product. Okay, what docs need to be updated? Who on the customer success team needs to be notified? Whatever. Own the entire thing and actually go upstream as well. Go to the decision meetings and ask before the spec even exists what are the problems that we're trying to solve here and how can we make that work within our system or how do we need to expand our system to fit this? Whatever the case, you're going to be thinking about that. That's your job. I want you to close the loop. After we ship, I want you to talk to support and I want you to go check out the metrics. Don't just throw it over the wall. It's your job to make sure that this is a successful shipped feature and that it continues to iterate with user feedback. And I want you to use retrospective language. What would I do differently based on this experience? Not well the ticket said I should do this or the agent said it did it this way or whatever. You think about how you would approach this problem differently in the future if it goes poorly and if it goes well too. Use that sort of language focused on yourself and how you would operate differently. You've got team members probably, most of you do. Of course they have some responsibility here too but you can only control yourself. Take ownership. You can do this. This is a muscle that you can work on. You can train. You can get better. As we talk about all these skills that you can develop and become a much more valuable member of your organization, there are other things to maybe deprioritize. For a long time people would make lead code interview questions as kind of their daily identity. They were just always thinking about how can I do this. I think that understanding systems matters way more than inverting trees or doing binary searches or whatever. That literally is not a hard thing for anybody with an agent to do anymore. You need to understand systems. Don't worry about FOMO tools or workflows or whatever. Just choose a stack, stick with that stack, be happy with it and move on. Don't bury your head in the sand or anything but for the most part you should be able to do this with just one tool. Just focus on that. I don't want you to confuse agent fluency, being fluent with an agent work flow with good judgment. Anybody can just say, "Yeah, take this ticket and go ship it. Take this ticket and go ship it." Agents are going to get better and it's going to be a lot easier for just anybody to do that. I've got homework for you. I've actually got three, maybe four bits of homework. First, I want you to wire one feedback source from somewhere that you'll see daily. Whether that's coming from Discord or Instagram or wherever and put that into a place that you and other engineers will see all the time. This will help you develop a good intuition for the problems that your users are experiencing with your existing solution and potential opportunities as well. Before your next agent task, I want you to write three bullet points. One, what is the problem that we're actually solving for a user? What is the success criteria? How will we know that this is successful and who could get hurt? Not physically, hopefully, but the downstream effects of this change. Your third piece of homework is whether this is in an open source project or at work, you're maintaining something that people are contributing to. I want you to apply the maintenance test to one thing that you're talking about merging or shipping. What are the downstream effects in six months, in a year? If we merge this, how is this going to affect my life in that time? Your last bit of homework is a little self-serving. I want you to like and subscribe and comment below what you want to learn about more. I'm just getting started with really caring about YouTube and actually putting things together. I welcome your feedback. Please provide that feedback and ideas of other things that you want to learn about. I hope that you've enjoyed this time to get better with Kent and I hope that we all can get better together. Thank you for spending some time getting better with me.