Start somewhere that has nothing to do with agents.

You have two kinds of people working for you. One takes the assignment and goes quiet, delivers on the date, and comes back to you exactly once along the way, about something they genuinely couldn't call and genuinely shouldn't have. The other asks you eight times a day: can I change this? do it now or later? is this approach okay? Every step waits on your nod. You call it managing. What you're actually doing is working alongside them.

We tend to say the second one "isn't ready yet." Anyone who has run a team knows it usually isn't about the person. Nobody has told them where their authority ends, so they can't tell which calls are theirs and which have to come upstairs. Nobody has told them what "done" looks like, so they can't tell when to stop. Leave those two things unwritten and even a strong person has no choice but to keep turning around to ask.

Now swap in an agent. The one you have is the second kind.

And it's a bit worse than a new hire. When a new hire is unsure, they know they're unsure. Being unsure about its own work is the single thing an agent is worst at, and there's data on that further down. So waiting for it to "mature" is even less promising than waiting for a person to. The only path is to write things down.

That's the question here: how do you stop being the babysitter. Four parts. Why watching buys you nothing. What the part it already runs on its own is actually resting on. How to decide when it should come find you. And where you should be looking, plus the one job you can't hand off.

Writing a feature used to take all day. Now you hand a sentence to an agent and it's done in minutes.

Everyone feels the first-order effect: output got cheap. But there's a second-order effect the excitement tends to bury — when something you used to pay for suddenly becomes nearly free, that money doesn't vanish. It just moves house, onto whatever is still scarce.

Code is no longer scarce. So what is? Deciding what to build, knowing where to call a halt, spotting the problem nobody else saw — your attention.

This isn't the feel-good line that "people matter more now." It's a concrete piece of accounting: when one input becomes cheap and abundant, the value slides upstream, to whatever is still scarce and complementary to it. AI wholesales a unit of output down to almost nothing; the value migrates to what sits above it — attention.

So the claim is short: cheap code, scarce attention. But I want to state it in full. Attention is worth more because its leverage grew — and leverage is double-edged: the same multiplier that amplifies your right calls amplifies your wrong ones. Worse, the moment "attention" becomes the scarce thing we grade, it gets gamed.

