← Back to blog

· Timothy O'Brien

Cargo Cult Development

The tools are installed, the practice is unchanged, and the airplanes don't land.

A bamboo lattice control tower with a single dot operator beside a runway edged with small fire dots, while a faint amber-line airplane passes far overhead in the haze — the ritual below, the landing that never comes above.

Most of what passes for AI-assisted development right now is cargo culting.

During World War II, American forces built airfields across remote South Pacific islands, and cargo arrived by the planeload: rations, radios, jeeps, canned meat. When the war ended, the military left, and the cargo stopped. On some islands, people rebuilt what they had seen. They cut airstrips out of the jungle. They built control towers out of bamboo and carved headphones out of wood. They lit fires along the runway edges and waited. They had watched every visible step of the process that brought the cargo, and they reproduced all of it. The planes never came back.

Richard Feynman told this story in his 1974 Caltech commencement address to name a failure he kept running into in science. “They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land.” His target was research that follows all the apparent precepts and forms of scientific investigation while missing something essential. He called it cargo cult science.

Walk through a development shop in late 2026 and you’ll find the same kit everywhere: Claude Code in the terminal, Cursor in the editor, agents wired into the review pipeline, MCP servers in the config. Much of it is installed for one reason — everyone else installed it. The mandate came down from above: we need AI-driven development, now. So the team stood up the stack in an afternoon, added the tools to the interview loop, and put them on the roadmap slide. That’s the airstrip. Those are the fires along the edge.

You can tell when the heart isn’t in it. The licenses are active and the practice is unchanged: the developer still types every line, still reviews the diff character by character, still declines every suggestion. Or someone genuinely gets into it, and the agent still sits in the corner of the screen producing completions the human never accepts. Both are the same situation. The model is present, and nothing about the work has changed. The spend shows up on the invoice, and nothing shows up in the design.

Here’s what the ritual misses. These models are not built only to help you write better code. They’re built to help you think about what you’re doing: to evaluate the architecture, to pressure-test a design before you commit to it, to propose a decomposition you never considered, to argue the other side while you argue yours. That work happens before the first line of code, and it’s the work these tools are actually good at.

So step back and ask. “Argue against this design before I build it.” “Give me three other architectures for this problem, and what each one would make easy or impossible.” “If this requirement turned out to be wrong, how would I find out?” “Review the concept, not the code.” “What part of this design is convention instead of a decision?” Those are different requests from autocomplete, and they use the part of the model that autocomplete never touches.

I guarantee some of you are already typing the objection: no, you can’t trust it with that. You can. Trusting a model with an architecture review does not mean shipping whatever it says. It means arguing with it — the same treatment you’d give a sharp colleague whose first answer is sometimes wrong. You check the claims, you push back, you keep what survives. The engineers getting real value out of these tools already work like this. The model is their most patient reviewer: available at any hour, holding the whole codebase in context, with no ego about being contradicted.

Feynman’s test was blunt: the planes don’t land. Run the equivalent on your own week. Did the tools change any decision, or only the typing? If you can’t name one design decision that came out differently because you asked the model — really asked, about the plan and not the code — then your development practice is what it was before, with better equipment. Stop, take a step back, and ask the model about the thing you’re building: whether the architecture is right, what else it could be, and whether you should be building it at all.

Keep reading
This post is part of the thinking behind Orchestrator: Your Next Job Title — recognizing and building the work of delegated intelligence.