AI Engineer World's Fair 2026

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

Read the talk

The engineer of the future is the person who is able to choose what is worth doing

As agents take on more software work, engineering shifts toward choosing worthwhile problems, designing verification, and remaining answerable for what ships.

From a talk by Addy Osmani

What is worth doing, and who stands behind it?

Should this work ship? Should it be blocked, redirected, or accepted with a known risk? Those production decisions remain consequential even when an agent does most of the implementation. Addy Osmani opens with the human responsibility behind them: choosing what is worth doing, then owning the evidence, the understanding, and the verdict around automated work.

Black slide with white, yellow, and purple text describing the engineer’s role in increasingly automated work, with the speaker inset at left.Open full source frame
Engineers choose what is worth doing and own the evidence, understanding, and verdict.

Quality produces evidence; a verdict assigns responsibility. Tests and other checks help establish whether work meets a standard. Someone still has to decide what that evidence warrants and remain answerable for the decision. Keeping a human in the loop means preserving that responsibility, not simply arranging for a person to see the output.

This changes how engineering roles fit together. Osmani credits Boris Cherny with useful language for craft boundaries that are becoming blurry: ownership increasingly follows the work rather than a job title. Prototype, build, sweep, grow, and maintain are distinct engineering modes, and agents can help with all of them. The scarce judgment is deciding which mode the product needs, what quality bar applies, and who owns the result.

0:400:54
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:40 · section reference included

From a model to a software factory

A model alone is not the whole coding system. Harness engineering surrounds it with context, tools, a filesystem, and Git—the environment that makes its capabilities usable for delegated work. Loop engineering adds repeated prompting, checking, remembering, and decisions about what happens next. Instead of asking for one answer, the engineer designs a process that can continue working. That is where agents begin to behave like infrastructure.

Put those pieces together and the result is a software factory, a concept Osmani connects to Dex’s earlier talk. Agents operate inside the execution loop and produce evidence. Humans make the production decisions around it. The purpose is to move human judgment to the checkpoints where it has the greatest effect, rather than requiring continuous intervention in every execution step.

2:332:44
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:33 · section reference included

Clean code helps the next agent

As AI-assisted code becomes an ordinary part of repositories, answerability becomes an engineering requirement. Osmani cites Sonar’s 2026 State of Code Developer Survey to illustrate that shift. Maintainability matters for the same reason it always has—someone must be able to understand the code—but the next reader may now be an agent as well as a teammate.

The Sonar study Does Code Cleanliness Affect Coding Agents? separates task success from the cost of reaching it. In the controlled comparison using Claude Code with Sonnet 4.6, clean repositories had roughly the same task pass rates as messy repositories, with 7–8% fewer tokens and about 34% fewer file revisits. These are results from the studied repository pairs and tasks, with variation across tasks, rather than a guarantee for every agent or codebase. The useful distinction is that an agent can reach a similar result while spending less effort reading and revisiting the system.

Slide reading “Clean code is cheaper for agents to read,” with a yellow line stating “7–8% fewer tokens. 34% fewer file revisits. Same pass rate.”Open full source frame
Clean code is cheaper for agents to read: 7–8% fewer tokens, 34% fewer file revisits, same pass rate.
3:353:47
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:35 · section reference included

Distrust without bandwidth

Making generation cheaper does not automatically make review cheaper. Engineers can be skeptical of AI-generated code and still lack the capacity to check everything it produces. In Sonar’s survey, 96% of respondents did not fully trust the functional correctness of AI-generated code, while 48% completely agreed that they always check AI-assisted code before committing. These are reported attitudes and practices, not observed defect rates; the second figure does not mean everyone else never checks. Osmani’s concern is the gap between distrust and the bandwidth to act on it.

Verification must become cheaper, clearer, and harder to skip. At organizational scale, adoption can move faster than governance, leaving review and validation as bottlenecks. A useful record of delegated work must let someone answer several connected questions: Did a model touch this file? What constraints guided it? What evidence did it produce? What risk was accepted, and who owns the result?

