Csaba Tamas

Kelly Johnson built America's first jet fighter in 143 days, with a tenth of the engineers such a project would normally take. In a circus tent. Every company has admired that model; almost none have copied it. Kelly could hand-pick the best engineers in the company and build exactly one aircraft, with no portfolio, no maintenance burden, and no other customers. Everyone else chose capacity over speed and paid the coordination bill. This was the tradeoff until now. AI levels the playing field, by allowing for smaller teams without losing output, enabling product portfolios with support and maintenance.

Execution used to be the expensive part of building software. Now it is cheap, and judgment is the scarce part. That lowers the value of every role built around moving work between people instead of deciding what the work should be. And it is increasing the value of making sound decisions.

This talk applies Kelly's method to AI-native product development, starting with the contradiction at its centre. He fixed the specification before anyone started building. Then he let engineers redraw the design whenever they liked. Rigid about what the aircraft had to do. Relaxed about how it got there.

It worked because the drawing was never the valuable thing. The specification was. A drawing was one attempt at meeting it, and attempts are meant to be thrown away.

Software has spent twenty years doing the reverse. We keep the goal vague and treat the code as precious. We argue for months about scope, then refuse to rewrite a module because it took three weeks to build.

AI removes that excuse. Code is now cheap enough to discard, the way Kelly's drawings were. But cheap code without a fixed specification is just more rework without net progress. Teams that hold both halves will pull ahead. Teams that add AI to an org chart built for expensive handoffs will continue to fall behind competition.

A story about 1943, and about the product team you will be running next year, whether you plan for it or not.