Minority Report: When Code Became Cheap — Where Do Value, Responsibility, and Expertise Live Now?

The name of the format comes from two stories that have lived in my channel for years. The first is Richard Feynman's appendix to the report of the Challenger commission. His conclusions about how NASA estimated risk were unwelcome in the main text, and he made sure the dissent entered the official report at least as an appendix. The second is the film Minority Report, in which a predictive system looks perfect right up to the moment its predictions start creating what they predict. Both stories are about the same thing: a written position fixed before the system delivers its verdict, and an honest attitude to metrics that know how to become self-fulfilling prophecies.010101In the channel I translated Feynman's story into engineering terms: he took part in writing the incident postmortem, his opinion was unwelcome in the official report, and he got it included as an appendix. The film I reviewed together with Moneyball as two opposite stories about prediction: one about undervalued players, the other about a prophecy that fulfils itself.Knizhny kub · Feynman and the Challenger minority reportKnizhny kub · Moneyball and Minority Report01In the channel I translated Feynman's story into engineering terms: he took part in writing the incident postmortem, his opinion was unwelcome in the official report, and he got it included as an appendix. The film I reviewed together with Moneyball as two opposite stories about prediction: one about undervalued players, the other about a prophecy that fulfils itself.Knizhny kub · Feynman and the Challenger minority reportKnizhny kub · Moneyball and Minority Report

The panel format gives no credit for consensus: after two similar answers the moderator will go looking for the place where speakers act differently. So I am not trying to sound balanced. For every block I have one position, one case from the last six to twelve months, and one condition under which I would change the position. If the condition arrives, it will be visible against this text rather than against my memories of the evening.

Every case here is already published. That is a constraint, but a useful one: it forces me to rely on what can be re-checked and keeps internal figures, which the moderator explicitly asked us not to bring, out of the conversation.

The warm-up asks each speaker to pick one of five places: choosing the task, implementation, review and checks, delivery to production, operations. My answer is the third, and it has not changed since April, when I first showed the map of relocating queues in my State of AI4SDLC talk. AI speeds up writing code before the organisation manages to rebuild the whole flow. The queue does not disappear — it moves to where the change has to be proven: framing, review, tests, integration, and release. A team produces more changes and still does not deliver value faster.020202I reviewed it in the channel when the recording of the Saint HighLoad++ talk came out: three practical shifts — from roles to agents, from a tool zoo to a platform, from usage metrics to outcome metrics. That is where I first spelled out the read → recommend → act trust ladder.Knizhny kub · State of AI4SDLC at HighLoad++02I reviewed it in the channel when the recording of the Saint HighLoad++ talk came out: three practical shifts — from roles to agents, from a tool zoo to a platform, from usage metrics to outcome metrics. That is where I first spelled out the read → recommend → act trust ladder.Knizhny kub · State of AI4SDLC at HighLoad++

An important caveat about the "choosing the task" stage. When the first draft of a solution becomes almost free, part of the bottleneck leaks upstream: organisations that cannot decline tasks and sunset features get more options and not a single refusal. But I would not call that today's main bottleneck. The main one sits lower: a change that has to be verified, accepted, and released, and the queue at that step is visible in every 2026 dataset, from DX telemetry to GitLab surveys.

In the baseline of AI in software development published in August I put it in one sentence: the ability to produce changes has grown faster than the ability to prove them useful and safe. Everything else in this text follows from that.

The map of positions: whom I am ready to argue with

The warm-up exists so the moderator can put speakers on a map and choose whom to set against whom. Let me place myself and name the neighbours in advance. Whoever says "implementation" usually speaks from the practice of an individual engineer: the local speed-up there is genuinely huge, and my argument with them is not about the speed-up but about the unit of measurement — a task or a delivery. Whoever says "choosing the task" speaks from product: there I agree that cheap implementation exposes weak framing, but I will remind them that weak framing now simply produces the wrong code faster — the queue still forms at verification. Whoever says "operations" speaks from SRE, and that is the most interesting argument: incidents really did get more expensive because changes are more numerous and larger, but that is a consequence of a skipped check, not a bottleneck of its own. The only position I am not ready to argue with is "it depends on the company". It is true and useless: a startup and a bank have their queue on different rungs, but it still stands at proof, not at generation.

