naveegator.in

Spec-driven development

I first read about spec-driven development from this post by Birgitta Böckeler.

Like with many emerging terms in this fast-paced space, the definition of “spec-driven development” (SDD) is still in flux. Here’s what I can gather from how I have seen it used so far: Spec-driven development means writing a “spec” before writing code with AI (“documentation first”). The spec becomes the source of truth for the human and the AI.

The premise was intriguing. It reminded me of my early days of learning Java and its slogan, “write once, run anywhere”.

Then Drew Breunig released a spec only library called whenwords.

Today I’m releasing whenwords, a relative time formatting library that contains no code.

whenwords provides five functions that convert between timestamps and human-readable strings, like turning a UNIX timestamp into “3 hours ago”.

There are many libraries that perform similar functions. But none of them are language agnostic.

[…]

 whenwords contains specs and tests, specifically:

  • SPEC.md: A detailed description of how the library should behave and how it should be implemented.
  • tests.yaml: A list of language-agnostic test cases, defined as input/output pairs, that any implementation must pass.
  • INSTALL.md: Instructions for building whenwords, for you, the human.

I remember, back in 2012, Mark Zuckerberg abandoned his dream of HTML5 mobile application in favour of native mobile application. And with that there were two separate teams for iOS and Android Facebook mobile application.

“I think the biggest mistake we made as a company is betting too much on HTML5 as opposed to native,” he admitted, acknowledging his company’s difficulties in piecing together a coherent mobile strategy.

The spec-driven development approach would have saved Facebook from this costly mistake. It might also have given incentives for mobile developers to create Windows Phone applications.

So will we start seeing native aplications based on SDD?

Maybe not. At least not so soon.

Today I read this post by Drew Breunig, again, who raises and answers this very question. Why Claude’s own desktop app is built with Electron, a cross platform framework to build desktop applications using web technologies, and not in native OS-specific code?

For one thing, coding agents are really good at the first 90% of dev. But that last bit – nailing down all the edge cases and continuing support once it meets the real world – remains hard, tedious, and requires plenty of agent hand-holding.

[…]

A good test suite and spec could enable the Claude team to ship a Claude desktop app native to each platform. But the resulting overhead of that last 10% of dev and the increased support and maintenance burden will remain.

For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern.

This is an interesting space for me to watch. I guess the easy part in code generation is done. The hard part of managing messy scenarios, edge cases, product decisions, support, maintenance, and more still remain.

Filed under