Closing keynote by Addy Osmani on the evolving role of software engineers in the age of AI agents. He argues that as coding becomes automated, an engineer's value shifts from code production to judgment, accountability, and system ownership. Topics covered include rebundling engineering roles, "harnesses" and loop engineering, reviewing AI-assisted code and organizational bottlenecks, human judgment and "taste" as leverage, risks such as cognitive debt and surrender, orchestration tax, accountability for scaling, credibility vs. capability in career development, high agency, and boundaries between agents and humans. # Channel Identity Observations: Addy Osmani Talk Video ## Explicit Self-Description Evidence - The speaker identifies himself in the title as **Addy Osmani, Anthropic**, positioning him as affiliated with an AI company. - No explicit channel-level self-description (e.g., "welcome to my channel") appears in the transcript; the talk is delivered as a **conference-style presentation**: "I'm really excited to be here." - The speaker addresses YouTube viewers directly, indicating the video is a recording distributed online: > "good afternoon or good whatever time it is when you're watching this on YouTube." ## Intended Audience - **Software engineers and engineering leaders** grappling with AI-assisted development. Evidence: repeated second-person address to builders — "what are we still good for?", "what are things that engineers should avoid", "if you've ever worked in a large code base or an enterprise code base." - Audience presumed familiar with **modern AI coding-agent terminology**: "We've been talking about harnesses and loop engineering and software factories over the last couple of days" — indicating a conference audience already deep in this discourse. - Audience includes people **already using AI agents daily**: "I think a lot of us start to feel this the more that we're using agents every single day." ## Claimed / Demonstrated Scope - **Topic scope**: The evolving role of engineers amid AI agents — accountability, judgment, verification, and career strategy ("alpha and decay," "the half-life of a signature"). - **Talk structure the channel demonstrates**: conceptual framing + practical guidance ("two terms... alpha and decay"; "three things to avoid: cognitive debt, cognitive surrender, orchestration tax"; "agency ladder"). - **Speaker's own positioning** (first-person claims, not channel claims): - "I love working in my software factory. I love building my engineering loops." - "I don't think I've ever been more excited about the future of this field." - **Referenced external sources** cited within the talk: Boris Cherney's role taxonomy, Paul Graham on taste, Mitchell Hashimoto on taste, Sonar 2026 survey data, a Wharton study, and "Dex covered this well in his talk" — indicating the channel/video's scope includes **synthesizing industry research and practitioner discourse**, not just opinion. ## Observable Presentation Patterns - **Tone**: Optimistic, rhetorically polished, occasionally humorous ("we're not suddenly all going to be Judge Judy"; a Homer Simpson reference about automation). - **Format**: Single-speaker keynote/talk format with takeaway aphorisms ("Explain it or don't ship it"; "build the factories, keep the lights on, own the verdict"). - **No metadata was supplied** beyond the title, so no further identity context (e.g., conference name, channel description) is available. ## Claim vs. Demonstration Distinction - **Creator claim**: Title asserts a thesis quote attributed to the speaker. - **Demonstrated**: The transcript confirms the speaker articulates this thesis: "the engineer of the future is going to be really defined by the person who is able to choose what is worth doing." - **Not evidenced**: Nothing in the material states the channel's broader content strategy, upload cadence, or whether this is the speaker's own channel versus a re-hosted conference recording. # Delivery Observation: Addy Osmani — "The Engineer of the Future" ## Overall Tone - **Conversational and warm**, opening casually: > "Howdy, folks. So, good afternoon or good whatever time it is when you're watching this on YouTube." - **Optimistic but grounded** — repeatedly balances enthusiasm ("I don't think I've ever been more excited about the future of this field") with sober caveats ("taste can become a magic word"). - Speaks **directly to the audience's anxieties** ("So what are we still good for? I think it's a question that's on a lot of our minds, right?"). ## Signature Teaching Habits ### 1. Defining terms explicitly He repeatedly names concepts and defines them immediately: - > "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." - > "Cognitive debt is the erosion of your understanding and memory around how to solve problems." ### 2. Pre-empting misreadings He clarifies a metaphor before it derails: - > "When I use the term verdict, I don't mean that we're suddenly all going to be Judge Judy." - > "Not because, you know, any of us are are magical in any way, but because some decisions actually require ownership." ### 3. Numbered, named frameworks The talk is structured around labeled lists: - **Three things to avoid:** cognitive debt, cognitive surrender, orchestration tax ("The first thing to avoid…" "The second thing…" "The third thing…"). - **Taxonomies and ladders:** "prototype, build, sweep, grow, and maintain"; "flags a problem… execute, diagnose, propose, recommend, and resolve." ### 4. Aphoristic contrast pairs A consistent rhetorical pattern of X-vs-Y distinctions: - > "Quality produces evidence. A verdict assigns responsibility." - > "That inner loop is capability. The outer loop is agency." - > "Execution and responsibility are very different things." - > "Skills can earn leverage, accountability can turn leverage into trust." ## Recurring Vocabulary and Phrases - **"Own / ownership / answerability"** — the talk's central lexicon: "own the evidence," "own the verdict," "who owns the blast radius," "what can only a human be answerable for." - **"Evidence"** appears throughout ("evidence design," "the agent returns evidence," "judgment that's backed by evidence"). - **"The scarce thing / scarce resource / scarce skill"** — recurring framing device: > "the scarce skill is really knowing which option deserves to exist." - **"Decay test / half-life"** — durability metaphors for skills: > "The half-life of an edge might be one model release." ## Use of Humor and Pop Culture - Light, self-aware asides: the Judge Judy line, the **Homer Simpson** automation reference ("if Homer Simpson's experience automating computers can teach us anything… I don't think it is"), and > "you will see people who for better or worse are still walking around with their laptops open." ## Attribution Habits He **cites sources by name** rather than asserting ideas as his own: - "Boris Cherney recently put some useful language around…" - "Paul Graham had a point here…" - "Mitchell Hashimoto gave us a more useful version of this definition." - References Sonar survey data ("One of Sonar's 2026 survey…") and "a Wharton… study." ## Closural Style - Ends with a **compact three-part imperative slogan**: > "So, build the factories, keep the lights on, own the verdict." - Explicitly flags the takeaway earlier: > "this is one of the things I want you to remember near the end." ## Uncertainty Notes - Filler ("um," "you know," cleared throat) suggests live, semi-improvised delivery rather than a read script. - Pauses like "Um" before definitions suggest on-the-fly structuring; whether the frameworks were pre-prepared is not observable from the transcript alone. # Position Record: "The Engineer of the Future Is the Person Who Chooses What Is Worth Doing" — Addy Osmani (Anthropic) ## Speaker - **Addy Osmani**, identified by video title metadata as affiliated with Anthropic. All positions below are his, expressed in a conference-style talk. ## Core Thesis - The engineer of the future is **defined by the ability to choose what is worth doing** — owning the *evidence*, the *understanding*, and the *verdict* around increasingly agent-driven work. - **Verdict** is clarified as accountability for production decisions: "Does something ship? Do we block it? Do we redirect it or accept the risk?" - Distinction drawn: **"Quality produces evidence. A verdict assigns responsibility. And answerability is really what lets us stand behind a verdict."** ## Borrowed Frameworks and Cited Research ### Boris Cherney's role taxonomy (cited approvingly) - Old craft boundaries are blurring; roles reorganize around the work itself. - Modes: **prototype, build, sweep, grow, maintain** — "real engineering modes." - Osmani's assessment: "optimistic without being overly vague." - Scarce skill is not doing the task but **knowing which mode the product needs, what quality bar applies, and who owns the result**. ### Sonar research (2026 survey and code-quality study) - AI-assisted code "is no longer marginal" — increasingly a large share of codebases; therefore answerability "becomes an engineering requirement." - Clean vs. messy repos: **roughly the same pass rates**, but clean code used fewer tokens and caused fewer revisits. - Nearly everyone is skeptical of AI code (~96% don't fully trust it), yet **only about half always verify before committing** — the danger Osmani names: **"distrust without bandwidth."** - Stated tension: **"making generation cheaper does not automatically make review cheaper."** ### Paul Graham (cited) - "When anyone can make anything, choosing what to make becomes very important." Osmani: "I buy that" — but with a caution: taste "can become a magic word for whatever part of the work we don't want to explain just yet." ### Mitchell Hashimoto (cited) - Taste = "the ability to make high-quality qualitative judgments where no objective metric exists yet." - Osmani values this because it places taste **before the benchmark and before market verdicts**. ### Wharton study (cited) - When AI was wrong, 73% of people still believed they had picked the wrong answer and felt more sure. Osmani's framing: the failure mode is not using AI but **borrowed confidence**. ## Key Concepts Defined by the Speaker ### Alpha and decay - **Alpha**: the gap between what you can do and what current models can do. - **Decay**: "the clock on that gap." If your edge is a capability, "the frontier is eventually going to come for it." - Decay test applied: speed decayed; recall decayed (harnesses have memory); verification is moving into harnesses, evals, static checks, and model critique; **taste decays more slowly but still resets** as models learn from examples and preferences; even judgment is "a slope rather than a wall." - Strategy: don't cling to one capability; "keep moving our edges up a level." ### Three failure modes to avoid 1. **Cognitive debt** — erosion of understanding of the system; the gap between code existing in a repo and how much any human genuinely understands it. Related: **delegation debt** — builds pass and PRs merge while the team loses the ability to explain what it ships. 2. **Cognitive surrender** — accepting AI answers before forming one's own opinion. Contrasted with **delegation**: "Do the work, then show me enough evidence that I can judge it." 3. **Orchestration tax** — running many agents in parallel multiplies decisions to route, merge, verify, integrate; "your cognitive bandwidth does not parallelize." Fix is not necessarily fewer agents but **designing attention like a system**. ### Long-horizon review - 30-second agent runs feel like interactions; hour- or day-scale tasks are **work streams**. At that scale, especially in parallel, "review can't just be a glance at the end. It has to become a whole control system." ### Signature and career math - The **half-life of an edge** may be one model release; the **half-life of a signature** — credibility, the name on the work — is much longer. - "Skills can earn leverage, accountability can turn leverage into trust." - **Execution and responsibility are different**: "The agent can follow your runbook, but it can't inherit the consequences." When something fails: who understood the policy, accepted the risk, owns the blast radius? ### Agency and the agency ladder - High agency = actively taking ownership of outcomes — knowing when to delegate, inspect, stop, and put your name on the result. Explicitly *not* "I personally do everything," which "doesn't scale" and is not "hustle theater." - Ladder (bottom to top): flags a problem → executes → diagnoses → proposes → recommends → resolves → **discernment** (deciding whether a problem is worth investing in at all). - With agents making more paths possible, agency is "deciding which paths deserve your ownership and attention." ### Inner loop / outer loop - **Inner loop** (agents): investigate, implement, test, report — capability. - **Outer loop** (humans): decide, verify, approve, own — agency. - Agents return evidence (diffs, tests, logs, rationale, traces, trajectories, screenshots), "but then the engineering really begins." - Claimed applicability regardless of whether one works with a few agents or thousands. - The boundary "is not human looks at AI output. The boundary is evidence and responsibility." ## Operational and Governance Claims - **"Explain it or don't ship it"** — someone must understand the work well enough to defend it; not that humans must read or type every line. - Analogy to **owners files** in large codebases: someone is on the hook for each part of the system. - Governance gap: review/validation become bottlenecks when adoption outruns policy; hard questions include whether a model touched a file, what constraints guided it, what evidence was produced, what risk was accepted, who owns the result. - Accountability reframed: "Accountability is not what remains after agents get good. It's what lets the rest of the whole system scale." ## On the Future of Engineering Work - "Automation moves the floor for all of us"; engineering "moves up a level" toward **loop design, evidence design, and brownfield stewardship**. - "Fewer keystrokes doesn't mean less engineering... It means that there is more surface area that needs taste, verification, ownership, and ultimately care." - Historical pattern cited: every drop in the cost of writing software (higher-level languages, frameworks, cloud, low code) was predicted to reduce demand for software; the opposite happened — **latent demand appears**. - Agents will "move the bottleneck from can we build this to should this exist and can we answer for it?" - Closing directive: **"Build the factories, keep the lights on, own the verdict."** ## Preserved Qualifications and Tensions - Osmani holds **taste matters** and **taste is not an eternal moat** — "it's alpha as well" — simultaneously; people with taste "are still going to matter... for a long time," but the best version is "not mystique." - Skepticism data (96% distrust) coexists with adoption reality; he does not resolve this beyond proposing cheaper, clearer, harder-to-skip verification. - His enthusiasm is hedged: on agents replacing humans, "I don't think it is. But it's one direction things could take" (referring to a Homer Simpson automation joke). - The rhetorical question "So what are we still good for?" is acknowledged as live ("a question that's on a lot of our minds") rather than dismissed. # Speaker Attribution Record ## Video Metadata - **Video ID:** `01a15ca8-a5b1-72fe-9e63-a3c2ce650e8a` - **Title:** *"The engineer of the future is the person who chooses what is worth doing." — Addy Osmani, Anthropic* ## Speakers | Speaker | Role | Evidence | |---|---|---| | Addy Osmani | **Primary speaker / presenter** (identified via title; introduces himself as "I'm really excited to be here" delivering a talk) | Sole voice throughout the transcript; delivers a conference-style talk addressing an audience ("Howdy, folks... good whatever time it is when you're watching this on YouTube") | - **No co-hosts, guests, interviewers, or narrators** appear in the transcript. - Audience is referenced indirectly ("we've been talking about... over the last couple of days") but does not speak. ## Third-Party Claims & Referenced Sources The speaker attributes claims to the following named sources: - **Boris Cherney** — cited for language around "blurry craft boundaries" and a role taxonomy (prototype, build, sweep, grow, maintain). - **Dex** — referenced as covering "software factory" concepts in a prior talk at the same event. - **Sonar 2026 survey** — claim that AI-assisted code is "no longer marginal" and plays a large role in codebases; also cited for figures: ~96% skeptical of AI code, ~half always verify before committing; a separate Sonar study on clean vs. messy repos (similar pass rates, fewer tokens/revisits for clean code). - **Paul Graham** — cited on the importance of choosing what to make when anyone can make anything. - **Mitchell Hashimoto** — cited for a definition of "taste" (high-quality qualitative judgments absent objective metrics). - **Wharton study** — cited for the statistic that when AI was wrong, 73% of people still felt more confident in the wrong answer. - **Pop-culture reference:** Homer Simpson automating computers (illustrative, not a source). ## Promotional Segments - **None identified.** No product placements, sponsorships, or self-promotion of commercial offerings appear in the transcript. ## Comment Availability - **Not specified** in the source material; no metadata regarding comment availability was provided. ## Uncertainty Notes - Speaker identity is inferred from the **video title** attribution ("Addy Osmani, Anthropic"); the speaker's affiliation with Anthropic is stated only in the title, not in the transcript itself. - The transcript includes one incidental music cue (`[music]`) at the end; no other speakers introduced. \>\> 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 um today I want to talk to you about really uh what it takes to keep the human in the loop where engineering is concerned. I really want to start with a 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 ship? 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 Cherney recently put some useful language around what many teams are starting to feel. The old craft boundaries are getting blurry, and roles are re-bumbling 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. Um 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 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 \[clears throat\] 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, where 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 judgments 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 survey said that AI-assisted code is no longer marginal. It's increasingly having a large role in our code bases. And once that happens, answerability stops being this philosophical world. 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 uh 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? I think it'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 change is 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 very right. 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 where 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. Well, 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 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 leverage. An engineer is not merely somebody who can code, you know, and 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 debt 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 all much 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 long horizon, that's a work stream. 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 um responses. Like, delegation is important cuz 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, um Wharton did a study that kind of offers us a warning light here. When AI was wrong, 73% of people still thought that they they 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 designing your attention like a system. Like where you enter, what you require, 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 and 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 result. 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 owners 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 and 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 where 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. \>\> \[music\]