Photo by https://unsplash.com/@imshaamim

The legacy

We have been through DevOps driven changes in the industry, where IaC (Infrastructure as Code), CaC (Configuration as Code), GitOps and so on tried to envision a world where configurations of a system define what it means to be able to replicate/produce it into existence.

It meant better templates, better scaffolding and schematic rigour to enforce a master version of desired truth.

We got Terraform, Pulumi, CloudFormation describing api driven ways to instantiate infrastructure.

Kubernetes, Cuelang, Dhall, Ansible gave us further ways to reason about configurations of the system.

What you maintain as an agreed specification, translates in the cloud or target layer as an equivalent implementation manifesting the resource and actively restricting any deviation in it's state unless it's from the actual source of truth.

Re-imagining the process

With LLMs being able to produce more accurate software code in a whole forest-variety of languages as the months roll on (when prompted and refined in isolation), agentic workflows now allow unhinged code implementations to solve whatever the agent comprehended from our prompt/context management tools.

But can we tether it to our actual intentions rather than depend on the non determinism LLMs inherently possess? (behavior can vary model to model or with different contexts).

MCP was a step towards that direction, enforcing programmatic management of features.

Then came skills, superpowers (I am probably missing a ton of other stuff, as this space adds on stuff so rapidly, but eventually some of them stick).

Markdown specs, defining how we want the workflow to reason about the tasks at hand and create code downstream as ephemeral/regenerative artifacts.

In DevOps parlance, infrastructure was the throwaway piece, regenerative, immutable.
One can always spin up a new resource again instead of changing it.
The infra code, configuration specs became the assets that should evolve as per intent.

With the advent of coding agents, now we are at a juncture where it might be possible to think of development itself in similar terms.

The programming implementations being the throwaway pieces, regenerative, ephemeral.
One can spin up the same or an updated implementation again instead of modifying it live.
The spec/design becomes the new assets that can evolve as needed.

Spec Driven Development

Chad Fowler calls it the Phoenix Architecture, you don't refactor existing code, instead treat as immutable artifacts and regenerate when change is needed.

In Spec Driven Development, which is now gaining traction in AI landscape, we have a close coupling between 3 elements.

Spec defines what we want, how we want.

Spec is indicative enough for agents to create relevant tests/contracts.

Tests drive an almost TDD style development process, implement code to satisfy the tests.

Send feedback to check if code matches intent on test and/or spec, give checkpoints for the human in loop to make those decisions on tweaking the spec and iterate.

Will we reinvent the wheel?

Is SDD going to be a sane stable way of reasoning about agentic applications? The new way of understanding how to develop in this paradigm?

Maybe, maybe not. Who knows if this would stick around for the next couple of years?

Some are tinkering with this concept and feeling agent driven code implementations can be still buggy and have loopholes obviously, no matter how great our spec is.

Agent confidently notifying it aligns with tests perfectly when it may have skipped some.

Code solutions being bloated, unoptimized and weirdly constructed since it doesn't do true evaluation of what's better.

Agents taking weird shortcuts or decisions even on the best worded spec, and so on are still observed.

An updated approach might be brewing, which is to provide code implementations/ snippets, basically programmatic harnesses rather than just plaintext may yield better results!

Wait, what?

Actual code implementations for the agent to clearly get the intent, since it cannot make sound decisions all the time (yet)!!

At the end of the day, when the dust settles eventually, maybe we will come back again to revisit first principles and find better processes was the key. SDD might just stuck around as one of the processes.