Osmani briefly invokes Homer Simpson’s computer automation as the comic version of a future with little human involvement. The serious problem is that an agent can produce more change than a person can comprehend. When generation scales faster than comprehension, judgment backed by evidence becomes scarce.

4:214:36
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:21 · section reference included

Alpha, decay, and taste that can be taught

Where does human judgment continue to create value? Osmani introduces two terms for thinking about that question. Alpha is the gap between what a person can do today and what current models can do. Decay is the clock on that gap. A capability can be valuable without remaining a durable advantage as the model frontier advances.

Taste is one proposed answer. Osmani attributes to Paul Graham the observation that when making things becomes easier, choosing what to make becomes more important. But taste can also become a vague name for work that has not yet been explained. He favors a definition he attributes to Mitchell Hashimoto: the ability to make high-quality qualitative judgments where an objective metric does not yet exist. That places taste before a benchmark can settle the question, or before the market has fully expressed a preference.

Model-generated interfaces make this concrete. Looking at the UX an agent creates, a person may recognize that an experience works—or that something is wrong—before having a metric for the difference. If generating ten options is cheap, the valuable contribution is choosing which option deserves to exist. To improve future decisions, that judgment must become critique and examples that a team or system can learn from. Taste remains useful, but treating it as an eternal moat misses how learning works.

The decay test applies across the capabilities engineers have relied on:

CapabilityWhat changes its advantage
SpeedModels absorb more execution work.
RecallHarnesses provide memory.
VerificationEvals, static checks, and model critique move into the harness.
TasteModels learn from examples and preferences.

Osmani expects taste to decay more slowly, but even judgment is a slope rather than an impermeable boundary. The career strategy is to keep moving to the next level of responsibility instead of defending one capability forever.

That shifts the question from what an agent cannot do to what a human must be answerable for. More people can now make computers do useful things, expanding access to building software. Engineering still requires reasoning about systems, understanding constraints, defending trade-offs, managing risk, and being reachable when something breaks. Those responsibilities extend beyond producing an implementation.

6:066:22
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:06 · section reference included

A passing build can conceal lost understanding

Cognitive debt is the erosion of understanding and memory as more problem solving is deferred to AI. In a repository, it appears as a gap between how much code exists and how much any human on the team understands. A build can pass its tests and a PR can be ready to merge while the team loses its ability to explain the system it is shipping. Passing checks and retaining comprehension are different properties.

Delegation depth makes this harder. A thirty-second agent run feels like an interaction; a task that runs for an hour or a day is a workstream. An agent can remain inside the system long enough for the human to lose the thread, especially when several long tasks run in parallel. Review at that scale cannot be a glance at the final result. It has to become a control system.

Slide with three horizontal bars labeled greater than 30 minutes, one hour, and eight hours of human-equivalent tasks, showing 80.6%, 70.2%, and 25.6%, plus a greater-than-60-hour callout.Open full source frame
Delegation depth is now real: long, parallel tasks demand answerable delegation.
9:489:59
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:48 · section reference included

Borrowed confidence and the orchestration tax

Cognitive surrender goes further than losing familiarity with code: it means accepting an AI answer before forming an independent judgment. Delegation asks the agent to do the work and return enough evidence for a person to judge it. Surrender substitutes the agent’s answer for that judgment.

Osmani cites Wharton research as a warning about borrowed confidence. In the cited reasoning experiments, participants accepted the incorrect AI output in 73.2% of trials where they consulted AI and it supplied a wrong answer. The research also reports increased confidence following errors. These were reasoning experiments, not software-review measurements, but they illustrate why confidence in an answer cannot substitute for evidence about its correctness.

A third failure mode is orchestration tax. Running hundreds or thousands of agents does not create more human attention. Every additional loop introduces decisions about routing, merging, verification, and integration. Human cognitive bandwidth does not parallelize with the agent count.

