< Infinite Monkeys

For many classes of coding tasks I'm still faster than AI in a straight-line drag race. I know the codebase, I know what I want, and I can just write it. When I first started using AI coding tools seriously I'd sit and watch the agent work, waiting for it to finish before I reviewed. It was like pair programming, except my pair was slower than me and I couldn't talk to it mid-thought.

The breakthrough was when I stopped watching.

I started kicking off a task, switching to something else, kicking off another, and cycling back to review the first one when it was done. Twenty tasks in flight at once. Some land first try. Some need a nudge (and some go sideways). But while I'm reviewing one, the others are still cooking. The ones that nail it on the first shot take care of themselves.

It's the infinite monkey theorem in reverse. Instead of random monkeys eventually producing Shakespeare, you have pretty-good monkeys producing pretty-good code right now. You just need enough of them that the ones requiring intervention don't bottleneck the ones that don't.

The other half is task selection. If you throw high-ambiguity work at AI, the probability of a one-shot[1] result drops dramatically. I've found the distribution is U-shaped — tasks either land cleanly or go properly sideways, and when they go sideways the intervention is significant. That's where my frustration tends to bubble up. If you shape the work into clear, bounded tasks, the hit rate goes way up. The skill isn't prompting per se — it's decomposition.

This only works if the surrounding system supports it. Tight coupling and shared state kill parallelism, which wouldn't be a surprise for those working in large engineering teams. If every PR conflicts with every other PR, you're back to sequential no matter how many agents you spin up. Same goes for process. Fast CI, automated previews, risk-based reviews.

But the hardest part is what it does to your day. Instead of carving out time for deep-thinking, you're constantly context-switching between tasks in various states of completion[2]. That's genuinely hard, and I'm not sure it's a healthy default long-term[3][4]. But it's where the leverage is.

I write about AI, organizations, and engineering leverage: find out about me and subscribe here.

Discuss and share via the meta page . Filed under AI, Code, Productivity, and 100PR.

Footnotes

  1. "One-shotting" is a bit of a flex, but I think it's probably the right flex.

  2. Managing twenty things in flight is a very different skill from writing code. I'm still figuring out whether it's a skill I want to be good at.

  3. I wrote about this tension in Your Brain on GPS. The more you lean on the tools, the more you should worry about what atrophies.

  4. There is a counter-point to this in that I think my day is overall more balanced at the moment. I'll write about that another day.