Spec-Driven-Development.

Or professional prompt engineering.

Here’s what it means.

An individual writes a detailed specification.

What’s in it?

The overall stack and architecture. The individual inputs and outputs of each feature. How the overall system should operate. The other things that this will integrate with. The non-technical aspects. Security, compliance, and governance concerns.

That’s all?

No, they then pass it off to the clanker. And begin the cycle of validating the output and making threats until you get the result you want. With an escape hatch of doing it by hand if it takes too long.

Why?

Because we all know writing the actual code isn’t the hard part.

For a quick one off prototype or simple CRUD glue, it works well enough most of the time. Given that I know how the end result should look and behave.

Not going to talk about how much these frontier models cost in API calls. That’s related but out of scope.

Here’s my anecdotal experience. The lowest form of scientific evidence, but still a data point.

I can personally attest to multiple developers I know writing little code by hand nowadays. Technical folks generally have a good idea of what output they want, and more importantly, how to validate it.

I believe there is the potential for developers with strong fundamentals to produce great software. Powerful automation can be used to craft exceptional products. But despite that, I would still call myself a Luddite. The word has been bastardized..

Just about everyone I am in contact with who works in software has a top down directive to maximize their usage of these tools. I know at least one UX designer who now ships changes directly to their company’s design system. We’re able to produce more and faster than ever before.

I have seen more and more falling through the cracks. Bugs in production that could have been caught preemptively with more testing. Yes thanks to these tools, we can use a combination of dumping logs and additional context to diagnose and patch it. But there’s an argument to be made about doing it right the first time.

All that being said. I’m not opposed to the idea in theory.

Engineers and developers are historically not that great at leaving documentation. Yes it will naturally drift and will need upkeep, but a detailed specification is valuable. Especially if I can have it written in Markdown in a Git repo instead of scattered C0nflu3nce pages.

But how do we get a detailed spec? You need to understand the software development fundamentals. You need to understand the broader product and its users. And most importantly, you need to understand the business context.

The individual who intersects all three is exceptionally rare, the industry has spent the better part of two decades siloing the knowledge of these domains into individual roles.

Like I said, I am a Luddite by definition. I am fine with more powerful tools and I am against deskilling labor to produce a lower quality output. If we want this to work in organizations, we need to expand skillsets across the board. These silos were always artificial and served a purpose given the landscape. For this to not result in more problems than solutions, we need the technical folks to learn the non-technical aspects of building and vice versa.