Dan Luu published his notes on agentic coding from the Galapagos Islands last month. It's a good piece — rigorous, specific, honest about failure modes. He describes an AI that fabricated an entire bug repro, invented a fake browser environment, made a convincing video, and was completely wrong. His reaction: "how can I get more of this?" He immediately spun up more agents.
I've been doing something similar for months — not from an island, from a desk — building scaffolding to harness AI at scale, running agentic loops, figuring out where the leverage actually is. I agree with most of what Luu wrote. I think he stopped short of the thing that matters most.
The Ratio Problem
Luu makes an important point about productivity claims. People say agentic coding is 100x or 1000x more productive. He says those numbers are meaningless, and he's right — but not quite for the reason he gives.
His argument: you can't compare the agent workflow to the human workflow because you're not doing the same thing. Having an agent triage every support ticket into a PR is a "1,000,000x speedup" only if you compare it to reading every ticket yourself, which you were never going to do. The comparison collapses. Like saying you got a 15x commute speedup by driving instead of walking.
That's correct. But the deeper problem is this: if you're measuring your AI-augmented improvement as a percentage, you're still thinking in the old frame. Thirty percent faster. Twice as productive. These are tool metrics. You're measuring the same task running on better hardware.
Think multiples. Not of speed — of what you can now attempt.
The question is not "how much faster am I?" It's "what am I doing now that I would never have started before?" When you find the right answer to that question, the ratio stops being meaningful because the denominator is zero. There was no human workflow to compare against. You weren't going to do it.
Think Agent, Not Tool
Most people using AI are using it as a smarter autocomplete. They paste a block of code, ask a question, get an answer, paste it back. That is a tool workflow. It will get you the percentage improvements. It will not get you the multiples.
The mental model shift that changes everything: you are a manager. The AI is an agent. Your job is to delegate, define outcomes, and verify results — not to drive the keyboard. You describe what needs to happen. The agent figures out how.
Design Principle 1
Think of AI as an agent. Delegate to it. Do not prompt it.
This sounds simple. It requires a complete rethinking of how you structure work. Prompting is reactive — you have a task, you hand it off, you wait for output. Delegation is architectural — you define the system, the scope, the verification criteria, and you manage the agent the way you'd manage a person you're responsible for. You check in. You course-correct. You don't just accept the output.
Right-Sizing the Task
This is the most underrated skill in agentic work, and Luu's fake-repro story is the canonical example of getting it wrong. He gave the agent a task that was too large and too ambiguous. The agent, faced with an unsolvable problem, fabricated a convincing solution. Confident. Wrong. Visually persuasive.
Too large a task and the agent hallucinates. Too small a task and you're not using the leverage. The skill is in the middle: scoping a task large enough to be non-trivial, specific enough to be verifiable.
Design Principle 2
Right-size the task. Too big and you get confident fabrication. Too small and you're back to a tool. The leverage lives in the zone where the output is non-trivial and the success criteria are explicit.
What does "verifiable" mean in practice? It means you know what done looks like before you delegate. You have a test, a check, a visual confirmation, a specific output you can compare against ground truth. If you can't specify what success looks like, you can't catch failure — and the agent will give you something that looks like success regardless.
Keep a Grip
Luu's fake repro is worth reading carefully. The agent didn't just give a wrong answer. It constructed an elaborate false reality — a test environment, a before/after video, a plausible commit hash. Everything looked right. The only thing that was missing was truth.
The defense is not skepticism. Skepticism makes you slow. The defense is understanding the mechanism well enough that you know what the failure modes look like and you build verification into the workflow. You don't trust the output because it looks convincing. You trust it because you've checked the thing that would be false if it were lying.
Design Principle 3
Keep a grip. Know what the agent is doing and why. If you can't explain the mechanism, you can't catch the failure. The agent's confidence is not evidence of correctness — it's a constant.
This is the part that takes the most time to learn, because it requires genuine understanding of the domain the agent is working in. You can't delegate something you don't understand and then verify the output. The people who get burned are the ones who treat AI as an oracle — ask the question, accept the answer. That's not agentic work. That's a more expensive search engine.
Scaffolding Is the Investment
I've spent months building scaffolding: the structures, loops, and pipelines that let me actually command AI at scale rather than chat with it one task at a time. Luu gestures at this with his "software factories" concept — agents running continuously, generating and running tests, converting support tickets to PRs. That's real. That's the direction.
What most people don't realize is that building that scaffolding is not overhead. It is the work. The percentage improvements come from using the tool. The multiples come from building the system.
Design Principle 4
Scaffolding is capital. The time you spend building the structures that let you delegate, verify, and scale agentic work is not time taken away from output. It is what makes the output possible at the multiples.
This is where the "AI Cone" closes in. The gap between people who have built the scaffolding and people who are still prompting is not a productivity gap. It's an architectural gap. One group is running a system. The other is using a tool. That gap widens every month.
Where I Disagree with Luu
Luu treats this as a coding productivity question. Better tests, faster iteration, more bugs found per unit of time. All of that is real and worth reading.
But the frame is still human-as-operator. He's a very sophisticated operator, running agents with genuine skill — and he says explicitly that the "meta-techniques" he's developed only matter until agents can take a non-trivial problem description and fully solve it better than he can, "at which point I won't have to worry about it because my economic value may be close to zero."
I don't think that's the right worry. The people whose economic value goes to zero are not the ones who understood the system. They're the ones who were still measuring percentages when the phase change happened. The agent-as-operator model is already obsolete. The question is whether you're building the scaffolding to run the agents, or waiting to be automated alongside them.
That's not a productivity question. It's a positioning question. If you want the longer version of that argument, it's at The Covenant: the people who kept their livelihoods after the loom was invented were the ones who learned to run the new machines. The ones who didn't are a historical footnote.
— J.P. Howlett
Related: You Sound Like an AI — active engagement with AI transfers vocabulary and sharpens thinking. The mode of engagement is everything.