Spec Driven Development and coding with LLMs

As a million other pundits have said, our technological landscape is evolving at a rate none of us have ever experienced. LLMs and LLM assisted coding is one of the most fascinating developments I’ve encountered in my career and I am enjoying diving deep into all facets of it.

What is particularly interesting to me is just how rapidly their capabilities are changing, and in turn, how rapidly we as developers need to adjust our work practices in response. And the rapidly growing capabilities of the frontier LLMs is what brings me to the topic of this post - Spec Driven Development.

It’s not that I have an issue with the methodology. Especially when working with LLMs, concise clear context and good guardrails are vital. I just don’t think the tooling out there is helping in any way whatsoever. OpenSpec and spec-kit are the two utilities that I recently encountered and I had a few thoughts to share on them after digging through their source code.

TL;DR - These tools are a lot of code around figuring out which coding CLI you are using so they can dump their pre-packaged prompt templates into. Woohoo?

Both repos, by the line. The glowing amber sliver is the entire idea — a few thousand lines of prompt markdown. Everything else is machinery for shipping that markdown to the right directories.

What’s really ironic is just how much overhead and cruft these tools have as baggage, ESPECIALLY under the spotlight of this machine learning space. Never have I seen a technology change so rapidly, and never have I had to continually evaluate and adjust my workflow like I have when working with LLMs. With every new frontier model every new minor version bump of Opus, they become more capable. More context, better tool usage, better rule adherence and fewer mistakes. Every new frontier model’s card comes with frequent reminders to re-evaluate your prompts and tooling to ensure that you aren’t inadvertently hampering the new versions. These tools seem to be going deep in the other direction.

The coding tools themselves have advanced at an insane clip these past 6-8 months too - check out awesome-cli-coding-agents on GitHub if you don’t believe me. Not only have the tools themselves proliferated but the capabilities have too. They all support planning modes, task planning, subagents, and LLM-As-Judge /goal and /loop long horizon coding. I use Claude Code and pi as my primary coding tools and with more LLMs than I can count and via every source of inference available - lab APIs, Foundry, Bedrock, OpenRouter, local inference ( oMLX/LM Studio/llama.cpp) and so on.

It’s not that I don’t like standards and procedures, quite the opposite as a matter of fact. Clear and consistent standards paired with self-describing, discoverable interfaces are the thing that makes all of this development work. In order to develop fast, you need to remove friction and uncertainty. If you leave opportunities for a developer (you, a colleague or an LLM) to find an easy path that’s not in alignment with standards - they’re going to find it and they’re going to use it.

Templates, patterns and modules make this the golden default path when starting new projects. Consistent API patterns, data models, UI component libraries and template repos are all things that developers have been doing for ages so as to eliminate the repetitive boilerplate and just get into writing code that aligns with standards.

To be fair, coding with LLMs has its challenges and earlier models needed a LOT of structure and guardrails around them to get the level of output you want. But these days? METR, an independent organization dedicated to evaluating frontier LLM capabilities and their risks, recently announced their need to develop more complicated benchmarks because the latest generation of models are already saturating their benchmarks on tasks that are estimated to take a human 16 hours to complete.

Task length an AI agent finishes at 50% reliability, by release date. Data: METR, Horizon v1.1 — remixed in the house style. The capability you’d be building scaffolding around doubles about every six months; the scaffolding does not.

One thing (maybe) worth its weight

If I’m being fair there is one idea that has some potential value. OpenSpec’s validator is a ~500-line script that validates your requirement files, ensuring that each requirement follows a specific convention. It’s a linter for requirement file grammar/structure.

So what do I actually suggest?

Nothing exotic, nothing crazy. If I’m going to invest in using a tool, downloading and running it in my environment, it needs to prove its worth. And from my perspective, these tools offer very little above and beyond what a typical developer toolset provides for without extra overhead and/or process.

Here’s an example repo if you want to poke around at something rather than read about it - jasondostal/dotnet-api-platform

All of the slash commands are kicking off premade prompt templates. Quick side note - one of the prompt templates marks tests as optional and says to only include them in a plan if they are requested. Now that sure sounds like the kind of foundation I want to build on!

All of the slash commands and other features in those CLIs are just running the prompt templates that the 30k of Python in the utility copied to your coding harness’s default directories. If you really felt compelled to make your own prompts, just save them as templates and set up slash commands for them in your coding harness. I wouldn’t bother much these days with how good the native planning mode is in these tools but it’s certainly doable. Same with the “constitution” thing these tools want to make for every single project. For personal dev work, just put a common CLAUDE.md or AGENTS.md in a template repo. You can even make a template repo with additional project/platform specific standards. GitHub is, shockingly, purpose built for teams of developers to cross collaborate on a single repo or file and changes to architecture or standards documents flow into the natural developer workflow without extra effort. All the change lifecycle stuff in these tools are PRs and their workflows.

Agents are incredibly good at parsing reference material and discovering information. Rather than dumping tons of context and information into Markdown files, structure your environment so that it’s self-documenting, self-describing and has easily discoverable interfaces. Building CLIs with great help text, data sources with defined structures/models and APIs that follow conventions are all ways that you can provide an LLM with learnable surface without having to document it. Those examples - along with your template repos you created, right??? - become a natural way for you to accelerate development with LLMs.

The frontier LLMs don’t need special tooling or processes to learn about features and break them down either. Jira, Azure DevOps and every other major work management platform provide APIs and MCP servers. Drop your PAT into a secure environment file and you can tell your agent to go pick up a Jira item and implement the story per specs and standards and off it goes. It’ll even create Subtasks and keep them updated on screen and in your backend app as it works!

Testing and validating both your features and your standards are not complicated tasks these days. Quite the opposite - if you HAVEN’T been doing unit / integration / end-to-end testing in your coding work… why not? Today’s tools are still called linters, but that is almost a disservice. Roslyn can be used in C# projects to assert virtually any rule you can think up. NetArchTest and ArchUnitNET can enforce architecture and conventions. API parity tooling is universal.

The premise of Spec Driven Development is that your specifications and natural language become executable and repeatable - like code. Rather than putting a ton of inefficient workflows and processes in place, I’d suggest just using the tooling we developers have used for ages to accomplish these things.

As developers and engineers we have a responsibility to be prudent about the tooling we use and run in our environment. These toolkits are bloatware claiming to solve a problem that doesn’t exist and easy to implement routine dev practices already do the job. One of them includes phone home telemetry turned on by default, another runs arbitrary shell commands from YAML with a community workflow catalog fetched via the internet with zero integrity checks. These are not the kinds of things you want to be running in a mature engineering shop.