The corrective is not necessarily to run fewer agents. It is to design attention deliberately: where a person enters the process, what information they acquire there, and what they can reuse. Parallel execution only helps if the resulting decisions remain manageable.

11:0411:22
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:04 · section reference included

Accountability makes delegation scalable

Accountability can sound like an extra burden, but it is what allows the larger system to scale. As agents do more work, faster and in parallel, someone must explain the intent, inspect the evidence, accept the risk, and improve the system when a decision turns out to be wrong.

Osmani frames the career distinction as the half-life of an edge versus the half-life of a signature. An advantage in speed, recall, verification, or taste might disappear with a model release; that is a strategic metaphor, not a measured duration. A signature is the person, team, or institution standing behind the shipped work. Credibility built through that responsibility can last longer than any particular capability advantage. Skills create leverage; accountability turns it into trust.

Agents can choose, route, merge, escalate, and operate within policy. In many systems, they should. But authority to execute does not transfer responsibility for consequences. An agent can follow a runbook without becoming the party that bears the cost when it fails. The questions remain: Who understood the policy? Who accepted the risk? Who owns the blast radius?

High agency means actively owning outcomes: knowing when to delegate, inspect, stop, and put your name on the result. Personally doing everything does not scale. Osmani’s agency ladder moves from flagging a problem through executing, diagnosing, proposing, recommending, and resolving it. The final step is discernment—deciding whether the problem deserves investment at all. When agents make more paths possible, choosing not to pursue one can be the responsible decision.

12:3812:49
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:38 · section reference included

The handoff is evidence and responsibility

The operating model separates an inner execution loop from an outer engineering loop:

LoopWorkRole
InnerInvestigate, implement, test, reportExercise capability.
OuterDecide, verify, approve, ownExercise agency.

Agents can run much more of the inner loop. The outer loop determines which work deserves attention and what can responsibly reach production.

The agent’s handoff is an evidence package appropriate to the task: diffs, tests, logs, rationale, traces, trajectories, or screenshots. The engineer then decides whether the work was worth doing, whether the evidence is sufficient, and whether to approve or redirect it. Whoever approves the result must own what reaches production. This boundary applies whether a team uses a few agents or thousands: seeing AI output is not the same as accepting responsibility on the basis of evidence.

Osmani makes the release rule explicit: “Explain it or don't ship it.” This does not require a human to type every line or even read every line. It requires someone to understand the work well enough to defend it.

Ownership files in large codebases provide a familiar analogy. Particular directories or architectural areas have people who are on the hook for them. Agent-written changes still need that relationship between a system and its accountable owners. Before release, those owners must be able to explain the changes, identify the supporting evidence, and understand the risks they are accepting.

15:0715:21
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:07 · section reference included

Cheaper software expands the work of engineering

Automation raises the floor, and engineering moves up a level. The work increasingly includes loop design, evidence design, and brownfield stewardship—caring for existing systems while agents change them. Fewer keystrokes leave more software surface area needing taste, verification, ownership, and care.

Osmani closes with an optimistic historical analogy. Higher-level languages, frameworks, cloud, and low-code tools made software easier to create. Lower costs brought previously infeasible ideas within reach, revealing latent demand. He expects agents to extend that pattern: more software becomes possible, and the bottleneck moves from whether it can be built to whether it should exist and whether someone can answer for it. That demand expansion is his forecast, with engineering responsibility at its center.

Purple-and-black closing slide stating that easier software writing led to exponentially more software, with a yellow sentence about making agent work legible, verifiable, and worth shipping.Open full source frame
Easier software creation leads to more software; engineers make agent work legible, verifiable, and worth shipping.

Build the factories, keep the lights on, and own the verdict.

16:5217:07
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

16:52 · section reference included

Resources

From the talk

Transcript download
Read the transcript and explore slides

Loading transcript and slides…