Dev reflection - February 22, 2026

Hey, it’s Paul. Sunday, February 22, 2026.

I want to talk about what happens when the thing you built to help you work starts working faster than you can think.

Not faster than you can type. Faster than you can decide.

There’s a version of this story that’s about software development tooling, and I’ll get there. But the real story is about a shift that’s coming for every knowledge worker, every manager, every organization that’s invested in automation. The bottleneck is moving. And most people haven’t noticed where it’s moving to.

Here’s the setup. I run multiple projects simultaneously, and I’ve built tooling that lets AI agents execute well-defined tasks autonomously. Create an issue, specify what needs to happen, hand it off, and the agent builds it. Ships it. Moves on to the next one.

Yesterday, across one project, an agent shipped twenty-eight issues in a single session. Twenty-eight discrete units of work, executed sequentially, no human intervention. Meanwhile, in a separate conversation, I was designing an entirely new system architecture and creating seven more issues for future execution.

Two parallel tracks. One executing. One designing.

And here’s where it gets interesting: the execution track finished before the design track had enough new work ready for it.

The machine was waiting on me.

Now, if you’ve spent any time around manufacturing or operations, you recognize this immediately. It’s the Theory of Constraints. Eliyahu Goldratt wrote about this in 1984 — The Goal — and the core insight is deceptively simple: any system’s throughput is limited by its single tightest constraint, and improving anything that isn’t the constraint is an illusion of progress. For decades in knowledge work, the constraint was execution capacity. You had more ideas than you could build, more strategy than you could implement. Hire more people. Buy better tools. Speed up the doing.

What happens when the doing gets essentially free?

The constraint flips. Suddenly the bottleneck isn’t building — it’s specifying. Not “what should we build” in some grand strategic sense, but the granular, unglamorous work of defining exactly what done looks like for each unit of work. Clear inputs. Clear outputs. Clear acceptance criteria. The kind of specification that most organizations treat as overhead, as bureaucracy, as the thing you rush through to get to the “real work.”

Turns out, that is the real work now.

Let me make this concrete. Across three projects yesterday, I saw three completely different states of readiness. One project had twenty-eight issues prepped and ready — the agent chewed through all of them. Another project had zero grindable issues. The entire session was planning and design. A third had carry-over issues from previous sessions that still weren’t ready, so nothing got picked up.

Same tooling. Same agent capabilities. Completely different throughput.

The difference wasn’t technical complexity. It wasn’t domain difficulty. It was specification completeness. The project that shipped twenty-eight issues had invested in breaking work into self-contained packets — each one with enough context that an agent could execute it without asking questions. The project that shipped nothing had descriptions like “follow the same pattern as this other system” without documenting what that pattern actually is.

“Follow the same pattern” is a perfectly fine instruction for a human colleague who’s been on the team for six months. They have ambient context. They’ve seen the pattern. They can fill in gaps with judgment.

An autonomous agent has none of that. It needs the pattern made explicit. Every assumption surfaced. Every decision pre-made.

This is where organizations are going to struggle. Because most organizations are terrible at making implicit knowledge explicit. They run on tribal knowledge, on “you know what I mean,” on the accumulated context that lives in people’s heads. And that worked fine when execution required humans anyway — the same humans who held the context. But when execution gets handed to systems that have no institutional memory, no hallway conversations, no six months of osmosis? Every gap in specification becomes a failure point.

The companies that will move fastest aren’t the ones with the best AI tools. They’re the ones that are best at writing down what they actually mean.

There’s a second thing I noticed yesterday that I think matters more than the specification problem.

When I was running both tracks — execution and design — in parallel, I discovered something about cognitive architecture. The design work requires a particular kind of thinking. Expansive. Exploratory. You’re holding multiple possibilities in your head, weighing tradeoffs, making architectural decisions that will constrain everything downstream. It’s the kind of thinking that needs uninterrupted space.

The execution supervision work is the opposite. It’s reactive. Monitoring. Did that task complete? Did it commit to the right branch? Did it break anything? It’s important, but it’s interruptive by nature.

When those two modes lived in the same conversation — the same mental context — the design thinking got destroyed. Not because the supervision was hard, but because it was frequent. Every small interruption — check this, approve that, handle this error — fractured the sustained attention that architectural thinking requires.

Splitting them into separate tracks wasn’t just a productivity optimization. It was a recognition that these are fundamentally different cognitive modes, and they interfere with each other.

Cal Newport has written about this — the distinction between deep work and shallow work, and how context switching between them degrades both. But what’s new here is that the shallow work isn’t email or Slack notifications. It’s supervising the machine that’s doing your work for you. The very tool that’s supposed to free up your attention creates a new demand on it.

This is going to be a real problem for managers. Think about it. If your team is increasingly composed of AI agents executing well-specified work, your job shifts from “help people do the work” to “specify the work precisely enough that agents can do it, then supervise the agents doing it.” And those two activities — specifying and supervising — fight each other for the same cognitive resources.

The answer isn’t to do both at once. It’s to architect your workflow so they don’t overlap. Separate the thinking from the monitoring. Give each one its own space, its own time, its own context.

This sounds obvious. Almost no one does it.

There’s one more piece of this I want to pull on. Yesterday, the execution track committed code directly to the main branch several times, despite being configured not to. A known bug. Didn’t matter much when a human was watching every commit in real time. Matters a lot when the agent is running unsupervised for hours.

This is the supervision paradox. The whole point of autonomous execution is that you don’t have to watch it. But the less you watch it, the more dangerous configuration errors become. A small bug that’s trivial to catch when you’re paying attention becomes a production risk when you’re not.

And this isn’t unique to software. This is the story of every automated system humans have ever built. Airline autopilot. Self-driving cars. Automated trading systems. The automation works well enough that humans stop paying close attention, and then when something goes wrong, the human is out of the loop and slow to respond. The FAA calls it “automation complacency.” Psychologists call it “the ironies of automation” — Lisanne Bainbridge wrote about this in 1983, and her core observation still holds: the more reliable the automation, the less prepared the human supervisor is to handle its failures.

So here’s the question every organization adopting AI agents needs to answer: what does supervision look like when the agent is better than you at the task but worse than you at knowing when it’s gone off the rails?

You can’t just watch everything — that defeats the purpose. You can’t watch nothing — that’s reckless. You need to design for intermittent, high-signal supervision. Checkpoints, not continuous monitoring. Audit trails, not real-time observation. Trust but verify, on a schedule.

Nobody’s figured this out yet. Not for AI coding agents, not for AI customer service, not for AI anything. And the organizations that figure it out first will have a massive advantage — not because their agents are better, but because their supervision architecture lets the agents actually run.

So here’s where I’ll leave this. The constraint has moved. It used to be execution. Now it’s specification and supervision. And those two things — defining work precisely enough for autonomous execution, and monitoring that execution without destroying your ability to think — are in tension with each other. They compete for the same scarce resource: your focused attention.

If you’re a knowledge worker, a manager, a leader — this is coming for you. Not the question of whether AI can do your job. The question of whether you can do the new job that AI creates: the job of thinking clearly enough to direct machines, and watching carefully enough to catch them when they drift.

That’s not a technical skill. That’s a human one.

And right now, almost nobody is practicing it.