Skip to main content

The dream of code that writes itself 🕯️

I recently read a pitch for AI-supported, spec-driven development.

We need a paradigm shift: the Specification-Driven SDLC, where high-quality, version-controlled specifications become the new source code. In this world, senior talent isn’t replaced; they are elevated to the role of “Conductors,” orchestrating an AI workforce to translate their architectural intent into flawless implementation.

Lineart illustration of a moth

There are many tools making similar promises right now. It makes me wonder whether expressing intent in its purest form is an irresistible yet unreachable goal. A flame that we developer-moths are drawn to.

Similar ideas in history #

It is said that history doesn’t repeat itself, but it often rhymes. The spec-driven development ideas could’ve been dropped into half a dozen earlier eras and it would’ve fit right in.1

  • 1950s–60s: Automatic programming: Pioneers imagined describing problems in English-like form and letting machines generate code. Ambiguity and complexity made this impractical; precise logic still had to be spelled out. (Languages like COBOL and FORTRAN still helped shape our industry.)

  • 1970s: Chief programmer teams: A lead “chief programmer” who best understands the system’s intention directed a team of specialists. In reality, rigid hierarchies couldn’t handle communication needs and evolving complexity.

  • 1980s: Fourth-generation languages: Let developers specify what they wanted rather than how to achieve it, mainly for databases and forms. They failed with general-purpose logic and required frequent workarounds. (SQL is perhaps the most well-known survivor.)

  • 1990s: Model-driven development: Graphical models promised automatic code generation from system designs. Models became as detailed as code, drifted out of sync, and tooling was slow and brittle.

  • 2000s: Model-driven architecture: Platform-independent models aimed to generate implementations for multiple platforms. Differences between platforms and heavy tooling made the process cumbersome.

  • 2010s: No-code and low-code platforms: Let users build applications through visual interfaces or simple declarative specifications. They struggle with complex logic, integration, and maintainability, limiting them to simpler workflows and prototypes.

Is it different this time? #

As these examples show, the same ideas seem to pop up regularly. Some ideas stick around and evolve into modern incarnations. Yet the final step to a high-level specification still eludes us. We try to bottle architectural intent into a neat spec, but the world’s messiness always seems to leak out.

  • Abstractions can’t cover all edge cases; humans must dive into the guts eventually.
  • High-level specifications get too detailed and collapse into another form of code.
  • Hard to generalize from specific domains to general-purpose programming.
  • Generated code is brittle, unreadable, and un-debuggable.

Or will AI-based code generation actually work? Machine learning models might handle ambiguity and gap-filling better than past tools. But even if it gets 95% right, the remaining 5% can still be brutal to debug.

Maybe this time it’s actually different—but the challenges remain eerily familiar. Are we really at a turning point, or just reliving old dreams with new tools?


  1. I am too young to have personally experienced most of these earlier incarnations. The descriptions are also simplified to fit bullets. If you find anything that is wrong, please let me know. ↩︎