Karpathy Built a Product in Two Hours. Willison Needed 321 AI Commits. The Skill Behind Both Isn't Coding.

When an AI agent can produce a working product in the time it takes to get coffee twice, the limiting factor on your team's AI output stopped being who can code. It's who can tell the agent, precisely enough, what "done" looks like — and catch it when the agent misses.

What happened and why it matters

In the same week, two of software's most-watched practitioners each shipped something real using AI agents, not demos. Andrej Karpathy had Claude Opus 5.5 build HackerTube — a working site indexing 6,454 Hacker News-recommended YouTube videos across 150 topics — in about two hours. His own manual steps were creating an API key, booting a server, and buying a domain. Simon Willison described October as a turning point for building playable games with coding agents, after shipping four playable browser games with them, including a real-time strategy game with audio-based multiplayer called Battle Drones. That one took 321 agent commits and twelve rounds of deliberate revision. By Willison's own account, the turning point wasn't a clever prompt — it was the twelfth round of specific feedback telling the agent exactly what was still wrong.

The skill that's left

Read those two stories together and the pattern is obvious: neither Karpathy nor Willison wrote the code themselves. What they did instead was scope the task tightly, review what came back, and give the agent specific enough direction to fix what was wrong — repeatedly. That's not a skill you learn once and move past. It's the same loop, run over and over, and the people getting real products out of agents are the ones who've gotten fast at running it.

For a team that doesn't write software, the equivalent isn't "learn to code with AI." It's the same scope-review-redirect loop applied to a dashboard, an internal tool, a client template, or a workflow. Monday morning, that's picking one task on your list an agent could plausibly handle start to finish, and writing down — before you touch a prompt — what "done" actually looks like for it.

Two teams, two different lessons

Teresa runs operations at a 22-person logistics brokerage. Her team had burned two days building a one-off dashboard tracking shipment delays by carrier, and she wanted the next version built in an afternoon with an AI coding agent instead. Her first attempt handed the agent a one-line request — "build me a dashboard for shipment delays" — and got back something that looked finished and tracked the wrong column. The second attempt worked because she scoped it first: which three delay categories actually mattered, what counted as "late," and which carrier names in the data were duplicates under different spellings. The agent still needed four rounds of correction after that, but each round fixed something specific instead of restating the whole request.

Not every team has Willison's patience for twelve rounds. Marcus, who handles internal communications at a 300-person insurance firm, used an agent to draft a new-hire onboarding guide and accepted the first version almost whole, because it read well and hit every section he'd asked for. It also contradicted the company's actual PTO policy in two places — a factual error no amount of polish would catch, because polish was never the problem. The fix wasn't more review time. It was treating the first output as a draft to check against the source documents, not a finished page to skim for tone.

The barrier to building something just dropped to nearly zero. The barrier to building something correct didn't move at all — it just changed shape, from writing the code to directing whoever writes it.