Is the Developer Lifecycle Dead? [Testμ 2026]

Systems Built for One Thread

The obvious break is speed. Agents produce code faster than any developer could, and with enough compute, whether that is Mac Studios and Mac Minis on a desk or cloud environments, you can run a whole orchestra of them through a workday.

The old world was one editor and a browser tab. VS Code open, Stack Overflow or a search engine alongside it, and a ceiling set by how fast one person could take a user story or a bug fix and convert it into code, compile it, debug it and push the pull request.

Everything in that world was centred on how fast one human could work and how good their code was. The new world has several terminal windows open, or a native agent app, running multiple threads in parallel.

Managing an Orchestra

His description of what that feels like is the line most engineers will recognise immediately.

The mechanics are the same as managing people. You multitask between threads, and you text instructions into agent sessions instead of into Slack or Teams.

What changes is the goalpost. You stop wanting fast responses, because a thread that comes back every three seconds buries you in context switches, and you start wanting loops that run long enough to leave you time to think about what each agent does next.

He is candid about where that has already left him. In 2026 he barely reads any of the code he produces himself, and he does not read the code produced by the agents of the whole team at all.

Which sets the problem the rest of the keynote works on: how to merge and deploy that volume of code into production without giving up the control you promised your customers, on security vulnerabilities, privacy leaks and plain bugs.

Code Review Was Always Flawed

Asked how teams adapt code review to agent-authored pull requests, he starts by refusing the premise that the old process worked.

His analogy is the spot-the-difference puzzle in a children’s magazine, where you compare two pictures and find the ten things that changed. The puzzle tells you it is ten, because a child who did not know the number would give up.

Code review is that puzzle with the number removed. You face a wall of text written by someone else, tasked with finding all the issues, without knowing how many there are.

So the reviewer calls it done at some point. Five issues found feels like a job completed, or seven does, because the count supplies a sense of achievement that the task itself withholds.

The second flaw is social. A pull request from someone you have worked with for years and trust gets a thumbs up sooner, while a junior developer or a newcomer to the project gets a nitpicking pass, because you are still working out how they collaborate.

The evidence for the flaw is the shipping record. Bugs shipped, vulnerabilities shipped, and changes rolled back a minute later because clicking merge is the moment you notice the one line you had not seen.

AI Reviewing AI

Agent volume makes that failure mode worse in a specific way. Code submitted on Monday refers to code the agent wrote on Friday, which nobody read either, and the unreviewed surface compounds.

He extends it to a codebase with three years of agent-written code in it, and cites Anthropic building Claude Code and other products with Claude Code as the case already running. A team in that position understands far less of its own codebase than it once would have.

His conclusion is that review moves from humans to machines, and he thinks that is an improvement rather than a concession. Specialised security models keep finding vulnerabilities consistently in a way no human sustains across a long review.

He is careful about what that does not mean. Humans should still understand code, and he argues for teaching children to code the way they are taught maths, science, languages and history, as a fundamental skill rather than a job requirement.

The Agent Arena

What the developer watches instead is how the agents collaborate. He calls it managing the agent arena.

The pattern he described has one agent addressing the issues another one found, then the first running a further review loop and finding more, with Cursor and Copilot in the mix alongside them.

Merge readiness becomes a property of that exchange rather than of a person’s sign-off. When the loop reaches a stable state, the agents have converged on the best way to solve the intent the developer had.

Ideas Still Come From Humans

Asked whether the developer still has a role at the final merge, his answer was unambiguous. What the business is, how it makes money, how it finds users and how it presents itself to the world are all defined by humans.

He places the moment in a longer sequence: mechanical tools in the medieval period, machines in the industrial revolution, and now machines powerful enough to generate a large share of our ideas at marginal cost.

He grants that some problems will get solved by machines to a degree that feels uncomfortable given where the industry is coming from. What he cannot picture is humans letting machines define how they want to live, talk or buy.

His evidence is the pandemic. Everyone expected travel and work to change permanently, and instead people travel more, want more experiences and pay more for them.

The practical version of that argument is differentiation. If ideas stopped coming from people, every company and project would look identical, and brand, messaging, business model and product are what stop that happening.

