With coding agents, specs feel more like source code

Coding agents are shifting software development from a code-driven to a spec-driven process, where detailed product requirement documents (PRDs) and acceptance criteria are becoming the primary artifacts developers maintain. Developers now spend more time writing clear specifications in plain language, as agents translate those specs into source code, making the spec document feel like the "real source code." This change forces developers to think more like product managers, focusing on feature behavior and user flows rather than line-by-line implementation.

The shift I didn’t expect The more I use coding agents, the less source code feels like the thing I personally write. I know. Strange sentence from someone with a computer science background. At university, the model was clean: humans write source code, the compiler turns it into machine code, and the final product runs from there. Source code was the serious artifact. You shaped it, reviewed it, argued over it, maintained it. That model is still true. It just feels incomplete now. In my day-to-day work with agents, the thing I keep touching is the spec. The PRD. The design note. The acceptance criteria. The markdown file where I try to explain, in plain human language, what this thing should do. That file is starting to feel like the real source code. How I got here My path through AI coding tools has been gradual enough that I didn’t notice the shift at first. First it was autocomplete. Copilot suggested the next line, maybe the next small block. I was still writing the code. It just felt like typing with a very fast assistant beside me. Then I moved to chat. Ask a question, copy the answer, paste a chunk of code, fix it, run it, repeat. Useful, but still manual. The model gave me pieces. I stitched them together. Then the workflow changed again. I stopped asking for snippets and started giving tasks. Investigate this bug. Add this feature. Update the tests. Refactor this flow. The agent could read files, edit code, run commands, and loop on the result. Once that became normal, the hard part moved. It was no longer “can I type the code fast enough?” It was “can I explain the work clearly enough that the agent builds the right thing?” So I started caring more about prompts. Then specs. Then keeping those specs clean and up to date. Not because I suddenly became a documentation person. Because the agent was only as good as the document I gave it. From code-driven to spec-driven When I write code by hand, I spend a lot of attention on how the thing works. Which function calls which function. Where the state lives. What the data shape should be. How the edge case should be handled. That is the normal programmer brain, and I still need it. But with a coding agent, I don’t always start there anymore. I start with questions like: - What should this feature do? - What should the user see? - What should happen in the weird case? - What is out of scope? - How will we know it is done? Less “how do I implement this line by line?” More “what are we actually building?” That pulls me upward. I find myself thinking more like a product person. The feature shape matters. The user flow matters. The tiny product decision that used to sit in my head now has to be written down, because otherwise the agent will invent an answer for me. Sometimes the invented answer is fine. Sometimes it is quietly wrong. That is the scary version. A new compiler in the middle The old model in my head looked like this: php 1human-written source code - compiler - machine code - product The new one looks closer to this: php 1spec document - coding agent - source code - compiler/runtime - product If I compress it, maybe it becomes: php 1spec document - agent-assisted compile process - product That middle part includes the coding agent, the generated source code, the tests, the build system, and the normal compiler or runtime. None of the old layers disappeared. The machine code is still there. The source code is still there. But there is another translation step before the source code now. This is the bit that keeps bothering me, in a good way. When the model is strong enough and the feedback loop is good enough, I spend less time inspecting every generated line. I still review. I still test. I still have to catch bad decisions. But I don’t read the code in the same way I read code I wrote from scratch. I read it against the spec. Did the product behavior match what we said we wanted? Did the agent make an assumption that should have been written down? Did the generated code satisfy the tests for the real requirement, or just the easiest interpretation of the words? That is a different kind of work. The document becomes the source of truth A vague spec is dangerous because a coding agent will not stop and feel awkward. It will make a reasonable guess and keep going. That is useful when you are moving fast. It is also how you get a product that is almost right in five different places. So the document needs to be treated more seriously. Not as a throwaway plan. Not as a meeting note that dies after implementation starts. The spec has to be maintained like code. Version it. Review it. Keep it honest. Remove stale decisions. Add the weird cases after you discover them. Write down what is out of scope before the agent helpfully builds it anyway. This is the part I did not expect to care about so much. Documentation used to feel like something around the engineering work. Now, in an agent workflow, it feels like the input to the engineering work. Bad input, bad output. Very old lesson. New place to apply it. What changes for developers I don’t think this makes programming less important. If anything, it makes taste and judgment more important. You still need to understand systems. You still need to know when the agent picked the wrong abstraction. You still need to know what a test is actually proving. And when the smooth path breaks, someone has to debug the mess. But the center of gravity moves. A developer using agents well spends more time defining the work, narrowing the scope, checking the result, and tightening the loop. The code is still there, but the human contribution is more abstract. More product-shaped. More about intent. That feels different from the model I learned at university. Back then, the path from human thought to product went through code directly. Now there is another layer in between, and that layer is getting stronger quickly. I am still getting used to it. Where I’m landing My current view is this: in AI-assisted development, the spec is becoming the new source code. Not because source code goes away. It doesn’t. But because the thing I most need to maintain is shifting. If the coding agent is part of the new compiler layer, then the product spec is the input language. A sloppy spec compiles into a sloppy product. A clear spec gives the agent something real to build from. That has changed how I look at my work. My code, my product, and my own role are not connected in exactly the same way anymore. I still love coding. I still like reading the implementation. But more and more, the thing I am really writing is the instruction manual for a machine that writes the code. And honestly, that is a little weird. The compiler used to start at source code. With coding agents, it starts earlier. It starts with the spec.