Let me walk through it step by step: why this accounting holds, how big the leverage actually is (there's a blank here I have to be honest about), why it turns around and becomes the new bottleneck, and the price it makes you pay.

If you've worked with an AI coding agent, you've seen this scene: the agent finishes a task and reports, full of confidence — "All tests pass ✅". You open the page. Blank screen. Or the API returns 404. "Pass," it turns out, sometimes just means the agent believes it passed.

This is the awkward spot AI-assisted development is in: writing code is no longer the bottleneck — acceptance is. Without watching every change and clicking through every feature yourself, how do you know what the AI delivered actually works, end to end? I made the broader case in The Last Mile of AI Is Infrastructure, Not Intelligence: the intelligence is already good enough; what's missing is exactly this kind of infrastructure.

The two common answers both fall short. Manual acceptance after every change can't keep up with an agent's output — and human eyes miss exactly the worst failures, the ones where the system claims it's fine while a critical path is quietly broken. End-to-end (e2e) tests are, in practice, a program you maintain forever: async, waits, retries, flakiness — and an agent refactoring the internals breaks them constantly. Worse, these days the tests are often AI-written too. When the player is also the referee, a green light doesn't carry much weight.

We built Duhem — an open-source holistic verification tool — because we think there's a third way. This post covers what it is, and a real bug it recently caught in our own product: one that fooled even the container's built-in health check, and that Duhem stopped before release.

In April 2021 I wrote a piece on why modern software engineering can't do without project management. In September 2022, one asking whether your team is practising agile correctly. That December, another on why complexity deserves a seat in software design. At the time they felt like three different topics: process, methodology, architecture. Rereading them recently, I realised all three had been circling the same question: why do more people make a team slower? The complexity piece even opens with the claim that "as project scale grows, complexity increases exponentially — left uncontrolled, it will eventually sink the project."

Years of running teams moved that question off the page and into my own schedule. A project slips; the reflex is to add people. The people arrive and the slip gets worse — newcomers need context, veterans stop to provide it, the meeting count doubles, and the cost of staying aligned grows faster than the output. Fred Brooks nailed this fifty years ago in The Mythical Man-Month (1975): "Adding manpower to a late software project makes it later." Every programmer has heard the line and nodded along. But strictly speaking it has always been an aphorism, not a law — no company can run a controlled experiment on its own team to check how right it is.

Here is the interesting turn: the check finally arrived, and it came from AI rather than management science. In late 2025, researchers at MIT and Google Research tested 180 configurations of agent systems, and the results read like a re-enactment of Brooks: on tasks that must proceed step by step, every multi-agent variant they tried did worse than a single agent — by 39 to 70% — and past three or four agents, adding more only deepened the hole. Fifty years after publication, the man-month got its first controlled experiment. The subjects just happened to be agents, not people.

That is this article in one sentence: AI agent teams are faithfully reproducing the oldest disease of human organisations — and, the more interesting half, they are the first form of organisation in history where the bill can be fully itemised.

On March 11, 2025, Anders Hejlsberg published a post titled A 10x Faster TypeScript: Microsoft was porting the TypeScript compiler to Go.

For most readers this was performance news. For me it was three old blog posts colliding. In 2021 I wrote, within the space of a few months, a piece asking whether Go was really a panacea for backend development, a piece arguing that TypeScript was indispensable for large frontend projects, and a piece praising C#'s developer experience — where I pointed out, almost as trivia, that TypeScript and C# share the same creator. Five years later, all three protagonists converged in a single repository: the compiler of the language I called indispensable, rewritten in the language I interrogated, led by the man who fathered both TypeScript and C#. I knew those articles were connected. I did not expect the connection to close like this.

The collision is worth more than nostalgia, because it exposes what has changed underneath the argument. In 2021, we debated which language was better for humans: which syntax was cleaner, which learning curve was gentler, which type system annoyed you least. The debate never ended. But the referee changed. Since then, AI coding agents have become some of the highest-frequency authors — and the very first readers — of production code. An agent does not care that Go's error handling is tedious or that TypeScript's annotations are verbose. It cares about two things: how fast it gets feedback, and whether that feedback can be trusted.

That observation is the candidate thesis of this article, stated deliberately in its modest form: when agents join the authorship of your codebase, two criteria get promoted to first class in stack selection — agent loop latency (how long one edit-to-trusted-feedback cycle takes) and the density of machine-decidable verification signals (how much of your correctness can be checked automatically, deterministically, per cycle). These criteria do not replace the human ones. They re-rank them. And under the new ranking, some of 2021's verdicts get crowned while others get overturned.

To make that case honestly, I will first excavate what we actually argued about in 2021, then define the two new criteria precisely, then examine three bodies of evidence from 2025–2026, then give the strongest counterarguments their own section, and finally propose a small selection framework you can disagree with productively.

The AWS Summit in Shanghai, 23–24 June 2026.

In June 2026, I gave what was almost certainly the least glamorous talk at the AWS Summit in Shanghai. I opened with a disclaimer: our Nova is not the Nova from Amazon. The Nova on my slides is an internal platform my team builds at HP; the Nova everyone else kept name-dropping is Amazon's frontier model. The room laughed at the collision — and then I spent the session on something no keynote would touch: how we moved a reporting stack off Power BI and onto Amazon Athena and Apache Iceberg. It was a thirty-minute, 300-level breakout, upstairs on the sixth floor, well away from the crowds.

The floor guide: breakout talks — mine among them — on the sixth floor, the keynote on the fifth, the expo downstairs.

Down on the ground floor, the expo hall was selling the opposite of unglamorous. Unitree humanoids reached for objects under hot lights. A dexterous robotic hand, priced at ¥9,999, flashed a peace sign for the cameras. On one screen, a swarm of coding agents shipped software with no human in the loop; on another, an AI turned footage of a football match into tactics and player metrics. The spotlight was on intelligence learning to perceive the world, to make things, and to act in it.

Down on the ground floor: the expo, where the crowds were.

That contrast is the argument of this piece. For two centuries, output scaled with headcount: more work meant more hands. AI is breaking that link — output is starting to scale with infrastructure (models, compute, and data) rather than people. This is the industrialization of intelligence, and like the first industrial revolution, it will be won not by whoever owns the flashiest machine but by whoever builds the floor those machines stand on. My boring migration is the proof in miniature: what made our reports better was not a smarter model but a new foundation underneath them — a refresh that once took four to six hours now finishes in one, and a report you could once only read became data anyone can now question in plain language.

So this article works from the floor up. First, the three frontiers the show floor was celebrating — machines that perceive, create, and act. Then the layer beneath all three, the one I went to Shanghai to talk about: the data foundation that decides how high any of them can climb.

A team of eight engineers has wired AI coding agents into their development pipeline. The agents take tickets off the top of the queue and ship pull requests faster than humans can review them. Six months in, the dashboards look enviable. Test coverage sits at 84%. The p99 latency on every changed endpoint stays under 100 ms. Merge throughput is up 3× since the agents went live. The Friday retrospective is short, because there is little to retrospect on.

Then a competitor ships a feature. It is not a clever feature. Their users had been asking for it on a public forum for six months, and the team's own users had been asking for it on the team's own forum for almost as long. No one on the team noticed. The competitor's launch lands in Slack on a Tuesday, and the room goes quiet, because everyone is asking the same question at once: which part of our system was supposed to catch this?

The honest answer is: no part. Not because someone forgot to build it, but because the team's architecture vocabulary has no word for it.

Every AI keynote in 2026 opens with the same three slides: a bigger model, a faster chip, a smarter agent. The fourth slide — the one about how any of that actually reaches a user in production — is usually missing. That missing slide is where the next decade of value will be created, and it will not be created by another round of model fine-tuning. It will be created by the most unglamorous layer in our stack: infrastructure.

The numbers back the hunch. MIT's 2025 "State of AI in Business" report found that 95% of generative-AI pilots fail to reach production. Gartner found that only 15% of IT application leaders are even piloting fully autonomous agents, despite the agent market projected to grow from $7.8B in 2025 to $52.6B by 2030. The bottleneck is not intelligence. Frontier models cluster around 70–75% on SWE-bench Verified. The bottleneck is everything between a model that can write code and an organization that can ship it — and that everything is infrastructure.

Here is the hot take, stated plainly: as coding gets cheap, infrastructure gets scarce. The DevOps, CI/CD, container, Kubernetes, and cloud-architecture knowledge that the AI narrative treats as "solved plumbing" is about to become the single biggest lever for turning AI capability into shipped product. The reason is simple. Agents can now write code. They cannot, by themselves, run a build, own a deploy, route a rollback, or provision a region. They need a substrate that does those things for them — and that substrate is the accumulated, low-cost, battle-tested output of two decades of DevOps work.

Six protocols. Six automation levels. Seventeen tools. Twelve predictions. One interactive map that ties them all together.

The AI Agent Interaction Landscape is an open-source, bilingual SPA I built to make sense of how AI agents interact with developers, editors, tools, and each other in 2026. This article walks through the key frameworks it introduces—and the insights that emerged from building it.

When SWE-bench scores improved 50% in just 14 months—from Claude 3.5 Sonnet's 49% in October 2024 to Claude 4.5 Opus's 74.4% in January 2026—you'd think AI agents had conquered software engineering. Yet companies deploying these agents at scale tell a different story. Triple Whale's CEO described their production journey: "GPT-5.2 unlocked a complete architecture shift for us. We collapsed a fragile, multi-agent system into a single mega-agent with 20+ tools... The mega-agent is faster, smarter, and 100x easier to maintain."