Session Logs as Artifacts

Code stays, in his account, because it is the deterministic product that runs on the computer. What joins it in the repository is the session log.

The split is between two kinds of record. Code defines the how and the what, while session logs define the why, capturing the developer’s thinking including the points where they changed their mind.

That matters directly for the review problem. An agent reviewing a change gets the intent behind it rather than only the diff, which is more than a human reviewer usually had.

He also made the case for agents that push back. His team keeps a Slack channel called my agent says, and a recurring entry is an agent volunteering that it did something and it was not what was wanted.

The reverse happens as often. Exploring an idea with an agent is how he works out that the idea was not the right way to go, the same way a conversation with a colleague does it.

The Loop Inverts

The DevOps lifecycle is usually drawn as an infinite loop, with the inner loop on the left covering everything on your machine, and the outer loop on the right covering collaboration, code review, testing, deployment and observability.

Both halves used to be optimised the same way, which was to make everything faster. Fast compiler, fast debugger, fast tests, short test suites, quick deploys and quick rollbacks, so a team could deploy hundreds of times a day.

The reason was human attention. A slow compile sent a developer to Slack or to a conference talk, and twenty minutes later they had to recalibrate what they were working on, which is exactly the flow state one of the original Copilot pitches was built around protecting.

In the agentic world he still wants a fast compiler and fast tests. What he no longer wants is a fast turnaround for himself.

He wants the agent working while he has dinner with his family and while he sleeps. His own joke during the session was hoping his agents were still running rather than surfacing a question three seconds into the recording, on a decision he would rather they made themselves.

More often than not the agent stops early instead, which is the source of a habit he has heard about from Silicon Valley founders: setting an alarm every two hours through the night to check the agent is still running, out of anxiety about lost productivity.

Designing Long Loops

As long as the token budget holds, running agents around the clock is the best return on investment available. The exception is the one that makes loop design a discipline.

An agent that runs eight hours and produces garbage has spent tokens, which is energy burned for nothing. His image for it is driving your car in circles around your house until the tank is empty without getting anywhere.

His own settings scale with how much oversight is available. An hour or two during the workday, since checking in gives more control over what is being built, stretching to eight hours overnight and up to 48 across a weekend.

The engineering question that leaves is how to know at kick-off that a loop will not go off the rails. His answer is that the input is only half of it, and the other half is evals.

He is deflationary about the word. An eval is a more scientific name for a test: a function whose output you verify against expected assertions.

Designing those two things together is what he thinks engineering now is. A handful of practitioners are good at it and publish both their wins and their mistakes, Andrej Karpathy and Peter Steinberger among the names he pointed to, and everyone else is still learning.

Token Maxing

Engineering leaders have always managed to a backlog and a budget, and in smaller teams that budget is mostly headcount. Laptops, cloud spend and conference travel are the rest, and each has an established way of being shared out.

Tokens break that pattern because they correlate directly with productivity. Set every engineer a budget of $500 a month and the real question arrives when someone reaches it.

Sending them back to manual coding is one option, and switching them to a cheaper model is the other. Both invite the same objection: if that was acceptable, why was it not the default, and is it simply a downgrade you accept for being over budget.

He expects the strongest engineers to be the ones who can spend the most tokens, by running more agents, and also the ones best at picking the right model per task. His example is an agent instructions file that reserves the largest model for planning and pushes the actual work down to smaller ones.

Beyond that he says the industry has not worked it out, other than engineering leaders lobbying finance for more budget on the argument that the productivity expected in this era has a price attached.

Wasted Token Spend

The other half of the budget problem is what the spend is for. Most companies build features for the success of the business rather than for the technology, and success is measured in revenue, profit and growth.

The correlation between a feature and that outcome is rarely as clean as product and engineering managers would like. Features get built on the premise that an enterprise customer signs or a satisfaction score moves, and almost nobody can show a feature that grew revenue 5%.

So the question he puts on token spend is whether it serves the company’s goals or is a side quest, and he named himself as one of the worst offenders at his own company for exploring things not tied to them.

He gave three concrete places the spend leaks.

