this post was submitted on 31 May 2026
8 points (83.3% liked)

Experienced Devs

5631 readers
1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 3 years ago
MODERATORS
 

cross-posted from: https://programming.dev/post/51247328

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.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] doo@sh.itjust.works 2 points 1 week ago (1 children)

I've not used speckit and likely reinventing the bicycle, but here's my process.

Idea.md in the root with a pitch of the system Readme.md in the root with technical information

Then I'm using moth (https://github.com/tailoredshapes/moth) to file ideas and track tasks. Those files are definitely not full specs, just several lines of the core of the issue.

Then I have a command /moth that instructs to read current moth, brainstorm design with me and when agreed, implement. Also as the agent works it should keep an up to date spec under ./spec describing the scope (explicitly no code details) as it evolves, decisions taken and rejected (adr like). It underscores that the task is only done when I say so. Superpowers skill is essential here.

Then there's the back and forth on development and testing.

Eventually another command /moth-done that instructs to run the full test suite and mark moth as done.

So the essence is that I don't expect to know the full specification beforehand, but I keep track of decisions and expect to refactor often and aggressively. Conveniently writing tests is now easy and I have plenty of both unit and e2e.

That's an interesting approach! I'll look into moth, thank you!