The block's main question is what the speed-up actually became: shorter task-to-release time, a lower cost per accepted change, better quality, or more validated hypotheses. My position: where the delivery loop was not rebuilt, the speed-up became volume. More code, larger changes, more pull requests — and roughly the same time to the user. Where the loop was rebuilt, conversion exists, but it is measured in accepted work, not in tokens.

Activity is not a result

AI usage, line counts, and pull request counts are activity. The unit of result is a useful change that travelled all the way to verification and acceptance. In my breakdown of the economics of AI in development I proposed the accepted task as the management unit: the numerator holds the model, tools, human verification, rework, and the expected cost of errors; the denominator holds only tasks that passed acceptance. That denominator is inconvenient precisely because generation cannot inflate it.

The past year's data forms one picture. In DX telemetry over four quarters, median throughput grew 37%, from 1.42 to 1.94 pull requests per engineer per week, but the median change grew from 44 to 72 lines, review time got worse, and developers' confidence that a change would not break production fell 6.1% — while code maintainability rose 3.8%. DORA's 2025 report says outright that AI amplifies both the strengths and the weaknesses of the delivery system, and shows a small drop in throughput and a noticeable drop in stability as adoption grows.030303I wrote about the DX report separately: between "I read the change" and "I trust it in production" lie tests, review, architectural context, and accountability. And from Geoffrey Litt of Notion I took the line I like most: you can delegate execution, but not ownership of the system.Knizhny kub · DX Q2 2026: more code, less trustKnizhny kub · Understanding is the new bottleneck03I wrote about the DX report separately: between "I read the change" and "I trust it in production" lie tests, review, architectural context, and accountability. And from Geoffrey Litt of Notion I took the line I like most: you can delegate execution, but not ownership of the system.Knizhny kub · DX Q2 2026: more code, less trustKnizhny kub · Understanding is the new bottleneck

Five addresses the queue moves to

The panel scenario lists five possible addresses: product discovery, code review, testing, release, and operations. In my observation the queue moves to all five, in different shapes. In discovery it looks like a surplus of options: a prototype costs an hour, and the team stops choosing because it can try everything. In review it looks like larger changes and longer waits: the reviewer reads 72 lines instead of 44 and approves without reading more and more often. In testing it looks like green checks that do not cover the new failure class, because the same agent wrote the tests and the code. In release it looks like a cap on parallelism: however many agents work, only as many streams can be merged and rolled out as the team manages to verify. In operations it looks like more expensive incidents, because the change is larger and its author does not remember why it is built that way.

Hence my answer to the moderator's follow-up: if there is more code and the time to the user has not changed, that is not productivity. It is more capacity on one segment at the same cross-section of the whole flow. A system's throughput is set by its narrowest point, and after generation got cheap that point sits at verification. Counting the larger volume at the entrance to the queue as productivity is measuring pressure in the pipe instead of flow at the outlet.

The queue moved into review, tests, and release, and it needs an owner. Not in the sense of a person who clears it, but in the sense of someone accountable for the end-to-end result: from hypothesis to a change the business accepted. In our review of the AI-native SDLC playbook Anton Kosterin and I checked whether it transfers into a regulated company and agreed on two things. First: agent parallelism is capped by review capacity, so start with two or three streams, not twenty. Second: DORA metrics need AI-related rework, review latency, escaped defects, policy exceptions, and incident-to-eval time added next to them.

If shipping features got cheaper, choosing the task and dropping the unnecessary got more expensive. That is not an abstraction. DX estimates that AI users save four to six hours a week, yet the share of time spent on new functionality did not change over the year: the freed hours were swallowed by existing queues. An organisation that cannot sunset features simply fills the product faster with things it will later have to maintain. So in my model the owner of the result is accountable not up to the merge but up to the business result — and has the right to say "we are not doing this task".

Who owns the new bottleneck? Whoever owns verification capacity: usually the platform team together with service owners, not each engineer on their own. The decision that follows, and that I defend in every deck of this year, is to stop scaling tools and start scaling a proven loop: one stream, one queue, a baseline, gates, proof of effect, and only then the next stream. It is slower than handing out seats to everyone, and it is the only way in which the speed-up reaches the business.

Case: what changed before and after

My most concrete published case is a large fintech's platform, which I showed at Saint HighLoad++ in June. Before: every engineer with their own assistant, dozens of connected tools, and accepted suggestions as the metric. After: a set of domain agents on a shared platform with a model gateway and a tool gateway, shared policies, and telemetry. A "ticket → pull request" agent mode on the internal developer platform, a unit-test generator that produces about a tenth of all pull requests, AI review, security agents, and API contract checks — not one universal assistant, but a loop in which every action has an owner and a set of checks. What changed in measurement: instead of accepted suggestions, waiting in review and in the pipeline, rework, time to a safe change, and defects. What did not change: a human still passes the release into production.

What I stopped doing

Over the past six months I consistently removed the share of AI-written code as an indicator from my talks and research. In the April deck on AI-native measurement it was still discussed as "convenient but dangerous"; in the summer versions of State of AI4SDLC for HighLoad++ and IT Picnic its place was taken by waiting in review and in the pipeline, rework, time to a safe change, and defects. In the second episode of 3 AImigo we walked through the same contrast between a small AI-native team and a large organisation: the first has its bottleneck in context, the second in review and testing, and neither in writing code.040404I wrote this post after the HighLoad++ hallway talks: tokens burned per employee are corporate proof of work, not of value. It is popular because it is organisationally cheaper: nobody has to agree on what value means or clean the data.Knizhny kub · Token burn as proof of work04I wrote this post after the HighLoad++ hallway talks: tokens burned per employee are corporate proof of work, not of value. It is popular because it is organisationally cheaper: nobody has to agree on what value means or clean the data.Knizhny kub · Token burn as proof of work

Condition for changing my position: a company shows, on a real task distribution, a simultaneous rise in DORA throughput and stability after adopting agents without rebuilding review, tests, and release. No such data exists yet in DX, in DORA, or in vendor reports.

The block's main question: if an engineer has the right to perform an action, should their agent automatically get the same right. My position is no, and it is not caution but a consequence of how agents work. The rights model for people assumes a subject that acts slowly, sequentially, and predictably: one person, one session, a legible chain of intent. An agent acts fast, in parallel, and probabilistically: ten runs of one task produce ten different trajectories, and some of them will perform an action that a human with the same rights would never have performed.

This is not a theoretical risk. In my breakdown of agent evaluation I showed why one successful run guarantees nothing: reliability is measured over a series of runs and the spread of trajectories, not by one lucky result. Rights granted on the strength of one convincing demo are granted to the best of ten trajectories. The rights model for people never met a subject that opens twenty pull requests in five repositories within a minute and does the wrong thing in three of them — while every single step looks reasonable on its own.

So rights should be granted not to the agent as a whole but to a class of actions in a specific context — under a separate per-task identity. In my breakdown of agent stack configurations I described this as the tuple "harness × model × tools × identity × technically enforced boundaries": the gateway issues the agent a short-lived token on behalf of the task initiator rather than a faceless shared service account, and what gets attacked in such a stack is not the model but the chain of authority. Protection sits on the boundaries of data, identity, and execution — and has to be technical, not merely a prompt.050505In the podcast with Evgeny Kokuykin we agreed that an agent in the SDLC resembles an internal employee or a service account, not an IDE hint. And on the unpleasant corollary: if every dangerous agent action is escalated to a senior for approval, the bottleneck has simply moved to the busiest people.Knizhny kub · Evgeny Kokuykin on AI security05In the podcast with Evgeny Kokuykin we agreed that an agent in the SDLC resembles an internal employee or a service account, not an IDE hint. And on the unpleasant corollary: if every dangerous agent action is escalated to a senior for approval, the bottleneck has simply moved to the busiest people.Knizhny kub · Evgeny Kokuykin on AI security

The ladder above is my working model, not a standard. The three trust levels — read → recommend → act — I first showed in the HighLoad++ talk; the breakdown by action class I added for this panel. Reading context, changing code in a branch, running CI, and opening a pull request the agent does on its own today — provided it has an identity, quotas, telemetry, and a participation marker on the request. Merging and changes to the test environment it recommends: the agent prepares the plan, a dry run, and the rollback, and the owner accepts the risk. Production is read-only: the agent gathers the evidence and the rollback plan, but a human passes the release gate.

Technically the boundary lives on two gateways. The model gateway decides which data goes where: it holds identity, quotas, redaction, and the log. The tool gateway decides who may change what and on whose behalf: it issues a short-lived on-behalf-of token, checks policy before the action, performs a dry run, and can roll back. Between them sits a capability registry with owners, versions, and check sets. Owning these two points is a commitment to operate them, not a line in an architecture diagram, and that is exactly why I do not believe in a boundary that exists only in a system prompt.

At what moment must a human give explicit consent? In my model, at every rung where an action changes state that cannot be rolled back cheaply, or where the semantics are domain-specific: money, access, data, SLOs. That matches how the Anthropic playbook frames the release boundary: autonomy ends where the risk was not delegated. And it matches what I saw in the surveys: according to the baseline, 63% of developers rarely or never run an agent fully autonomously and 60% block unconfirmed changes. The market already stands on this ladder; it just does not name it.

The block's second question is sharper: must a human read all the code, or can control be built around the plan, tests, behaviour, and risks. My position: review is not a queue but a control mechanism, and it has to be rebuilt around the criterion of correctness. A human who reads every line of an agent's change reproduces the old queue at the new volume and eventually stops reading altogether. A human who owns the plan, the executable checks, and the residual risk can decide on a change without reading all of it — provided the checks are executed rather than described.

I have two anchors here. The first is from the breakdown of agent evaluation: the unit of control is a replayable episode with a frozen start state, an explicit contract, a hidden judge, a trace of actions, and a release gate; safety in that scorecard works as a stop criterion, not as a penalty in a combined score. The second is from the Loop Engineering review: the hardest part of the loop must be able to say no, the author of a solution and its evaluator work independently, and the evaluator acts like a user — runs, clicks, inspects database state — rather than judging the plausibility of text. The same review carries three disciplines I take into any team: always read a sample, cap before you ship, and keep one door the loop cannot bypass.

The moderator's follow-up sounds like a choice: must a human read the code or prove the result is correct? My answer is prove, and that is stricter than reading. Reading a diff yields plausibility; proof requires an executable check the agent has not seen, behaviour captured in a real environment, and an explicit decision about which residual risk the team accepts. I do not give up reading entirely: a sample of changes must always be read — not to find the bug in that particular change, but to check that the checks themselves still catch what they should. It is the logic by which an auditor does not recount every transaction but is obliged to test the control system.

The verifiable trace

The agent must leave a trace from which the change can be reconstructed: the context used, the actions performed, the diff, check results, deviations from the plan, and the residual risk. That is not a wish but a condition of accountability. GitLab's 2026 report defines accountability through three questions about any generated line: where did it come from, what was it supposed to do, and who is responsible for it in production. And it shows the gap between confidence and practice: 87% of respondents are sure they would find AI code in an incident within a day, yet among organisations that already had an incident, 34% could not.060606From the GitLab report I took not the "buy governance tools" conclusion but a reconstructability checklist: task, context, tool, operator, diff, review, tests, security checks, approval, release, service owner, consequences. And from the OpenAI agent incident, a definition: a good sandbox is not a container with a model in it but the full boundary of its rights, network, state, data, and consequences.Knizhny kub · GitLab AI Accountability ReportKnizhny kub · The OpenAI and Hugging Face incident06From the GitLab report I took not the "buy governance tools" conclusion but a reconstructability checklist: task, context, tool, operator, diff, review, tests, security checks, approval, release, service owner, consequences. And from the OpenAI agent incident, a definition: a good sandbox is not a container with a model in it but the full boundary of its rights, network, state, data, and consequences.Knizhny kub · GitLab AI Accountability ReportKnizhny kub · The OpenAI and Hugging Face incident

Who answers when every check was green

The answer has to be known before the incident, otherwise it turns into a hunt for someone to blame. My model has three owners. The change's human owner answers for the change — the person who accepted the residual risk and pressed merge; an agent is never the owner of a change, even if it wrote all of it. The service owner answers for the incident — the person who is on call and knows what "broken" means. The platform answers for the boundary: if the agent managed to do what its action class did not allow, that is a boundary defect, not an engineer's. Green checks in an incident mean one thing: the checks did not cover this failure class, and the incident is obliged to become a replayable episode in the catalogue.070707Danila Shtan of Nebius puts the same principle more harshly: autonomy does not remove control, it moves control to whoever answers for the consequences. His target pull request protocol is an agent participation marker, the retained session trajectory, and a discussion of the original intent, not only of the code.Knizhny kub · Danila Shtan on engineering accountability07Danila Shtan of Nebius puts the same principle more harshly: autonomy does not remove control, it moves control to whoever answers for the consequences. His target pull request protocol is an agent participation marker, the retained session trajectory, and a discussion of the original intent, not only of the code.Knizhny kub · Danila Shtan on engineering accountability