• Rebuilding what exists - burning tokens to build a helper tool already available as open source, when the existing one needs no tokens to build or to run and works deterministically.
• Agents doing a framework’s job - having an agent read a CI/CD log to work out whether a test passed or failed, when a test framework reports that with no token usage at all.
• Endless sessions - he kept one session open for weeks and ended up with a million tokens of context and no upside, where starting fresh each morning or per problem would have been cheaper and less convenient.

The third bucket he named is buying rather than building, pointing at off-the-shelf products including his own and TestMu AI rather than rebuilding everything in house.

COGS Versus OPEX

Maneesh Sharma offered the cloud comparison: everyone experimented, finance objected, optimisation followed, and what took cloud three to five years to normalise might take AI six to nine months.

Thomas Dohmke accepted the shape of the cycle and rejected the equivalence, on an accounting distinction he thought engineering leaders should hear.

Cloud costs on a production service rise when more users arrive, and more users should mean more revenue. If they do not, the problem is the business model rather than the cloud bill.

Tokens burned coding and reviewing with agents are not tied to revenue that way. Cloud spend of that kind is cost of goods sold, which is allowed to grow as long as revenue grows, because it is managed to a gross margin.

Coding tokens land in operating expenditure, which almost every company fixes to the fiscal year and manages to a dollar budget. A variable cost has arrived inside a fixed envelope, and that is the change leaders have to plan around.

Three Theses for the Next Platform

Asked what the next developer platform looks like, he answered as someone building one, and laid out the bets it rests on.

• Session logs belong with code - stored in the repository rather than in a vendor’s dashboard. Their open-source CLI does this under an MIT licence and works with any git repository and almost any agent.
• The lifecycle becomes loop engineering - which means rethinking coding, code review and testing rather than adding AI to each existing stage.
• Git needs to be a decentralised network - because agents never sleep, so there is no longer a peak hour anywhere and a single-region repository stops being viable.

On the third, his argument is that international teams already work this way. A repository can live on GitHub in the US while a developer in Mumbai clones from a fast local mirror, pushes back to it, and lets the copies sync behind the scenes.

Then he extends it to ten agents per developer running continuously around the world, which removes the notion of a peak load window entirely.

Which brings the keynote back to its title, and to the qualification that makes the answer usable.

He pointed at the financial institutions still paying system integrators to maintain decades-old COBOL, and at the people still writing against Windows 95 APIs because some terminal somewhere runs them. Dead is a word that gets clicks.

What is happening instead is evolution, and the parts of the lifecycle that survive are the ones that still earn their place when agents do the work.

Q & A Session

This session ran as a moderated conversation rather than a talk with an audience Q&A, so the questions came from the host. Two exchanges sat outside the through-line above and are worth keeping.

• Are you seeing customers actually embrace loop engineering?

  Thomas Dohmke: Yes, and visibly. He pointed to people posting about it publicly, naming Peter Steinberger of OpenClaw, Andrej Karpathy and Boris from Anthropic, and made the point that the useful posts cover what is not working as well as what is. Adoption runs from startups to enterprises, and he put the driver bluntly as fear of missing out. The pattern he described starts with a hobby project, often because people were wary of pointing agents at a production codebase without approval from their CISO, and it ends with someone starting a Sunday with an idea and finishing the evening with a working front end and back end, or a usable iPhone app deployed to their own phone. Before, that was the preserve of the top one percent of coders. He extended it to non-technical people using platforms like Lovable or Vercel’s v0 to spin up a marketing landing page or an allowance tracker for their kids, and argued the adoption curve for AI is far steeper than for any technology before it.

• Four years ago every Copilot conversation was about who owns the code. Why is nobody asking now?

  Thomas Dohmke: Because it has become normal. He recalled selling Copilot at GitHub as an uphill battle where the engineers were excited but the legal team, the privacy team or the budget holder were not, and said that in hindsight those days feel early, before anyone understood how far this would go. He also noted what changed commercially: the flat-rate model has largely given way to token-based pricing, because a flat rate no longer works. His framing of the timescale is the part worth holding onto, since all of this happened inside three years rather than ten.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.