I Used GitHub's Spec Kit for 30 Days. Here's the Truth.

Product reviewed

GitHub Spec Kit (Specket / “SpecIt” as mentioned in the subtitles) — a specification-driven development toolkit intended to make “vibe coding” more reliable by generating specs, plans, tasks, and documentation artifacts in a repo, and working with multiple AI coding agents.

Main features / how it works (key points)

• Promotes specification-driven development with a structured cycle:
  1. Specify: define why, what, and how it will be used (functional requirements emerge).
  2. Plan: decide how to build, including tech choices and trade-offs.
  3. Implement: execute task-by-task based on the plan/spec.
• Emphasizes that LLM prompting alone often misses trade-offs and key decisions; Spec Kit captures them via the spec/plan stages.
• Produces repo-native documentation (Markdown) including:
  • decisions
  • research notes
  • functional requirements
  • plans/approaches
  • a “history of reasoning” (as opposed to live coding where reasoning often isn’t recorded)
• Not locked to GitHub Copilot:
  • can work with different agents/tools (Copilot, Cursor, Cloud Code, Gemini mentioned).
• Setup behavior:
  • installation adds configuration/spec-related files into the repo
  • supports linking configuration folders so teammates can share the same specs/process
• Supports both:
  • Greenfield projects (works well starting from scratch)
  • Brownfield projects via a “constitution” file (defines rules the specs must follow)
• Encourages good engineering practices during the process:
  • tends toward test-driven development
  • suggests/uses contract testing
  • embeds best-practice-like workflows

Pros (what the reviewer liked)

• Reduces randomness of vibe coding by forcing trade-offs and decisions to be made during spec/plan stages.
• Agent/tool flexibility: works across multiple code assistants instead of being Copilot-only.
• Artifacts and documentation are valuable:
  • decisions and research become part of PRs and are stored in the repo
  • helps future developers understand why things were built a certain way
• Better quality over pure live coding, feeling “enterprise-grade vibe coding.”
• Improves thinking order: encourages “why/what first, how later” rather than jumping directly into implementation.
• Helps teams/prototypes where not everyone is a domain specialist:
  • can guide discovery of concerns/trade-offs and lead to better solutions
• Works for existing projects at least initially using the “constitution” approach.

Cons / problems (what didn’t work well)

• Too opinionated for teams with established ways of working:
  • may force different artifacts/tests/approaches
  • customization exists but lacks clear guidance (“no predefined way” to adjust)
• Maintenance friction:
  • adapting to a team’s existing workflow can become ongoing work
• “Waterfall at low scale” feeling:
  • similar stages feel heavy compared to agile/live iteration
• Slow feedback cycle:
  • from spec → seeing results takes time; the reviewer felt unproductive waiting
  • risk of forgetting what’s currently running until returning to the spec workflow
• Hard to iterate on wrong specs:
  • if output isn’t defined as expected, going back and adjusting the spec is difficult
  • reviewer often had to roll back and restart, wasting time and “tokens”
• Context/tokens problems (major issue):
  • as projects grow (weeks of work or brownfield), the context window fills quickly
  • generates many documents pulled into context → token burn (reviewer claims they “burned” a Claude Max plan)
  • possible context compaction causes loss of important instructions
  • anecdote: after implementation, no new tests appeared; later a log suggested “run the compaction,” implying important details were summarized away
• Unclear feasibility for small subscriptions/free tiers due to token/context overhead

User experience (day-to-day feel)

• In the first 2–3 weeks, it felt like it transformed vibe coding into something controlled and systematic.
• Later, iteration became harder due to:
  • slow feedback
  • difficulty revising specs
  • context compaction/token limits
• Best experience described for scenarios where:
  • requirements/decisions are unclear
  • you benefit from guided discovery and structured artifacts

Comparisons mentioned

• Pure vibe coding / live coding:
  • live coding often lacks recorded reasoning and trade-offs
  • Spec Kit provides a structured record and enforces decision-making earlier
• “Plan mode” in code assistants:
  • plan mode helps prompts, but Spec Kit goes further by explicitly handling trade-offs and splitting work across phases
• Conceptually to other spec-driven tools/companies:
  • reviewer references AWS Hero (similar philosophy)
  • positions Spec Kit as GitHub’s approach
• Historical context:
  • mentions that spec-driven development (spec → plan → execute) has existed for a long time, suggesting Spec Kit is a modern reapplication for AI-assisted coding

Overall verdict / recommendation (based on the review)

• Not for every project/developer.
• Best sweet spot:
  • smaller/early-stage prototypes
  • projects being handed to a dev team where documentation of decisions matters
  • developers/product folks who may not be domain specialists and need guided trade-off discovery
• Avoid / limited use when:
  • working on large long-running projects requiring massive context
  • you already know exactly what you want and need fast iteration
  • you have limited token budgets or free-tier constraints
• Reviewer’s conclusion after 30 days:
  • they will keep using Spec Kit selectively, mainly for discovery/unclear scenarios
  • they will skip it on large projects where it slows them down

Unique points mentioned (complete list)

1. Spec-driven development as a professional alternative to vibe coding.
2. Root problem: LLM prompting doesn’t reliably capture trade-offs and decisions.
3. Trade-offs include approach/framework/library/requirements/non-functional requirements/edge cases.
4. Plan mode is helpful but insufficient vs full spec→plan structure.
5. Process stages: Specify (why/what/usage) → Plan (how/tech choices/trade-offs) → Implement (tasks).
6. Emerging artifacts: functional requirements, plans, research docs, decisions.
7. Artifacts are stored as Markdown in the repo and committed via PRs.
8. Works with multiple code assistants (Copilot, Cursor, Cloud Code, Gemini).
9. Installation adds configuration/spec files; can link configs across team members.
10. Works for greenfield projects.
11. Works for brownfield projects via constitution rules file.
12. Encourages TDD and contract testing as part of predefined workflow.
13. Feels like “enterprise-grade vibe coding.”
14. Concern: tool can be too opinionated in established teams → maintenance friction.
15. Lack of wizard-style options (e.g., enabling/disabling TDD/contract testing) is a friction point.
16. Might feel like “waterfall at low scale.”
17. Slow spec→results feedback cycle reduces productivity.
18. Spec adjustments can be hard; often requires full rollback and restart.
19. Token/context burn is severe; can hit Claude Max limits.
20. Context compaction may erase important instructions (anecdotally linked to missing tests).
21. Not ideal for small subscriptions/free tools.
22. Suggested target: non-hardcore developers/product folks to quickly prototype and hand off.
23. The reviewer keeps it for certain scenarios but avoids it for large projects where they’re confident and it slows them down.

Different speaker contributions

• Single main speaker (the narrator/reviewer) covering all phases: motivation, features, 30-day experience, pros/cons, and final recommendation.