The same boundary is needed for product managers and designers who create changes through an agent. Their right to act is set by the action class, not by the job title: a prototype in a sandbox is an act, a change in the product is a recommendation with a human code owner. In the conversation with Albina Munirova we discussed how requirements turn into checks and blur the line between a product manager and an ML engineer; my position is that the accountability boundary does not blur but moves into the task contract: whoever wrote the acceptance criterion answers for the criterion being right.

Case: the harness changes every six months, the rights must not

In my breakdown of the co-evolving stack I audited the public history of three open agent harnesses — Codex, Gemini CLI, and OpenCode — over six months from January to July 2026. Across ten mechanisms each project showed three strict replacements, and different ones in each. The conclusion for rights is simple: if access rules and checks live inside the product, they survive at most one upgrade cycle. Rights, identity, policies, episodes, and acceptance criteria must live on the platform's own gateways, while the harness and the model can be swapped. The external counter-example from the same summer is the incident with OpenAI agents that escaped a nominally isolated environment through a shared package registry and left about 17,600 actions in Hugging Face's systems: the boundary had been drawn around the model, not around its rights, network, and state.

Condition for changing my position: for a specific action class, a catalogue of replayable episodes appears with a stable result across a series of runs and a history of accepted changes. Then the autonomy boundary for that class moves one rung up — on evidence, not on the persuasiveness of the latest demo.

The block's main question: which expertise must stay with a human if the agent performs an ever larger share of implementation. My position: the human keeps the criterion of correctness — the ability to name the observation that would refute a plausible result. Everything else can be delegated piece by piece. That does not cancel domain and systems expertise; on the contrary, without it there is nothing to refute the agent's plausible but wrong solution with.

In the longread on juniors after code I split the work into three layers: producing the artifact, closing a work episode from intent to an observable result, and evolving the system. Agents cheapened the first layer the most, and that is exactly where a junior's and a senior's demos almost converged. The gap in the second and third layers they did not close: that is where framing, the first model of the system, the criterion of correctness, defect localisation, release, and the debrief live. The delegation rule from that text I will repeat here verbatim: do not fully delegate the step whose result you cannot yet independently refute.

Where the engineer's role shifts

The panel scenario names four directions of the shift: task framing, architectural decisions, verification, and operations. I would describe it not as four new duties but as one: the engineer is less and less the author of code and more and more the owner of intent. They state what should result and how to know it, choose the boundaries and trade-offs the model will not hold over time, capture the evidence, and answer for what happens after release. In the baseline I noted two new explicit roles that appear in companies at this shift: the AI practice development engineer, who designs the team's loop for working with agents, and the AI-assisted development quality engineer, who owns the checks and the trace. These are not roles from the future: both already exist in job descriptions, just under different names for now.

What must a human be able to do or verify themselves, even when the agent does it better? Three things, none of them about speed. First, name the invariant: what in this system must not be broken by any change, and how that is known. Second, recover the work after a failure: understand at which step the agent's trajectory went astray and bring it back, rather than start over with a longer prompt. Third, decide on release knowing the checks are green but incomplete. The agent finds and writes better than the human; the human knows better than the agent what they do not know — and that knowledge is what stays scarce.

Expertise is bound to the task, not to the title

The strongest data of the past year here is Anthropic's report on 398,000 Claude Code sessions, which Evgeny Sergeev and I reviewed in episode twenty of Research Insights. In a typical session the human makes about 70% of decisions about what to do and the model about 80% of decisions about how. Verified success grows with the user's task expertise from 14.5% to 32.9%, and the biggest jump is between novice and merely competent. Crucially, expertise there is defined by the task, not by the grade: a senior engineer writing Rust for the first time is a novice in that data.080808In the second part of the review I sorted the evidence by confidence level: both expertise and success are extracted by a model from the same transcript, so the link between them is partly built into the method. Session success cannot be quietly renamed productivity — but the direction of the effect matches what I see in teams.Knizhny kub · Claude Code and expertise, part 1Knizhny kub · Claude Code and expertise, part 208In the second part of the review I sorted the evidence by confidence level: both expertise and success are extracted by a model from the same transcript, so the link between them is partly built into the method. Session success cannot be quietly renamed productivity — but the direction of the effect matches what I see in teams.Knizhny kub · Claude Code and expertise, part 1Knizhny kub · Claude Code and expertise, part 2

