Everything Looks Simple From Outside
Ask Claude to build you a GTA V clone this weekend. It'll say yes. It'll produce a convincing plan, break it into phases, and ask if you're ready to start coding. By Sunday night you'll both be staring at a tile-based prototype that renders a car sprite that slides around a surface awkwardly, wondering where the time went.
This isn't a capability problem. It's an articulation problem — a gap between what you envision and what you can actually specify. You can't describe what you don't understand, and agents are pathologically eager to attempt whatever you ask. They could challenge your assumptions — they have the world's knowledge at their disposal — but their default is to match your energy, not question it.
I learned this the hard way with a driving game last year. I'd just built a gorgeous 3D sand dune renderer — layered terrain, advanced lighting, fragment shaders, the works. Riding that success, I asked Claude to add a simple box car with cylinder wheels. Struggle. Then I asked for suspension, because the car looked stiff and unconvincing. You put four springs on the wheels, give it some mass, let her rip. Simple, right?
Hours later, the car was still either launching into space like a rocket or collapsing under its own weight. Claude kept suggesting we tune parameters. I kept agreeing. Neither of us flagged that we were trying to solve a problem that game engines dedicate entire physics subsystems to.
When the naive spring model failed, I pivoted to raycast suspension — surely simpler. When that failed, we tried reverse-engineering working examples. More failure. Gemini, asked later to assess the difficulty, delivered the punchline: "It is a common rite of passage for game developers to move from simple box-physics to a car, only to realize that raycast suspensions are deceptively difficult."
Would have been nice to know that before the first attempt.
Gall's Law has survived decades for a reason: a working complex system invariably evolves from a working simple system. You can't design complexity from scratch. You grow it from something that already works. I went straight to what I wanted, assuming it would be simple enough to just work.
The temptation, now that agent swarms and orchestration are maturing, is to solve this by throwing more agents at the problem. But parallelism doesn't close the gap — if you're digging in the wrong place, more shovels just means a bigger hole. You can have a beautifully orchestrated swarm executing a plan that was never articulated well in the first place. More agents just means faster failure on the same flawed foundation.
Discovery is how real software gets made, and agents genuinely extend your reach into domains you'd never touch alone. But the articulation gap is different — expecting it to close without you is just expecting magic.
The agent will always say yes. But good articulation is on you.