I Built SpecDD Because AI Kept Forgetting What We Were Building - and Between the Two of Us, We Couldn't Spec-ify a Thing – SpecDD
We believe that this document is primarily AI-generated with some human-written content.
Hacker News Article AI Analysis
Content Label
AI
AI Generated
92%
Human
8%
Window 1 - 100% AI-Generated
← All articles April 29, 2026 A creator’s account of specification-driven development, why context is the real bottleneck, and what happens when you stop treating AI like a search engine and start treating it like a tool that can actually read the manual. There is a moment that every developer working with AI agents eventually hits. You have been building something for a while - a billing module, a new API, a data pipeline - and then you ask the agent to implement the next logical piece. It comes back with something that contradicts what you instructed on three sessions ago. A dependency appears that you explicitly said was forbidden. A boundary gets crossed. A pattern gets abandoned in favor of something the model apparently prefers from its training data. The code is often technically correct, but it is wrong for your project. I hit that moment a lot. It annoyed me greatly. And then I started thinking hard about why it kept happening. The mainstream response to this frustration, as best I could observe it, was to reach for more. More tokens. More retries. More elaborate prompting strategies. Entire products were built around the idea of throwing larger and larger amounts of context at the problem and hoping the model would find the relevant signal buried somewhere inside it. The industry collectively decided that if the thing was not working well enough, the answer was to feed it more. Claw back context from wherever you could find it. Stuff the window. Spend the tokens. Ship the wrapper. I found that unsatisfying in the way that only a real engineer can find a workaround unsatisfying. Not because it never worked, but because it was treating the symptom rather than the cause, and I have never been particularly good at leaving causes alone once I have identified one. If something is not working the way I want it to, my instinct is not to compensate around it. My instinct is to understand it well enough to make it work properly. That is, I would argue, what engineering actually is. So instead of spending more tokens, I started asking a different question: what would it take to give an AI agent exactly the right context, in exactly the right place, in a form it could actually use reliably? Not approximately right. Not probably enough. Exactly right. And that question, pursued far enough, is what became SpecDD. Will AI Make Developers Obsolete?
Window 2 - 100% AI-Generated
Wrong Question. Before getting into the diagnosis, though, I want to address something I hear constantly in conversations about AI-assisted development, because it shapes how people think about the problem and whether they believe a solution like SpecDD is even worth pursuing. The question is whether any of this matters in the long run, whether AI is simply going to replace the practice of software development entirely and make frameworks like this an interesting historical footnote. My answer is an unambiguous no, and the reason is written into the history of every major productivity leap this industry has ever taken. We have been through these inflection points before. The jump from assembly to high-level languages. The shift to object-oriented programming. The emergence of modern frameworks and package ecosystems. Each transition looked, to someone standing at the before side of it, like it might fundamentally change who does development and whether there is any development left to do. Try building a modern web application in legacy Pascal and you will understand viscerally just how large those productivity gaps were. Remember the world before package managers like NPM, before mature build systems, before any of the scaffolding we now treat as furniture? Today you spin up a Nuxt project in seconds, complete with reactive frontend, hot reload, and a curated ecosystem of dependencies ready to go. Think about what that same task looked like twenty years ago. Think about thirty. Each leap was genuinely transformative. And yet none of them reduced the amount of software being built. Every single one of them caused an explosion of new software, new categories of applications, new industries built on top of the new capability. The demand for software did not shrink to meet the new productivity ceiling. It grew past it, almost immediately, and then kept growing. Now, I can already hear the objection: this time is different. This time the leap is bigger. And I will grant you that it is louder, certainly, because the reach of AI extends well beyond software development into almost every domain of human work simultaneously. But I remember the transition from simple code editors to fully-featured IDEs with intelligent completion, integrated debugging, and real-time error analysis. At the time, it felt like magic. Applications that used to take months were suddenly taking days. Some of them took hours. If you were there for that shift, you know exactly what I mean, and you probably also remember that nobody seriously argued it would be the end of programming as a profession.
Window 3 - Human
It just meant you could build more, faster, and want even more still. The current moment feels different in magnitude. It rhymes with every previous one in pattern. AI-assisted development is the same kind of leap, arguably the largest one yet. And I expect the same pattern to hold. But we will not have less software development because of AI. We will have more, considerably more, because every time the cost of building something drops, the number of things people want built goes up faster than the cost came down. That is not a prediction. It is a description of what has already happened, repeatedly, across decades. The industry grew because our capabilities grew, and our demands grew right alongside them, if not faster. Our tools have changed, certainly. But they changed in exactly the same way when the open-source ecosystem matured. We were handed hundreds of thousands of work years of collective human effort, packaged and ready for consumption across registries like Maven, NPM, PyPi, Packagist. Development cycles that once spanned decades collapsed into months. Sometimes weeks. Often days. The profession did not disappear, quite the contrary. The baseline simply shifted. So no, I am not worried about development as a practice or developers as a profession. I am focused on how we do the work well, which brings me back to the problem I kept running into. The Problem Was Never Entirely Intelligence When I started experimenting with what eventually became SpecDD, my working assumption was that the models were simply not smart enough yet. I figured this was a capability problem, a problem that more parameters and better training would eventually eliminate. So I waited. Models got bigger. Yet I kept hitting the same wall in slightly different ways. Let me be clear: there is plenty left to be desired in terms of raw model capability. Anyone who tells you current AI coding models are anywhere close to solved is either not spending enough time in the weeds with them, or lacks the engineering experience to see the structural shortcomings and dangers. To pretend otherwise is naive. Reasoning still breaks down in subtle ways. Long chains of logic still drift. Edge cases still get quietly ignored in favor of the happy path. These are real limitations and they matter, and the industry is actively working on them. But those were not the fundamental problem I kept running into. The wall I was hitting was not about intelligence at all.
Window 4 - 100% AI-Generated
It was about context. This is not a new problem, and that realization was most clarifying. Humans have been dealing with exactly this limitation for as long as we have been building complex software in teams. A new engineer joins a project and spends their first weeks violating unwritten rules that every senior team member treats as obvious. A contractor implements a feature correctly according to the ticket but totally wrong according to the architecture that nobody thought to write down. A team spins up a new service and accidentally duplicates something that already exists because the relevant decision was buried in a Slack thread from fourteen months ago. I have been part of this industry professionally for close to twenty years, and considerably longer than that as a wide-eyed enthusiast who could not stop building things. That is enough time to have watched these exact patterns play out not once or twice but across projects, companies, and entire technology cycles. The symptoms change with the tooling. The underlying dynamic does not. The AI version of this problem is structurally identical, just faster and more relentless. An AI agent does not absorb institutional knowledge through osmosis. It does not remember last week’s architectural debate. It does not carry a vague sense that we do not do it that way around here. It works with exactly what you give it, every single time, and then fills the rest in with reasonable guesses drawn from billions of lines of code it has read that have nothing to do with your project. A smarter model making the same uninformed guess is still making the wrong guess. Too much information, scattered across too many places, arriving too late or not at all. No human thrives under those conditions either. Think about what onboarding actually looks like in most engineering organizations. You join a team, you are handed access to a repository with years of accumulated decisions baked silently into the code, a wiki that was last touched before the last major architectural pivot, and a handful of colleagues who each carry different and partially overlapping mental models of how the system actually works. Nobody sits you down and hands you a complete, accurate, current picture of the whole thing, because no such picture exists in any single place. You piece it together over weeks and months, making mistakes along the way that your more tenured colleagues find baffling because the constraints you violated seemed obvious to them. The knowledge was there. It just was not where you could find it when you needed it.