RELEASE 02

One theme, two lenses. Amelia Prasad on where spec-driven development serves and where it quietly costs us. Tom Barber on why reviewing AI-written code is now the expensive part.

{{current_date_full}} · Read online

Welcome to the Concept to Cloud newsletter. One theme an edition, two takes on it, ours. If it would not earn a place in our own inbox, it does not go in yours.

This edition is about building software now that the writing part got cheap. Amelia takes the spec side: what a finished spec still leaves unsaid, and the human judgment that gets flattened when the format does the thinking. Tom takes the bill: why the gaps a model quietly fills show up later, and why review just became the expensive part of shipping. Grab a coffee.

By Amelia Prasad

Spec-driven development has come into focus lately and is being used by many companies as the next direction in product development. As with any new technology, it should be evaluated and used responsibly. The question that I want to raise today, and that I raise for our practice, is: if we define a spec and allow it to build the product in the rhythmic execution that AI is capable of, do we lose the human nuance that allows us to feel the flow and fit of a product with our customer base?

As a rudimentary definition, spec-driven development is essentially giving an AI a prompt for what you want in natural language, and then what you get back is a specification or a product requirements document (PRD) that describes what is going to be built. AI can go forth and build from there. It emulates the steps of product development, but you are leaving it to automation much sooner in the process.

We can talk about a spec as a noun. It is a document that specifies what is to be built, but we should also think about its roots as a verb. To specify in product is a process that requires understanding the constraints and understanding the points of interest. Usually, as something is built, the specification tends to evolve as new information comes in. The risk we run is that if we leave everything to automation, if we say, "Okay, let's build all the things," we may lose touch with some of the pulse of how that build-out should meet customers as we go.

What is that pulse of human-driven product development and what do we gain or lose by allowing more to be AI-driven? Does spec-driven development keep us tied into minutiae, when a human in the process might have a better sense of what to let go of for cost or viability. Does the rigid structure blind us to the natural rise and fall of information, so that a reader can no longer tell what was well defined by a human rooted in customer discovery and pain versus what got filled in to satisfy the format. Is it all beneficial. Where does it even fit, product or engineering, does it belong to either. Underneath all of that is one throughline. Does the speed of a complete artifact remove the time an idea needs to saturate, turn, and resolve, the time that used to let both the builder and the user learn their way into what's being built. The constraint under all of it is that humans take time to process. Automate everything, and we're not saving that time, we're just handing ourselves a different kind of overwhelm.

When in the product cycle should a team actually launch spec-driven development? Should it be before the customer research or after? Does it start when an entrepreneur has a new idea and they know exactly what they need, or after?

The danger is in the speed itself. It's doing discovery once and handing it off to automation without continuously doing discovery, keeping customers in the loop, and doing that testing. When we do spec-driven development early on, it's an abstraction that we've turned into something concrete that we haven't validated. That becomes a dangerous piece for a product. Especially if that spec-driven development turns into something that requires a lot of engineering, safety guards, and funding, it can become an expense on time and funds if it is not done properly.

It's really important for that spec to have continued review. This happens in sprints, product direction meetings, quarterly mappings, and the like. It is very important to keep the understanding that while we may have specified everything, the reality remains abstract and to be validated by feedback, input, and the actual product process.

Anything being built requires creativity. We rearrange the pieces that we have to yield a result that is favorable to our audience.

In a properly researched product, people building it before spec-driven development were surely getting the sense of what they were building as it evolved. They got a sense of what felt right or wrong as the product grew. Thinking about the function of products more broadly, every product is meant to either fulfill a service or change an industry via fulfilling a service efficiently. As products evolve, we metabolize them in society, and then we need new products. It's a leapfrog effect where we get a technology, absorb it into our culture, then need a newer technology, so on and so forth.

In the course of that leapfrog effect, those doing the building hone in on their product sense for that particular industry fit. When AI is building and the thinking has been offloaded, there's no one to understand the sense of what's being built, no felt sense of it. It's just ticket to ticket and a rhythm with no room to notice whether the thing is actually good or not. You've made hundreds of tickets and they are being built and deployed without question or room for feedback and only an interest in speed which means it's a cadence that leaves no room for creativity.

If you give an AI a natural language prompt and let it build everything, do you still have full ownership of your product when someone comes back to you? Can you look at that finished spec and tell what a human worked out from real discovery versus what was filled in to satisfy the format? Perhaps that is a compliment to AI, but does the trail disappear when iteration has to happen over an entire spec?

This is not to say this is bad. It is to say that humans are needed in the loop. It should be clear to the team what is being built, why it is being built, and why certain decisions were made. That provenance matters not only for owning your own product. If you do not evaluate it, a competitor will see the decision that should have been made, a decision based on people and intention, and they will make it. Their product may do better. That is why it is important to keep this ownership front and center.

