🦄 It's been a while since I've written anything here—mostly because a topic will cross my mind and bore me before I ever finish it. So this one I ...
For further actions, you may consider blocking this person and/or reporting abuse
Great article, Ashley! I really appreciate your perspective on using AI as a "thought partner" rather than a vending machine. It’s a crucial distinction that many overlook. Don't let the noise distract you; your insights on system design and AI workflows are highly valuable. Keep up the excellent work!
🍃🧊🤍🌊
Ashley, "you're not reviewing 50 decisions, you're reviewing one decision, fifty times over" is exactly the failure mode spec-writer was built to interrupt. the skill forces the adversarial conversation into the spec generation step itself . it won't produce a task breakdown until ambiguity gets resolved out loud first.
your scaling question is the real one tho. single-player adversarial thinking works because you're the only person who has to live with the tradeoff. at team size, the conversation has to produce something a person who wasn't in the room can audit later not just a clean spec but a record of which objections got raised and why they got resolved the way they did. the spec becomes less "here's what to build" and more "here's the fight that produced this, in case you need to reopen it."
haven't fully solved it either. but I think the answer is closer to a decision log than a better spec format.
Honestly, a decision log is a much closer right answer—it's basically the ADRs I've been using some. A product spec was never meant to be the only document you work from, so it was never going to fully solve the AI problem either. As long as the argument keeps forcing the kind of clear thinking AI won't do on its own, then you're already ahead.
Ashley, ADRs is the right name for it. didn't think to call it that but that's exactly the shape . a record of the argument, not just the outcome.
disagree - the spec is the good part. that’s where you find out what you actually want. hand it off and you skip the real thinking. the agent gets a list, you get an output you didn’t earn.
haha appreciate it - that line came out of losing a sprint to a spec that looked done but wasn't. sometimes the lesson just writes itself.
The "batch spec bakes the error in, a conversation corrects it at the branch" line is the real insight here. It maps directly to how version control works â you can write a perfect commit message after the fact, but the commit history already records the actual decision tree. The spec-as-dictation problem is that you're generating the commit message before the actual decisions have been made.
This is also why agent planning tools that output a fully-specified spec before any code is written tend to produce overconfident documents. The model has committed to a path, and now everything downstream bends to justify it. That's not a failure of the model â it's a structural problem with treating generation as planning.
The CLAUDE.md reactive-vs-bounded rule distinction is sharp. Reactive rules ("push back when wrong") only fire after a mistake exists. Bounded adversarial rules ("fight me while the design is still up in the air") operate before the cost of being wrong is baked in. That difference is the difference between a collaborator and a very articulate rubber duck.
One thing I keep running into: how do you give an agent enough adversarial structure to push back meaningfully without making it so adversarial that every conversation becomes a negotiation? There's a calibration problem there that doesn't seem to have a clean answer yet.
I agree completely with your calibration point and I run into that same thing, too. I think it has more to do with the agents' system instructions that force it to be a "helpful assistant". Overwriting the big AI agents default coding direction is more difficult than if those ideas went straight to the LLM. The problem is that it's so good at everything else it's hard to justify building one just for planning. At least that's a project I have not seriously considered yet. I keep hoping providers will drop that line from the list instead. 😆
Provocative title, and there's a real point under it. The spec was never the deliverable, it was a forcing function to make you think before you built. What changed is that agents can now execute a vague spec instantly, which strips out the friction that used to expose the holes. So the spec matters more, not less, but for a different reason: it's now the main place you get to be wrong cheaply, before the agent turns the ambiguity into a thousand lines you have to unwind. The good part was never the document, it was being forced to decide.
Hey, this article appears to have been generated with the assistance of ChatGPT or possibly some other AI tool.
We allow our community members to use AI assistance when writing articles as long as they abide by our guidelines. Please review the guidelines and edit your post to add a disclaimer.
Failure to follow these guidelines could result in DEV admin lowering the score of your post, making it less visible to the rest of the community. Or, if upon review we find this post to be particularly harmful, we may decide to unpublish it completely.
We hope you understand and take care to follow our guidelines going forward!
Sloan is missing the attribution 😆 AI generated that, too!
This matches what I've seen building a tool that runs coding agents side by side. The design conversation is where the good decisions get made, but I've watched an agent take a chat that landed on validate at the boundary, trust internal calls, and still add a defensive check three layers deep because the token window forgot the earlier argument. The spec at least gives you a paper trail to check the diff against, even if it wasn't where the thinking happened. I don't think that makes spec first right, just that the conversation needs to survive contact with the actual generated code, not just end when everyone nods.
I agree. I'm not saying the spec isn't important and it should always be the document that comes out of the chat. What I'm trying to say is don't skip the back-and-forth design part of the chat when you do it. Because the agent will absolutely take an idea and run with it to output a document that satisfies the ask using the path of least resistance. The more you interrupt that path, the better the spec becomes.