SpecKit creates the illusion of work, generating a bunch of text

[NaikSoftware]

Even after providing complete and detailed information, the result is as follows:

• Files are created ignoring the project structure, because the focus is not on the project, but on thousands of lines of instructions
• Even instead of simply adding a test to the existing structure, it tries to create new files and generates hundreds of unnecessary tests, most of which make no sense at all
• Overengineering, because the LLM, instead of executing a concise command, is busy analyzing kilobytes of text and generating new texts, completely losing the essence of the work

Conclusion: The area of use for SpecKit is very limited - it's for testing new ideas, generating simple prototypes. For proper incremental work, you need to:

• Conduct an analysis of the project and task; here, ordinary simple queries to an LLM are very helpful
• The developer themselves should think through the steps for implementation; LLM can be used for clarification, but under no circumstances should planning be handed over, because LLM != AI, it cannot know what exactly is the purpose of the task. It's still a large and complex, but neural network.
• Atomic tasks can be given to the LLM, but controlling all changes and directing them in the right direction.

Based on the described points, SpecKit only complicates the work. The project needs to change its concept - it's not about software development, but more about generating ideas and a general plan. It's more a tool for a product owner than for a developer.

P.S used with Claude Code (Opus 4.1)

[scotteveritt]

I believe if you have a well defined constitution and take the time to invest in refining the plan stage then it could be well worth the effort. I'm realizing that for smaller changes, speckit is overkill. But, if you'd like to make significant changes to a codebase then it's a useful tool. I do agree that if you are not careful during the plan phase it will ignore most of the current codebase structure.

For claude usage, i recommend creating a plan with Claude first, refining it, then before approving claudes plan, simply deny the plan and proceed to only type "/specify". This gives you a good starting point plan. Well, better than specifying one yourself.

[kevlingo]

I started my development journey back in the VB4 days (yikes, that does date me!). Over the years I’ve worn a lot of hats: from being an independent developer to overseeing larger projects with contracted teams. That mix has given me some perspective that I think relates directly to your points.

Like you, I’ve seen countless tools and philosophies come and go, all promising productivity boosts. AI tools are the latest rabbit hole, but they require a different mindset: we need to approach them as if we’re contracting work out. If we don’t provide clear direction, we’ll get results that miss the mark.

This ties back to your critique of Spec-Kit:

• Overengineering and messy project structures → I agree this happens, but I see it as a symptom of poor context management rather than the tool itself. The real “magic sauce” is filtering only the relevant documentation into the AI’s context so it can deliver focused, atomic results.
• Hundreds of unnecessary tests → I think that’s what happens when we throw the whole kitchen sink at an LLM. Tight scope and incremental context keep it on the rails.
• Atomic tasks under human direction → Completely agree. LLMs shine when they’re given specific, bounded jobs. Documentation + context engineering is how we make that possible.
• Better for product owners than developers → I’d reframe this: to get value from AI, developers themselves increasingly have to think like product owners, project managers, and architects. That’s a shift, but also an opportunity.

So, while I share your skepticism about Spec-Kit as a drop-in tool for incremental dev, I think the real opportunity lies in how we manage context and documentation. Done well, it can bridge the gap you’re pointing out between “toy prototype generator” and “practical assistant.”

