15

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.

top 16 comments
sorted by: hot top controversial new old
[-] talkingpumpkin@lemmy.world 13 points 1 day ago

For the fellow community members who are not up to date with the latest AI ~~BS~~ trends:

  • if you search for "speckit" you'll land on https://speckit.org/ "Spec Kit - AI-Powered Specification-Driven Development Toolkit"
  • if you've never heard of "spec-driven development" it's because, far from being a noteworthy development practice like TDD or DDD, it's just another word for "leave all coding to coding agents"
[-] nieceandtows@programming.dev 1 points 1 day ago

It is 'leava all coding to agents', but at least it's 'leave most of the design control to me'. I was, and still am, and old style programmer yelling at AI to get off my lawn, but like any new technology, I'm trying to do my best to learn and make best use of it so that I grow as a developer even though it is meant to 'save money for the company'. It's here whether I like it or not, so I'making sure I don't lose my job because of it, while still being employable when it inevitably crashes to the ground.

[-] Azzu@leminal.space 3 points 4 hours ago* (last edited 4 hours ago)

It's interesting that so many people are able to do this. For me, I'd just rather lose my job than do something I fundamentally disagree with. If I didn't, I would just be so extremely unhappy that I couldn't function anyway.

Not bashing you, just pondering the differences.

Lemmy might not be a good place to ask about AI unfortunately. Most people here HATE it.

I'm 100% with you on this. I don't love AI but I'm not going to let myself be pushed out of the field by people who cannot program, just because I don't like something new.

[-] nieceandtows@programming.dev 3 points 14 hours ago* (last edited 14 hours ago)

Glad to know there is somebody else sharing my feelings on this. Even with ai critical comments, there's still some great comments here. I cross posted this to experienced_devs and there a bunch of useful comments there as well.

[-] something183786@lemmy.world 4 points 23 hours ago* (last edited 23 hours ago)

Superpowers has brainstorming

Note that the current version injects a lot into the system prompt, and it’s always on. If you using Claude Code, install it in a second profile, so that you choose when to use it. I exploring its features now.

https://github.com/obra/superpowers

The Basic Workflow

  1. brainstorming - Activates before writing code. Refines rough ideas through questions, explores alternatives, presents design in sections for validation. Saves design document.

  2. using-git-worktrees - Activates after design approval. Creates isolated workspace on new branch, runs project setup, verifies clean test baseline.

  3. writing-plans - Activates with approved design. Breaks work into bite-sized tasks (2-5 minutes each). Every task has exact file paths, complete code, verification steps.

  4. subagent-driven-development or executing-plans - Activates with plan. Dispatches fresh subagent per task with two-stage review (spec compliance, then code quality), or executes in batches with human checkpoints.

  5. test-driven-development - Activates during implementation. Enforces RED-GREEN-REFACTOR: write failing test, watch it fail, write minimal code, watch it pass, commit. Deletes code written before tests.

  6. requesting-code-review - Activates between tasks. Reviews against plan, reports issues by severity. Critical issues block progress.

  7. finishing-a-development-branch - Activates when tasks complete. Verifies tests, presents options (merge/PR/keep/discard), cleans up worktree.

The agent checks for relevant skills before any task. Mandatory workflows, not suggestions.

[-] kibiz0r@midwest.social 5 points 1 day ago

Spec driven development is a scam.

[-] nieceandtows@programming.dev 1 points 1 day ago

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.

[-] kibiz0r@midwest.social 8 points 13 hours ago* (last edited 10 hours ago)

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:

  1. Tasks with unambiguous acceptance criteria that can be quickly, automatically, and deterministically checked. You can let it go nuts against that kind of task, as long as it’s not allowed to move its own goalposts.
  2. Tasks with trusted inputs and subjective outputs, like information-gathering. The key here is that a human will consume the output and then produce something else as the next step, not simply hand it off as gospel to an artificial implementer.

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.

[-] luciole@beehaw.org 3 points 1 day ago

I suggest you design the core bits of your project, actually fucking program it yourself, see what works and what doesn't, review design, and repeat. (This is a programming community.)

[-] nieceandtows@programming.dev 4 points 1 day ago

I have 18 years of programming experience, this is not about not knowing how to code. It's about using a new technology effectively without losing your identity as a senior programmer. May be you have the ultimate say in your company, and can stave off agentic coding until the bubble bursts, but I don't have that luxury. Agentic coding has fucked up all output velocity expectations, so even if you don't use them, you're still expected to output at the new velocity, which would just about kill mj love for programming.

[-] Azzu@leminal.space 1 points 4 hours ago

which would just about kill mj love for programming

How is the expectation of coding fast killing your love for programming, but stopping programming altogether and letting an AI do it is not?

[-] e0qdk@reddthat.com 2 points 1 day ago

I'm not familiar with the tool you're using and my big, traditionally written projects have largely been organically grown over the years as unpredictable requirements change -- mostly I just try to keep things readable enough that I can jump back in when I need to do so on old projects...

It sounds like you want to incorporate LLMs into brainstorming though. Maybe try using the word "elicitation" in your prompts for early phases? e.g. "ROLE: Requirements Elicitation Specialist" or "ROLE: Architecture Design Elicitation Specialist". You can also meta-prompt to get a system prompt tailored to your specific needs.

[-] PumpkinEscobar@lemmy.world 2 points 1 day ago

Openspec has an “explore” command you can use to give some thoughts and have agent spit out a high level plan, some back and forth, then create the proposal once you’re happy. I’ve also generated markdown documentation for a subsystem or thought so I can check it in, then continue improving that later, then when ready to turn it into a proposal and implement I start by referencing that document.

It sounds like a big part of what you’re talking about is just pre-feeding future concerns into one proposal for work that you plan to do in the future, also nothing wrong with that. I’ve used “in the future we will need … so design in that direction without implementing in this first iteration” sort of wording.

And not sure if this applies but I’ve found big monolithic code bases become too large for AI to work well in… enforcing some boundaries by breaking code into technical foundation and vertical slice functional modules really helps decouple code and focus on cross-module boundaries and interfaces, similarly to how they help reduce cognitive load for developers, helps for AI too

[-] nieceandtows@programming.dev 3 points 1 day ago

How is open spec for Greenfield apps? I've heard it's best suited for existing code. I'll try the 'in the future' heads up, thanks

[-] PumpkinEscobar@lemmy.world 3 points 21 hours ago

It works pretty well for greenfield, that’s where I’ve been using it. A pretty involved monorepo with a decent bit of code and things are still going reasonably well.

Also, leaning on documents as deliverable artifacts for people and for AI awareness / consumption helps me.

Like put together an architecture document for either the entire application or specific parts and subsystems (or multiple documents with different granularity) those can list future considerations.

I pretty often will include those documents when generating proposals / specs to make sure the AI is building in the right direction. It’s not perfect, there are some rough edges and these are the early days of this whole process.

this post was submitted on 31 May 2026
15 points (67.4% liked)

Programming

27108 readers
257 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS