"The engineer of the future is the person who is able to choose what is worth doing." — Addy Osmani

Howdy, folks. So, good afternoon—or good whatever time it is when you're watching this on YouTube. I'm really excited to be here, and today I want to talk to you about, really, what it takes to keep the human in the loop where engineering is concerned.

I really want to start with the human side before we talk about the architecture here. I think that the engineer of the future is going to be really defined by the person who is able to choose what is worth doing.

They're going to own the evidence, they're going to own the understanding, as well as the verdict around increasingly automated work that's being done by agents. Now, when I use the term "verdict," I don't mean that we're suddenly all going to be Judge Judy.

We're not. But what I mean, really, is something just a little bit different. I mean we're going to be accountable for the production decisions. Does something shift? Do we block it? Do we redirect it or accept the risk?

Quality is something that we all talk about a lot, but quality produces evidence. A verdict assigns responsibility. And answerability is really what lets us stand behind a verdict. And this, of course, is not the only way that our industry is starting to think about our roles evolving.

Boris Cherny recently put some useful language around what many teams are starting to feel: the old craft boundaries are getting blurry, and roles are rebundling around the work itself. And the important question here becomes a lot less about "what is your title" and more "what part of the system can you own."

Now, I like this taxonomy quite a lot. It's optimistic without being overly vague. So things like prototype, build, sweep, grow, and maintain, and these are real engineering modes. Agents are going to help with all of them, but the scarce thing is not merely doing the task.

It's going to be knowing which mode your product needs, and what quality bar applies, and who owns the result at the end of the day. Now, we've been talking about harnesses and loop engineering and software factories over the last couple of days.

We can talk why this shift is happening. We've moved past the model as the whole story,right? With harness engineering, the coding agent is the model plus the harness around it,right? Your context, your tools, your file system, Git. And the harness is what turns intelligence into something that you can delegate to.

The next move was loop engineering, where we weren't just prompting one run anymore; we were designing systems that kept prompting, checking, and remembering, and deciding what happened next. And that's really when agents started to feel like infrastructure. And once you start putting all of those things together, you get that software factory.

Dex covered this well in his talk, but you have agents that are running inside that inner loop, and evidence that comes out. Humans still end up making the production decisions in this loop. And the wind really isn't moving us from it.

The wind is moving human judgment to the highest leverage checkpoint, I think. And this is why it starts to matter now. AI-generated and AI-assisted code is becoming normal code for a lot of us. One of Sonar's 2026 surveys said that AI-assisted code is no longer marginal.

It's increasingly having a large role in our codebases. And once that happens, answerability stops being this philosophical word. It becomes an engineering requirement. And there's a quality point here as well,right? Like, we used to care about clean code, code that people could read.

But cleaner code is actually not just going to help the next human and the next person on your teams. It actually helps the next agent. Another one of Sonar's research studies found that clean and messy repos had roughly the same pass rates, but clean code actually used fewer tokens and caused fewer revisits.

So there's a lot of benefit to maintainability that can fuel efficiency for your factories. Now, making generation cheaper does not automatically make review cheaper,right? I think a lot of us are facing this moment. And we know that engineers are not naive.

The Sonar numbers say that almost everybody is skeptical of AI code. Now, I love working in my software factory. I love building my engineering loops. But the problem is still capacity. If 96% of people don't fully trust that code, but only about half always verify before committing, we have this danger that we've got distrust without bandwidth.

And so safety comes from making verification cheaper, clearer, and harder for people to skip. And if you zoom out from the individual reviewer to the organization, review and validation start becoming a bottleneck when governance isn't able to catch up, and adoption is already moving way faster than any company can go and set their policies.

And this means that we have some hard questions we have to deal with. Like, did a model actually touch this file? And the hard questions are also, like, what constraints guided that work? What evidence was produced? What risk was accepted?

And who owned the result? Now, the agent can ship more than any of us can review,right? So what are we still good for? That's a question that's on a lot of our minds,right? And, you know, if Homer Simpson's experience automating computers can teach us anything, maybe this is our future.

I don't think it is. But it's one direction things could take. Now, let's try that again. If changes where humans enter the loop, if generation scales faster than comprehension, the scarce resource becomes judgment that's backed by evidence. So the question is no longer "how much can the agent do," but "where does human judgment still create leverage?"

Now, I want to talk to you about two terms that I'm going to use for the career part of this talk: Alpha and Decay. Alpha is the gap between what you can do today and what current models can do.

That gap is a very real thing. And Decay is the clock on that gap. If the thing that makes you special is a capability, the frontier is eventually going to come for it,right? And there's a whole conversation around this.

This is one of the reasons why taste keeps coming up. Paul Graham had a point here that I think is veryright. When anyone can make anything, choosing what to make becomes very important. And I buy that. But I also think that we have to be very careful because taste can become a magic word for whatever part of the work we don't want to explain just yet.

Mitchell Hashimoto gave us a more useful version of this definition. Taste is the ability to make high-quality, qualitative judgments where no objective metric exists yet. That matters because it puts taste before the benchmark and before the market has fully voted.

When you try out a model and you see the kind of UX and the kind of experiences that it builds, you can often tell when you think it has taste or lacks taste, or when there's a gap there that humans can fill.

Now, this is also only useful if we can turn some of this concept around taste into critique, examples, and better judgment over time. So, yes, taste matters when production gets cheaper. And if anyone can generate 10 options, the scarce skill is really knowing which option deserves to exist.

But taste is not some eternal moat. It's Alpha as well. Now, the people with taste are still going to matter. I personally think they're still going to matter for a long time. But the best version of that skill is not mystique.

It's making better calls and leaving behind examples that your team and the system can learn from. Now, let's apply the Decay test. While we used to have speed, that decayed. We used to have recall. You know, harnesses have memory.

Verification is moving into harnesses, evals, static checks, and model critique. Taste, I continue to think this is going to decay much more slowly, but it still resets as models learn from examples and preferences. Even judgment, in some ways, is a slope rather than a wall.

So the strategy is not to cling to any one capability. It's for us to keep moving our edges up a level. So this is one of the reasons why "what can the agent do" is not the best strategic question anymore.

The list of things that agents can't do just keeps shrinking. The better question for us is really "what can only a human be answerable for?" Not because, you know, any of us are magical in any way, but because some decisions actually require ownership.

They require context, risk acceptance, and responsibility after that work ships. This is why the word "engineer" has to get just a little bit stricter. More people than ever can now make computers do things. And I think that's truly awesome.

The total addressable market for builders has never been larger, and that's so cool. But it's a huge expansion of the leverage. An engineer is not merely somebody who can code, you know, and get things to exist. An engineer can reason about systems.

They think about constraints, you defend trade-offs, you can manage risk. And you're the person that can be reached out to when things start to break. So what are things that engineers should avoid if we want to stay effective and accountable in this moment?

Well, the first thing to avoid, really, is cognitive debt. Now, cognitive debt is the erosion of your understanding and memory around how to solve problems. I think a lot of us start to feel this the more that we're using agents every single day.

I know that I feel this a lot. And it's because we're deferring more and more to AI to solve our problems. For code, it's the gap between how much code exists in your repo and how much any human on your team genuinely understands.

And this is why things like delegation depth end up mattering. You can have a build that passes, you know, your tests, a PR that you can merge, but your team can still end up losing its ability to actually explain the system that they are shipping to production.

Now, a very real pressure is also how much we delegate. So agents can now stay inside the system long enough for the human to lose the thread. So a 30-second run,right, can feel like an interaction. But an hour or a day-scale task, so something of long horizon, that's a workstream.

And when tasks can end up, you know, lasting that long, especially when you begin running many of them in parallel, review can't just be a glance at the end. It has to become a whole control system. The second thing to avoid is cognitive surrender.

Now, this is when you blindly accept AI's responses. Like, delegation is important because delegation says, "Do the work, then show me enough evidence that I can judge it." I still make a judgment in that situation. Surrender is really saying, "Hey, your answer is now my answer before I have formed any opinions myself."

Now, Wharton did a study that kind of offers us a warning light here. When AI was wrong, 73% of people still thought that, you know, they picked the wrong answer and they felt more sure. So the failure mode is not using AI, but it's borrowed confidence.

The third thing to avoid is orchestration tax. Now, if you've been in the Bay Area, you will see people who, for better or worse, are still walking around with their laptops open or talking to you about cloud agents.

And we're increasingly trying to run more and more and more in parallel, or telling each other that we're shipping with hundreds of agents or thousands of agents. More AI agents running does not mean that there is more of you available.

Your cognitive bandwidth does not parallelize. So every loop that you create ends up causing more decisions to route, merge, verify, and integrate. And the fix is not necessarily fewer agents, but it's about assigning your attention like a system.

Like, where you enter, what you acquire, what you reuse. You just want to be very intentional about it. Now, accountability can be a scary word for a lot of people. And I wouldn't be surprised if it made you want to go hide in the bushes and just tell your agent to deal with it.

But accountability is not what remains after agents get good. It's what lets the rest of the whole system scale. If agents can do more work, if they can do it faster in parallel, better than what many of us could do, the scarce thing becomes the ability to explain intent, to inspect evidence, to accept risk, and improve the system when the decision was wrong.

Now, here is the career math. The half-life of an edge might be one model release. Speed, recall, verification, even taste all move as the frontier moves. But the half-life of a signature, your credibility, your expertise, is much longer.

And by signature, I really mean the name on the work. The person, the team, the institution, whoever stands behind what's actually shipped. So skills can earn leverage. Accountability can turn leverage into trust. And this is one of the lines that I want to draw pretty clearly.

Agents can choose. They can route. They can merge. They can escalate. They can operate inside policy. And in many systems, you know, they can. They should. But execution and responsibility are very different things. The agent can follow your runbook, but it can't inherit the consequences.

When something fails, the question is, who understood the policy? Who accepted the risk? And who owns the blast radius? High agency is something that a lot of us talk about these days as being, like, this thing that we're looking for when we're hiring.

High agency is actively taking ownership of your outcomes. So knowing when to delegate, when to inspect, when to stop, and when to put your name on the results. High agency in this world is not "I personally do everything."

You know, that version doesn't really scale. It's not just hustle theater. But it's ownership with judgment attached. This agency ladder tries to make that a little bit more concrete. At the bottom, you've got someone that flags a problem and leaves it for the system.

Higher up, they execute, diagnose, propose, recommend, and resolve. And the rare top movement is discernment. You know, maybe you find a problem and you decide whether or not it's worth investing in. Maybe it's not. And maybe you move on.

But when agents make more paths possible, agency is not chasing every single path. It's really just deciding which paths deserve your ownership and attention. So translate that into an operating model. Agents can run much more of the inner execution loop.

They can investigate, implement, test, and report. I think that there's leverage in that. But that outer loop is still engineering. So deciding, verifying, approving, owning. That inner loop is capability. The outer loop is agency. And this is a boundary that I really care about.

Your agent returns evidence. It returns diffs, tests, logs, rationale, traces, trajectories, screenshots, whatever the work itself requires. But then the engineering really begins. We decide whether the work was worth doing. We verify whether the evidence is enough. And we approve or redirect or own what reaches production.

It doesn't matter if you're someone that's just working with a small number of agents or whether you're working with thousands of agents. I still very much think that these ideas apply. So the boundary is not "human looks at AI output."

The boundary is evidence and responsibility. So here's an operational rule. Explain it or don't ship it. And it's not because humans have to type every line or read every line, but because someone has to understand the work well enough to defend it.

If you've ever worked in a large code base or an enterprise code base, some code bases have this concept of an owner's file or certain subdirectories where there are people who are on the hook for that part of the system.

You can think about this in a very similar way. Who is accountable for that part of your architecture in your code base? Your model might write the code, and the question is really still whether you can explain those changes that the agent is shipping.

Whether you've got the evidence, whether you understand the risks. Now, this is one of the things I want you to remember near the end. Automation moves the floor for all of us. Engineering continues to move up a level.

And our new work might be loop design, evidence design, and brownfield stewardship. But fewer keystrokes doesn't mean less engineering over the next few years. It means that there is more surface area that needs taste, verification, ownership, and ultimately care.

I don't think I've ever been more excited about the future of this field. Every time that we have made it easier to write software, we've predicted that the world would need less of it. And in fact, the opposite happened.

Higher-level languages happened, frameworks, cloud, low-code. The pattern always went the other way. And when you lower the cost, latent demand ends up appearing. Those ideas that people didn't think were feasible to build and get out there are suddenly unlocked.

And agents are going to do the same thing for a lot of people. It's not going to remove engineering work. It's going to move the bottleneck from "can we build this" to "should this exist" and "can we answer for it."

So build the factories, keep the lights on, own the verdict. I hope this was useful. Thank you.