PS I used ME to write this 😄 (I know you were talking about the model you use when you code, but I couldn't help it!)

[NaikSoftware]

I believe if you have a well defined constitution and take the time to invest in refining the plan stage then it could be well worth the effort. I'm realizing that for smaller changes, speckit is overkill. But, if you'd like to make significant changes to a codebase then it's a useful tool. I do agree that if you are not careful during the plan phase it will ignore most of the current codebase structure.

For claude usage, i recommend creating a plan with Claude first, refining it, then before approving claudes plan, simply deny the plan and proceed to only type "/specify". This gives you a good starting point plan. Well, better than specifying one yourself.

Problem not in description, not in planning. I have well documented task (new feature). Described all needed things: constants and their values, places where I need the changes and so on. Its a real task with some increment for the user. But instead of just investigating codebase and creating comprehensive tasks with needed changes it's working about 30 min and created bunch of unneeded and don't described stuff. Some interfaces I am not asked, hundreds of tests and other things that I should fix on the implementation stage. My point - I can work much faster using LLM just as helper with queries like "create such a class with described functionality", finish this small part of work, fix some code if needed and move on. What place of SpecKit in this flow? Is it really needed if I should spend hours to fix plan, tasks and then fix implementation anyway?

[42tg]

I also tried it out yesterday and find it somewhat dissapointing. And I can agree on the general Intuition what @NaikSoftware is already describing. It feels that Claude (wich I used) looses relative fast the overall Picture after starting an Implementation and after nearly an workday of keeping him running all the Time I had to invest alot of time to Pinch it back to create an usable experience.It keeps falling into the TDD trap of concentrating on the test cases and starts iterating on those issues very fast and after a short time it looses the initial todo very fast. Especially on Greenfield Projects (wich my was) It looses to fast track of an certain task, because the initial spec covers the whole application. I have to try this out again on an Brownfield Implementation to experience how this works.

I'm not sure if its related to my incapability to use this framework correctly, wich I must confess can also be true. But to work properly I think there are missing guardrails for Claude to Focus on the certain aspect. Also it keeps failing to update the Tasklist with the work it has done and if there is an new Session Started the Agent is not aware enough of the overall way to work. I think it would be good if the setup script would at least ship with an dedicated claude agent who keeps his context window focused to the task itself. This will of course work only with Claude but in my current point of View it must be more focused on what to do instead of tackling all those Test cases.

But overall thanks for the Idea I would say you are on the right track but we need more Guardrails here wich can be surely clarified trough precise Priming and Context management. 👍

[chrisleyva]

In order to save my Claude Code tokens (I pay for the Pro plan), I use it exclusively for coding and have been using Gemini CLI (2.5-pro) for all my planning/spec work.

I've found that, as awful as Gemini (both Pro & Flash models) has been with coding tasks (often creating code that is incomplete and riddled w/ compile-time errors), it has been an incredibly comprehensive and useful tool during spec work. Once I get it to a point where I'm ready to code, I then use Claude Code to start implementing based on all the specs created with Google. It's been a good workflow up to now.

Yesterday, I used Gemini (gemini-2.5-pro) to spec out a new service-based project (no-code whatsoever) and was blown away by how comprehensive the results were. I first ran specKit without editing my constitution.md file and noticed sub-par results. Then I edited the file and re-ran the /specify command and the difference was significant.

So far, I've had a great experience with this tool and I plan to use it again for another project tomorrow (no pun intended...or was it? 🙂).

[kenny-kim2]

(I'm not a native English speaker, so please excuse any parts that seem like they were put through a translator.)
It might be an issue with the models I used, but they often incorrectly implemented the contents of the tasks.md file. (Claude Code, Sonnet 4) For example, when adding a simple button to a screen, the button text would be different from what was written in the tasks.md file. While I agree with the philosophy of spec-kit and SDD, I feel that the current performance of the models isn't quite sufficient to entrust them with the entirety of the implementation.

[NaikSoftware]

(I'm not a native English speaker, so please excuse any parts that seem like they were put through a translator.) It might be an issue with the models I used, but they often incorrectly implemented the contents of the tasks.md file. (Claude Code, Sonnet 4) For example, when adding a simple button to a screen, the button text would be different from what was written in the tasks.md file. While I agree with the philosophy of spec-kit and SDD, I feel that the current performance of the models isn't quite sufficient to entrust them with the entirety of the implementation.

If you asked raw ChatGPT or Claude to do same thing it will work. But when you put kilobytes of text into context it can randomly fail. More input data = more unpredictable results, in my experience. I added detailed instructions into CLAUDE.md about my project (several months ago, it's wasn't one-day test) and it added certain randomness into daily tasks. Sometimes some instructions takes into account, sometimes no. Then I reduced CLAUDE.md by three times and surprise! It greatly improved stability of work.

[hendrix04]

@NaikSoftware,

Absolutely! The old adage, less is more really holds true when dealing with LLMs.

[amondnet]

@NaikSoftware
Regarding the criticism "SpecKit creates the illusion of work" — I believe this stems from a misunderstanding of spec-driven development (SDD) and agentic coding.

Over the past few years, I’ve successfully delivered 20+ AI-assisted projects, evolving from “vibe coding” toward primarily agentic coding and SDD. Key insights from this journey:

• SpecKit isn’t a brand-new concept — Similar approaches have existed for months. I was already building an internal version before SpecKit’s release.
• Not “illusion of work,” but “redefinition of work” — The balance has shifted from ~80% coding to 50% planning, 20% coding, 30% validation. In an era where AI can generate code rapidly, the developer’s value is increasingly in architectural decisions and clear specifications.
• Context optimization is essential — As projects grow, feeding full context to AI becomes inefficient. Sub-agent patterns with domain-focused context reduced response time in my projects from 45s → 8s and cost from $0.50 → $0.08 per interaction.
• Real results matter — After SpecKit’s release, I resolved real issues in 5 projects in a single day. This was possible because I was already fluent in SDD.

I’d encourage critics to try the difference between vibe coding and agentic coding first-hand. SpecKit is not just another text generator—it’s a framework for systematic development in the AI era. Personally, I’ve been very satisfied with its impact and continue to extend our internal tools based on it.

Change always meets resistance, but what’s clear is that the developer role is evolving: from primarily writing code to orchestrating AI, designing specifications, and ensuring quality. SpecKit reflects that shift.

[amondnet]

For those interested in diving deeper into these concepts:

• https://smcleod.net/2025/06/vibe-coding-vs-agentic-coding/
• https://blog.val.town/vibe-code
• https://aroussi.com/post/spec-driven-ai-development
• https://aroussi.com/post/ccpm-claude-code-project-management
• https://github.com/automazeio/ccpm/blob/main/AGENTS.md
• https://www.aiagentshub.net/blog/claude-code-subagents-researchers-not-coders
• https://www.nathanonn.com/how-a-read-only-sub-agent-saved-my-context-window-and-fixed-my-wordpress-theme/
• https://yozm.wishket.com/magazine/detail/3309/

And the spec-kit approach is quite similar to the best practices of Claude Code:

• https://youtu.be/iF9iV4xponk?si=iSXV3ifbU9DkGjua&t=1165

  • Easy tasks: Tasks that can be handled almost perfectly with a single prompt
    → Tag Claude in a GitHub issue and request a PR
  • Medium tasks: Tasks requiring planning
    → Start in planning mode (Shift+Tab) in the terminal
  • Difficult Tasks: Complex tasks requiring engineer-led execution
    Use Claude as a tool:
    • Research and analyze the codebase
    • Prototype ideas
    • Write code to understand system boundaries
    • Delegate unit test creation

• https://www.anthropic.com/engineering/claude-code-best-practices
  Claude Code doesn’t impose a specific workflow, giving you the flexibility to use it how you want. Within the space this flexibility affords, several successful patterns for effectively using Claude Code have emerged across our community of users:
  a. Explore, plan, code, commit
  This versatile workflow suits many problems:

  1. Ask Claude to read relevant files, images, or URLs, providing either general pointers ("read the file that handles logging") or specific filenames ("read logging.py"), but explicitly tell it not to write any code just yet.
     1. This is the part of the workflow where you should consider strong use of subagents, especially for complex problems. Telling Claude to use subagents to verify details or investigate particular questions it might have, especially early on in a conversation or task, tends to preserve context availability without much downside in terms of lost efficiency.
  2. Ask Claude to make a plan for how to approach a specific problem. We recommend using the word "think" to trigger extended thinking mode, which gives Claude additional computation time to evaluate alternatives more thoroughly. These specific phrases are mapped directly to increasing levels of thinking budget in the system: "think" < "think hard" < "think harder" < "ultrathink." Each level allocates progressively more thinking budget for Claude to use.
     1. If the results of this step seem reasonable, you can have Claude create a document or a GitHub issue with its plan so that you can reset to this spot if the implementation (step 3) isn’t what you want.
  3. Ask Claude to implement its solution in code. This is also a good place to ask it to explicitly verify the reasonableness of its solution as it implements pieces of the solution.
  4. Ask Claude to commit the result and create a pull request. If relevant, this is also a good time to have Claude update any READMEs or changelogs with an explanation of what it just did.

  Steps 1-2 are crucial—without them, Claude tends to jump straight to coding a solution. While sometimes that's what you want, asking Claude to research and plan first significantly improves performance for problems requiring deeper thinking upfront.

  b. Write tests, commit; code, iterate, commit
  This is an Anthropic-favorite workflow for changes that are easily verifiable with unit, integration, or end-to-end tests. Test-driven development (TDD) becomes even more powerful with agentic coding:

  1. Ask Claude to write tests based on expected input/output pairs. Be explicit about the fact that you’re doing test-driven development so that it avoids creating mock implementations, even for functionality that doesn’t exist yet in the codebase.
  2. Tell Claude to run the tests and confirm they fail. Explicitly telling it not to write any implementation code at this stage is often helpful.
  3. Ask Claude to commit the tests when you’re satisfied with them.
  4. Ask Claude to write code that passes the tests, instructing it not to modify the tests. Tell Claude to keep going until all tests pass. It will usually take a few iterations for Claude to write code, run the tests, adjust the code, and run the tests again.
     1. At this stage, it can help to ask it to verify with independent subagents that the implementation isn’t overfitting to the tests
  5. Ask Claude to commit the code once you’re satisfied with the changes.

  Claude performs best when it has a clear target to iterate against—a visual mock, a test case, or another kind of output. By providing expected outputs like tests, Claude can make changes, evaluate results, and incrementally improve until it succeeds.

[NaikSoftware]

@NaikSoftware Regarding the criticism "SpecKit creates the illusion of work" — I believe this stems from a misunderstanding of spec-driven development (SDD) and agentic coding.

Over the past few years, I’ve successfully delivered 20+ AI-assisted projects, evolving from “vibe coding” toward primarily agentic coding and SDD. Key insights from this journey:

• SpecKit isn’t a brand-new concept — Similar approaches have existed for months. I was already building an internal version before SpecKit’s release.
• Not “illusion of work,” but “redefinition of work” — The balance has shifted from ~80% coding to 50% planning, 20% coding, 30% validation. In an era where AI can generate code rapidly, the developer’s value is increasingly in architectural decisions and clear specifications.
• Context optimization is essential — As projects grow, feeding full context to AI becomes inefficient. Sub-agent patterns with domain-focused context reduced response time in my projects from 45s → 8s and cost from $0.50 → $0.08 per interaction.
• Real results matter — After SpecKit’s release, I resolved real issues in 5 projects in a single day. This was possible because I was already fluent in SDD.

I’d encourage critics to try the difference between vibe coding and agentic coding first-hand. SpecKit is not just another text generator—it’s a framework for systematic development in the AI era. Personally, I’ve been very satisfied with its impact and continue to extend our internal tools based on it.

Change always meets resistance, but what’s clear is that the developer role is evolving: from primarily writing code to orchestrating AI, designing specifications, and ensuring quality. SpecKit reflects that shift.

Thank for the sharing you experience. I am just expressing how it works for me. Maybe depends from the project stack/complexity. But on real system with different modules (Flutter, JS, Java, ObjC and communication layer) SpecKit is almost impossible to use in a way that brings benefit. I tried Kiro IDE and BMAD - the same feeling. I spent much more time to implement something. Stuck in hundreds of specs which makes no sense because LLM can randomly ignore some of them.

Simple example: we have a task part of which is this: we should introduce new parameter in json that looks like "param": {"value": 1234}. There are examples in the codebase, I described additionally in the task description. But final results - LLM decided to use "param": 1234 instead of my requirements. I was small part of the whole task so I just approved changes, because described clearly what I need.

As a result a lot of time was spent for writing specs and a lot of time for debugging. Tests can't help because LLM written the test that just pass.

So when you see good looking generated MD files with formatting and emojis it is just text. And LLM operates as text generator in this case 🥲 This creates Illusion of work being done.

[hendrix04]

Wow, this is a great thread with a lot of great information in it.

@NaikSoftware,
I started writing this before your edit, so I will keep my original message but also respond to your example.

As with any new skill, it takes practice and experiecne to get it right. It will take awhile for developers to learn the appropriate skills to interact with AI and AI will evolve and get better over time.

Per your example, this is where experience with managing context comes into play. While you will likely get mitakes like that, the better that you can craft the context, the fewer of those typers of mistakes will pop up. Like with any jr developer, there will be mistakes and sr developers have to be there to catch them.

[NaikSoftware]

@hendrix04 I expect that SpecKit is designed to manage context. But it turns out that you need to know some magic spells so that LLM does not throw away context and does not make mistakes

[NaikSoftware]

Isn't it simpler to just think through simple steps and give them to the LLM directly, without overengineering?