Spec-driven development comes with clear impacts, but one side of the equation is minutiae, cadence, and human cost. There are different ways this can go, depending on how a business is set up and what pieces are in what places. The more useful question at this stage is what happens after an end-to-end run through this process: what gets lost when the time to pause, consider, and adjust disappears along the way, and what is gained by keeping it? The older process had built-in pauses. Production took time, and that time was when ideas had room to sit, turn over, get resolved, and get discussed in a room. That is not wasted time. It is how the less obvious connections surface, and it requires a genuinely unhurried interval, because the limiting factor remains human interaction. People only move as fast as people move. Technologies can speed along and deliver much of what was imagined, but assessing whether something is truly the right fit still takes time to consider. The time saved before, the soft time for that human interval, has a corresponding cost after if it is skipped: the harder time paid in course correction when iteration has to happen over an entire spec. The gain from the soft time is concrete: the human interaction and introduction that make a product succeed, not just ship, and that gain is protected by not letting spec-driven development run wild on a new product. The clearest place this shows is onboarding. Onboarding is not just showing a new screen, it is changing how something is understood to work, and that step cannot be skipped. The leapfrog effect applies here: a product can be built to be the best product on paper, but if people are not introduced to it gradually, not everyone can jump into the deep water a spec-driven document creates. Onboarding therefore becomes critical, not only as interface, but as reputation, marketing strategy, need assessment, demand creation where needed, and clear articulation. If the expected conversion does not arrive, is it because the spec did not deliver what was wanted, or because the work was not allowed enough time to sit as it should have? There is no single answer here, it is something to consider within the context of understanding the speed of human processing.

Where spec-driven development belongs shapes how much yield it returns and how many pitfalls are avoided. Research and discovery sit naturally in product, so spec-driven development is used iteratively there. In engineering, specs should be delivered with high specificity in engineering pockets, with each done well before deployment. The check is whether the thread of the deliverable's needs stays intact as the spec develops, or whether the work drifts into what could be created. A useful spec can offer a perspective that was not there before, but the editorial filter remains whether it keeps to the needs of the deliverable. Engineering treats ambiguity as a liability, a spec tends to pay for itself there. Early product treats ambiguity as the material, and a spec too early tends to flatten the signal being sought. Used in the right pockets, the yield is highest.

At the end of the day, spec-driven development is just a tool, and humans shape how much yield it returns. When it is used responsibly, the return is stronger. The real cost shows in more than one register. It shows economically when development and deployment move without proper market research, the cost to fix things arrives later, and while iteration has a natural cost, building out fully without that soft interval tends to mean a greater cost at each turn. It also shows reputationally when something is released that its intended audience cannot readily digest. Reputation is affected when, in fact, the product could have been strong, and a loop that was inexpensive to build becomes expensive and harder to repair later. For the business, the suggestive question is what the cost of that automated minutia proves to be, and whether the yield justifies it, put directly, what is the cost of course correction, and which cost was worth paying: the soft time before that buys success, or the hard time after that buys back ground?

FREE THIS MONTH: THE PRODUCT BLINDSPOT REVIEW

Before the paid launch we're giving away a handful of Product Blindspot Reviews. A working session with our product, design and engineering leads, plus a short written read on what is holding your product back and what we would do about it in the next 30 days. Normally $1,200, free for the launch cohort, in exchange for honest feedback.

By Tom Barber

Writing code in 2026 is cheap. You can throw a prompt at an LLM and ask it to build something for you, and if you're lucky it'll probably even work.

When you're building software a lot of thought has to go into the architecture. What language, what backing data store, how the security is designed, what it will cost to run. The problem in 2026 is that everyone, and I mean everyone, is building something, often without any real regard for how it's built.

Amelia's piece looks at this from the specification side. A spec can be finished and still say nothing about the things that decide whether the software can ship. It will cover the button copy and the field validation and leave out tenancy, retention, and who is allowed to read row two. The model fills those gaps with something plausible. When you read the result you can't tell which decisions a person thought about and which were generated to satisfy the format.

So build away, but know when the bill arrives. You find out the data leaks like a sieve when a customer's security team sends over a questionnaire. The design choices show up on the first full month's hosting invoice, and the missing audit log becomes a problem when a buyer or a regulator asks to see it.

Code review is the last point where any of that is still cheap to fix. Someone who knows the system reads the code and finds the problem in an hour, instead of you paying for a re-architecture six months later. That only works if the review is real. A large diff of tidy, well-commented code that nobody wrote is harder to review than a colleague's messy pull request, because it looks like it has already been thought about.

Review is now one of the more expensive parts of building software, and it needs staffing and scheduling accordingly.

Concept To Cloud · product engineering for regulated and PE-backed companies · concepttocloud.com

You are getting this because you subscribed. Unsubscribe · Preferences