I use speckit, and while I like the spec/clarify/plan/task/analyze/implement loop (although it can get a bit overwhelming at times), I don’t like that I have to start with writing a spec and implement it to begin with. I am looking for a more of a design phase before the spec phase, where I can talk about the overall application architecture, and then start writing specs for implementing pieces of it.
For instance, let’s say I want to build a github repo provisioner that 1. creates repos with desired setup, and 2. bulk edit repos with secret updates, yaml updates, etc. I don’t want to build both the features at the beginning. I want to first build only the create portion, and then do the bulk edit feature later on. With speckit, I can do this by only telling it to create the spec for the build portion, but later if I want to build the bulk edit portion, the whole application might need to be changed in important places, because it wasn’t a ‘planned’ feature when it was first designed. I want instead to have a design phase where I describe and maintain a doc with the whole application, and when I start the spec for the create portion, the agent can understand that this create portion is only part of a bigger application and can design/implement the create portion accordingly.
Have you come across a situation like this? how do you handle your big applications? Please advise.
At least it’s better than just asking the agent to build something without any control over it, which is what a lot of junior devs are doing these days.
My original comment was flippant, but you’re fightin for your life with earnesty in these replies, so I’m gonna provide what little IRL experience I have in this so far.
Spec driven development is better than ephemeral prompting in the short term while building up… but for maintenance, it works against you.
Once the code has been generated from the spec, the two inevitably drift apart.
Even for humans, this is a problem. Stale docs can waste time and mislead developers, so the best spec is one that is executable to confirm that it still matches the implementation.
But for agents, it’s especially important, because they have a harder time detecting stale docs and disregarding them, and also because LLMs corrupt documents over time, so they will invariably cause this problem.
So the best spec turns out to be tests. Which means your spec is gonna be code, not natural language. (Djikstra has some insight there.)
Which means you need it to be easy to write tests as a human. Which means you need to aggressively refactor. Which agents are not great at doing.
But even if they were, the dirty secret about refactoring is that it’s heavily dependent on having a good taxonomy for your subject matter, which is a people problem and not a coding problem.
My own sense of this landscape is that AI is effective in two radically different scenarios:
I took a course where the capstone was to achieve Ralph Loop Nirvana, to show the suits that I’m willing to play along. But I’m unconvinced. If you let AI consume input that is mostly AI-generated, it seems to inevitably deteriorate.
There’s no avoiding it: you simply must get your hands dirty in order to keep things organized, and that’s at odds with any of these “your new job is to be a manager, or SME, or PM, or whatever” tactics.
Appreciate the insights. In all my years as a programmer, I was never the tdd kind of guy, and looks like it has now come to bite me in the ass. I need to learn how to write tests and validate/write my own tests to the code. I’m still pretty new to all this, so I’m yet to be in a position to face the long term consequences