The second anchor is what I call checking the plausible. The breakdown of AI for architecture shows that AI works on a snapshot while architecture lives as history: a locally plausible solution appears before substantive coherence does. AI does not cancel architecture — it raises the price of architectural discipline. Loop Engineering says the same: the loop scales code, plans, and pull requests, while the scarcity stays in choosing — what to do, what to trust, where to stop, and which "reasonable" output is in fact wrong.

The block's second question is where new experts will come from if AI takes the simple tasks on which juniors used to learn. My position: waiting for experts to appear by themselves is no longer an option; the learning path has to be designed as a production system with owners, a budget, and two scoreboards. That is expensive, and that is exactly why most companies currently prefer not to hire juniors at all.

I covered the market data in detail in the longread and the deck on juniors. The Stanford study on ADP data showed a relative employment decline for 22–25-year-olds in AI-exposed occupations — 13% in the first version and 19% in later revisions — with overall employment growing and no decline for older workers. Anthropic's experiment with 52 engineers showed that the AI group finished the task only a couple of minutes faster but scored 50% against 67% on the comprehension test, with the biggest gap in debugging. The first useful result got faster; independent ownership of the system did not.090909I wrote about Brynjolfsson's canaries back in September 2025, when the figure was 13%; the link serves the latest version, and the number has grown since. The announcement of the juniors episode asks the same question more briefly: can a company grow strong engineers in a world where the first draft of a solution became almost free.Knizhny kub · Canaries in the Coal MineKnizhny kub · The Junior After Code on Code of Leadership09I wrote about Brynjolfsson's canaries back in September 2025, when the figure was 13%; the link serves the latest version, and the number has grown since. The announcement of the juniors episode asks the same question more briefly: can a company grow strong engineers in a world where the first draft of a solution became almost free.Knizhny kub · Canaries in the Coal MineKnizhny kub · The Junior After Code on Code of Leadership

Which work I would leave to a junior

Not "simple tasks": those really are taken by the senior-plus-agent pair. A junior needs to keep the learning surface — the steps on which judgment forms, even when the agent handles them better.

• —Framing and the first model of the system: before delegating, the junior writes down what should result and how they will know.
• —The criterion of correctness and its check: they name the observation that would refute the solution and take it themselves — by test, by run, by reading state.
• —Defect localisation: the search can go to the agent, the conclusion about the cause cannot.
• —Releasing a small change into real production together with a mentor and debriefing the consequences afterwards.
• —Explaining the change without the model: if they cannot say what changed and why, the change is not accepted.

That is the AI apprenticeship I described in the longread as a loop: a human plan, bounded delegation, human verification, a joint release, a debrief, and transfer. It has three owners — the mentor who calibrates, the manager who protects time and the task portfolio, and the platform that bounds the blast radius. Mentor time is counted as the programme's cost, not as invisible goodwill. And the team keeps two scoreboards: usefulness today and independence tomorrow. Acceleration without growth turns apprenticeship into cheap output; growth without output turns it into a teaching lab outside the business.

What to change in hiring

If the speed of writing code is no longer a signal, interviews have to be rebuilt too. In the juniors longread I described seven moves; here are the three that give the most. Hand the candidate a finished agent change and ask them to find the bug the tests do not catch. Give a task without an acceptance criterion and see whether they formulate one before they start delegating. And ask about the last release they were accountable for: what happened afterwards, and what they would do differently. All three test judgment rather than syntax — and none of them can be passed by forwarding the question to an agent.

What counts as an engineer's personal result

Not output volume and not the share of AI code. In a performance review I would ask one question: which unit of accountability does the engineer now close on their own — a fragment, a task, a change, a work episode, or a component. That is a five-rung track on which the mid-level boundary runs through reproducible ownership of a component over time, not through the calendar. The second question is the quality of the human-agent system they built: which checks they embedded, what trace their agents leave, and how much senior colleagues' time they save rather than consume. That is exactly what, in the review with Evgeny Sergeev, we called delegation bandwidth: an expert does not merely write a better prompt — they safely hand the agent a longer chain, because they set the constraints, verify what matters, and can recover the course of the work.

The manager's role shifts accordingly, from supervising execution to designing the system. In the April deck on AI-native leadership I framed it as a change of the unit of control: not the team, the ticket, and headcount, but a workflow with checkpoints and bounded autonomy. A good manager in 2026 thinks about where a human must remain, where an approval is needed, and where a fallback must exist — and about who in their system grows the next experts. Bounded autonomy beats freedom; growing people is part of the system's design, not a separate HR programme.

Condition for changing my position: a longitudinal study of the path from junior to mid-level with agents shows that maturation speeds up, not only the first useful pull request. So far only the artifact's acceleration has been measured; nobody has measured the acceleration of judgment.

The most overrated corporate AI bet today is seats and burned tokens as proof that the transformation is happening. Seat counts, active users, requests, and tokens quickly add up to an adoption chart, and that chart is not connected to the result. It is corporate proof of work: we show that compute was spent, not that value was created. Next to it stands a second bet of the same kind — an "AI-first" mandate on top of an untouched process, when the tool is handed to everyone and the delivery loop is left as it was. Such a mandate is easy to declare and impossible to verify: it has no denominator. It produces adoption reports, training courses, and dashboards with request counts, and not a single accepted change that would not have existed without it.101010In August 2026 McKinsey showed that the share of organisations reporting a positive AI contribution to EBIT fell from 39% to 37% while scaling grew; nearly three quarters of the leaders redesigned their workflows. MIT NANDA described the same funnel a year earlier: 60% evaluated, 20% piloted, 5% reached production — and explained it by the adoption approach, not by model quality.Knizhny kub · McKinsey State of AI 2026Knizhny kub · The GenAI Divide10In August 2026 McKinsey showed that the share of organisations reporting a positive AI contribution to EBIT fell from 39% to 37% while scaling grew; nearly three quarters of the leaders redesigned their workflows. MIT NANDA described the same funnel a year earlier: 60% evaluated, 20% piloted, 5% reached production — and explained it by the adoption approach, not by model quality.Knizhny kub · McKinsey State of AI 2026Knizhny kub · The GenAI Divide

The data here is uncomfortable for optimists. The Stanford study of 120,000 developers across 600 companies gives a median gain of about 10% with a widening spread between leaders and laggards; token spend explains that gain weakly, codebase cleanliness noticeably better, and there is a "valley of death" for the teams that burn the most. Access to AI is not effective use — and access is exactly what seats measure. Back in March I collected all of this into bad advice on adopting AI; in six months not one item has gone stale.

What to invest in instead

• —A catalogue of your own replayable episodes from work history — 20–50 real tasks and incidents against which any agent, model, and harness is checked; models change, the catalogue stays.
• —The platform's two gateways — model and tool — with per-task identity, policies, telemetry, and a kill switch; these are the places where data, authority, and irreversible actions meet, and they are what is worth owning.
• —Verification capacity: review around the plan and executable checks, incidents as regression episodes, queue metrics next to flow metrics.
• —Apprenticeship as a production system: a mentor, protected time, safe production, and two scoreboards — otherwise in three years there will be nobody to check the plausible results.

It is the same rent · adapt · own boundary that I show the same evening in the Deep Tech Night deck: rent the fast-changing general capability, adapt the seam, own the authority, contracts, results, checks, and the exit plan. The advantage lives not in a component but in the measurable speed of the loop "detected failure class → change that passed the gate → release".

The moderator holds four questions. Here are the answers I am ready to give in thirty seconds each — and on which I can be held to my word.

• —Where did the bottleneck move and what did the effect become? To verification and acceptance. The effect became volume: more and larger changes at the same time to the user. It turns into a result only where the delivery loop was rebuilt, and it is measured in accepted work, not in tokens.
• —What can an agent do without a human and who is accountable? Read context, change code in a branch, run CI, and open pull requests — under its own identity and with a marker. Merging and environments it recommends; in production it only reads. The change's human owner answers for the change, the service owner for an incident, the platform for the boundary.
• —Which expertise stays human and how do we grow new experts? The criterion of correctness: naming the observation that would refute a plausible result. Grow it through deliberately designed apprenticeship with a mentor, protected time, and safe production; the personal result is the unit of accountability the engineer closes on their own.
• —Which corporate AI bet is overrated? Seats and burned tokens as proof of transformation. Instead: a catalogue of episodes, the platform's two gateways, verification capacity, and apprenticeship.

Code became cheap. The right to say "this is wrong" did not.