Using SpecKit and Specification-Driven Development to Tame AI Coding at NE Code 2026

✅ Presented at Nebraska.Code() 2026
📅 July 23, 2026
🎤 Session: Using SpecKit and Specification-Driven Development to Tame AI Coding

Introduction

AI is changing how we write software. According to DORA’s 2025 report, 95% of developers are now using AI in some capacity. Over the last year, we’ve been having a lot of conversations at work and I’ve been thinking a lot about how to use AI effectively in software development.

AI can generate a lot of working code quickly, it’s really impressive — but just as quickly, it can generate, a ball of mud (Unmaintainable systems with Poor architecture, Tight coupling, Hard-to-change systems).

SpecKit appeared on my radar and the idea of Specification-Driven Development (SDD) with BDD, ATD was renewed as a way to guide AI coding and use Engineering practices to produce better systems. Back in 2014, I was intrigued by Specification By Example where Mr. Adzic described technique to have the tests written in the BDD style (Given, When, Then) and then generate code from the tests. SpecKit seems to make this approach possible using AI.

The Problem: Vague Inputs → Unpredictable Systems

We’ve always struggled translating ideas into code:

“That’s not quite what I meant…”
“Now that I see it, can we change this?”

Even with Agile, BDD, and DDD:

• Documentation drifts and becomes outdated
• Intent is lost in translation
• Developers need to take time looking through the code to understand actual behaviors

With AI, this gets amplified:

• Faster iteration = faster divergence
• Prompts alone lack structure
• Systems degrade quickly

What is Specification-Driven Development?

“Spec-Driven Development (SDD) is a software engineering paradigm where AI agents generate and test code based on unambiguous, machine-readable specifications, rather than developers writing code manually. It shifts the development bottleneck from manual coding to planning, architecture, and writing clear executable contracts” ~ Source: https://www.gartner.com/en/documents/7492453

Hypothesis

Specification-Driven Development can guide AI to produce better, more maintainable systems than prompt-only approaches.

Competing Hypothesis

Code is the only source of truth. AI can generate and reverse-engineer everything else.

What is SpecKit?

SpecKit is an open-source toolkit that enforces a structured workflow of Specification → Plan → Tasks → Implement.

Instead of Vibe Coding, you use the provided skills and scripts to:

1. Be an Engineer and think
2. Define specifications
3. Generate a plan
4. Break into tasks
5. Implement with guardrails (like TDD (test-driven development), architecture rules, git commits, work tickets, and CI/CD)

This encourages intentional thinking and evaluation before code generation.

My Experiment

I built a Bike Commuter Tracking app using SpecKit + Copilot over a few months using the companies extra Copilot tokens. My source code with git commit history is available for reference.

Approach

• Start with the constitution, architecture, scaffolding and constraints
  • Scaffold the code projects needed
• Break down into small specs
• Iterate and learn
• Measure:
  • Tokens
  • Time
  • Adaptability
  • Understandability

Key Observations

• I like the flow of SpecKit.
• the /speckit.analyze command asked good questions and pointed out cases I hadn’t thought of.
• Setting up the constitution to enforce TDD, then stop and have me review the tests before implementation was a good approach.
• I was running this on the side, so didn’t pay as much attention to the planning and Markdown output as I would have if it was my main focus.
• I have 27+ specs and overall it wrote a good app with good structure.
• There were times it broke things, but then it was able to fix it. I would have it write tests when that happen.
  • my installable app with Tauri still isn’t working.

Workflow

I believe this Bike Commuter Tracking app has sufficient functionality and complexity to show that SpecKit holds up to expansion and change. As of this writing, I have 27 completed specs that can be viewed in the spec/ folder .

Look at the Core Commands in the documentation as they have good examples. I also have added links to videos and articles at the bottom of this article.

Constitution Prompt

My constitition changed during the course of this project as I built and learned more about what I wanted to build. You don’t have to know everything up front, but you should have a good idea. Don’t let the AI make all the decisions for you.

I highly suggest to use Matt Pocock’s Agents.md prompt to split up the constitution.

I started with this prompt, but later used Copilot to improve it.

If you have an existing project, you can use AI to create the constitution from the already existing code.

My Starting Point

Follow principles focused on code quality, testing standards, user experience consistency, and performance requirements following Clean Architecture, Functional Programming (pure and impure function sandwich, use Results instead of Exceptions, avoid using Exceptions), Event Sourcing and Domain Driven Development ideas to create high scalable, quality applications

Suggest tests, but ask for my input before creating tests. 

Focus on creating a working vertical slice of functionality for each specification. We value working software after running /speckit.implementation task. Create end-to-end user flow UI tests using Playwright code and MCP when a end-to-end user flow is complete. 

Use the MCP tools for MS Learn (for information), GitHub (source control and actions), Azure MCP for gathering information. Use the Playwright MCP. Suggest other  MCP tools to use and record those in this constitution. Prompt me for permission to use these. If you are unsure, use a web search and MS Learn to make sure your information is up to date.  

We will use the latest Aspire orchestration, latest C# features, C# with .Net 10 Minimal API for the API backend. Make sure we have the latest NuGet packages and ask to update when you see any out of date. Do not add any packages with my permission. Use F# for domain logic, C# for common Api infrastructure/detail code.

Microsoft Blazor .Net 10 for the front end (with responsive design and and simple UX. The user will login with an OAUTH identity (look up information in MS Learn https://learn.microsoft.com/en-us/aspnet/core/blazor/security/?view=aspnetcore-10). The user will have access to only their data and publicly available (use the latest Blazor FluentUI v4.13.2 https://www.fluentui-blazor.net/, componentize with "Design Tokens", create a DesignTheme using these colors for a palette "FFCDA4, FFB170, FF7400, D96200, A74C00" to follow our branding)).  

Validate all data in the front and back end using the Microsoft DataAnnotationsAttributes https://learn.microsoft.com/en-us/aspnet/core/blazor/forms/validation?view=aspnetcore-10.0&preserve-view=true

The database will be an Azure SQL database. We will use the new SDK style database project to handle all database changes. Use the latest Entity Framework Core. Following Event Sourcing, create tables to store each event. Current projections will be created in a background Azure Function listening for Change Event Streaming Events (CES) and stored in a different read only table.

Prefix any sample data with SAMPLE_. Prefix any dummy/demo data with DEMO_. Ask before creating data.

The application will be hosted in Azure.  With Aspire, host the application in Azure Container Apps. Use Managed Identity. All secrets must be in the Azure Key Vault.

DevOps: Pipelines will be for GitHub Actions using the Aspire and `azd` tooling to deploy. Create templates actions for easier reuse.

Git: Always commit before continuing to a new phase.

I’m not sure if this was too much for a prompt or not, but it’s a solid start

I also removed Event Sourcing later, changed to React (LLMs are trained on a lot more for React than Blazor).

Walk through Spec 004-create-the-record-ride-mvp

I have 27 specs as of writing this.

/speckit.specify task

“Create the record ride page. The user needs to enter the day and time (default to now), how many miles they rode (default to last inserted). Optional time to ride in minutes (default to last inserted) and temp (default to last inserted). This needs to be persisted to the database as an event”

This is an example of the output from Copilot CLI through the process of using SpecKit of a later spec. I’m using Caveman — the token-efficient stack for agent-native builders to reduce token usage. It cost about 10% of my tokens when I ran it on July 9th, 2026.

Model changed from claude-sonnet-5 (medium) to Auto

/caveman use /speckit.specify the mileage rate is recorded in the settings by the user as cents per mile. In the existing savings stats, it needs to show the total saved so miles * mileage rate. This allows the user to see both the miles saved base on gallons of gas and the mileage rate for wear and tear a company might pay

Thought for 2s

skill(caveman) 

Thought for 6s

Speckit.specify(claude-sonnet-4.6) Specify mileage rate savings feature
Edit feature.json +1 -1
Create requirements.md +37

Spec done.  specs/027-mileage-rate-savings/spec.md  created.

Key decisions:

• Rate stored in settings as cents per mile (integer)
• Mileage savings =  total miles * rate  → shown in existing savings dashboard
• Live recalc (rate change updates all history) — distinct from per-ride gas snapshot
• Separate stat from gas savings, both displayed

Run  /speckit.plan  next to generate implementation plan.
/caveman run /speckit.plan
Thought for 1s

skill(caveman) 

Speckit.plan(claude-sonnet-4.6) Plan mileage rate savings feature
Edit copilot-instructions.md +1 -1
Shell Verify all artifacts created 22 lines…
ls -la /workspaces/neCodeBikeTracking/specs/027-mileage-rate-savings/ echo "---" ls -la /workspaces/neCodeBikeTracking/specs/027-mileage-rate-savings/contracts/ echo "---" grep "SPECKIT" /workspaces/neCodeBikeTracking/.github/copilot-instructions.md -A2

Plan done. Key finding: mostly already implemented.

One prod code change needed in  GetAdvancedDashboardService.BuildWindow()  — switch from per-ride snapshot to live  UserSettings.MileageRateCents .

Also:

• 5 existing tests need  UserSettings.MileageRateCents  in DB setup
• 2 new unit tests
• 1 new E2E spec

Run  /speckit.tasks  to generate task list, or  /speckit.implement  to execute directly.
/caveman run /speckit.tasks
skill(caveman) 

Thought for 5s

Speckit.tasks(claude-sonnet-4.6) Generate tasks for mileage rate savings
Read constitution.md 42 lines read
Create tasks.md +233

Tasks generated.  specs/027-mileage-rate-savings/tasks.md  — 19 tasks.

Critical path: T004→T005 (write failing tests) → T006 (confirm red) → T007 (fix  BuildWindow() ) → T008–T014 (fix 5 existing tests + verify green) → T015–T016 (E2E).

Run  /speckit.implement  to execute, or work tasks manually.
/caveman /speckit.implement
Thought for 1s

skill(caveman) 

Thought for 9s

Speckit.implement(claude-sonnet-4.6) Implement mileage rate savings feature
└ Agent started in background with agent_id: speckit-implement. You'll be notif...

Running in background. Agent executing 19 tasks — TDD cycle,  BuildWindow()  fix, test repairs, E2E spec. Will notify when done.

Background agent "Implement mileage rate savings feature" (speckit.implement) completed.

Read (Speckit.implement agent — Implement mileage rate savings feature)
└ idle

Done. All 19 tasks green.

Running in background. Agent executing 19 tasks — TDD cycle, `BuildWindow()` fix, test repairs, E2E spec. Will notify when done.
Done. All 19 tasks green.

**Summary:**
- `GetAdvancedDashboardService.BuildWindow()` → live `UserSettings.MileageRateCents` (dropped per-ride snapshot)
- 7 unit tests fixed/added → 20/20 dashboard tests, 423/423 backend
- New E2E `mileage-savings.spec.ts` → 3/3 scenarios
- `playwright.config.ts` fix for devcontainer Roslyn lock

Run `/speckit.git.commit` to commit, or review diffs first.

Usage

This is the /session info from Copilot CLI

Changes +1552 -31 AI Credits 629 (5h 10m 22s) (I left the window open a long time, it only really ran for 30 minutes or so, but I wasn’t watching it) Tokens ↑ 11.5m (11.0m cached, 445.8k written) • ↓ 89.0k (25.9k reasoning)

/speckit.plan

“Create technical implementation plans with your chosen tech stack” ~ https://github.com/github/spec-kit#core-commands

I figure the constitution knows what technology I want to use, so I didn’t always spell it out here in the later specs. Sometimes I just used /speckit.plan and let it go. Other times it could be very helpful to define here, but then add it to the constitution.

Example: “Plan the record ride page using the spec. Follow the constitution and use the existing scaffolded projects with .Net for the API and React for the front end.”

/speckit.tasks

Break the work down into tasks.

This is where it will also specify the TDD process and the order of tasks. It will plan out what tasks can be done in parallel.

/speckit.analyze

Check that the spec, plan and tasks are all consistent. It will flag issues before implemenation.

/speckit.implement

Run it and wait. The AI will create all the tests and code. It will run the tests and then fix them as well.

This is a modern version of get back to work, but my code is compiling excuse .

Implementation Side Note

In April, 2026 I asked Copilot before implemention:

how long would you estimate spec 015 would take in human hours if human engineers coded it?

Based on the 81 tasks I generated, here's my estimate for **experienced engineers** working in the existing BikeTracking codebase:

## **Time Breakdown by Phase**

|Phase|Focus|Hours|
|---|---|---|
|**Phase 1**|Setup|1.5–2.5|
|**Phase 2**|Foundational (F#, EF Core, Receipt Storage)|6–8.5|
|**Phase 3**|US1: Record Expense (MVP)|5–8|
|**Phase 4**|US2: View/Edit History|7–10.5|
|**Phase 5**|US3: Dashboard|2.5–3.5|
|**Phase 6**|US4: Oil-Change Savings|1.25–3|
|**Phase 7**|Polish|3.25–7|

## **Total Estimates**

- **Core Feature (71 tasks)**: **26–42 hours**
- **Full Feature + E2E (81 tasks)**: **30–45 hours**

## **Practical Delivery Timeline**

|Scope|1 Dev|2 Devs (Parallel)|
|---|---|---|
|**MVP** (Phases 1–3)|1 week|3–4 days|
|**Full Feature** (Phases 1–7)|1.5–2 weeks|5–7 days|

## **Key Factors Affecting Estimates**

**Lower bound (26–30 hrs)** assumes:

- Deep familiarity with BikeTracking architecture
- Swift TDD red-green cycles
- No debugging surprises
- Receipt storage & EF Core migrations go smoothly

**Higher bound (40–45 hrs)** assumes:

- Learning curve on codebase patterns
- More thorough testing/validation
- Debugging receipt file handling edge cases
- Comprehensive E2E test coverage

**Realistic middle (33–38 hrs)**: One experienced .NET/React developer familiar with this codebase, full-time, completing the feature end-to-end with quality.

---

**Parallelization opportunity**: Backend and frontend streams can work independently after Phase 2 completes, potentially cutting total time by ~30% with 2 devs.

Analysis outside of the SpecKit workflow can be helpful

It’s good to ask different models to check on architecture, design, code quality, security, test quality, performance, etc.

Here’s one example that I captured:

### Analyze for Consistency
## Remediation Summary

**Total Findings**: 13 (4 CRITICAL + 6 MEDIUM + 3 LOW)

**Recommended Fixes** (Priority Order):

1. **A1**: Fix US2 scenario numbering (5 min)
2. **A3**: Add security test tasks (30 min; 3 new tasks)
3. **A4 + L1**: Expand T072 error handling details (15 min)
4. **M1**: Clarify oil-change savings language in FR-015 (10 min)
5. **Constitution IV**: Add [CONFIRM RED TESTS] markers to 6 key tasks (10 min)
6. **M2**: Update "receipt image" → "receipt attachment" (5 min)
7. **M5 + L2**: Add 2 documentation tasks (15 min)

**Estimated Time to Remediate**: ~90 minutes total (mostly clarifications and task additions).

---

## Overall Assessment

✅ **READY FOR IMPLEMENTATION** with minor clarifications.

**Strengths**:

- Solid architecture alignment with Constitution (all 10 principles satisfied)
- Comprehensive requirement coverage (95% of FRs mapped)
- Well-organized 7-phase delivery with clear dependencies
- TDD structure enforced throughout
- Parallelization opportunities identified

**Areas to Strengthen**:

- Add explicit security test tasks (currently implicit in integration tests)
- Clarify error handling and edge case recovery strategies
- Fix terminology imprecisions (receipt "image" vs. "attachment")
- Add documentation/backup strategy tasks for user-facing guidance

**Recommendation**: Implement the 7 remediations above (90 min), then proceed with Phase 1 setup. Security tests (A3) should block Phase 3 completion.

I like Tests

I’ve talked about Automated tests for a long time . My constitution defined needing to follow TDD and has hooks to stop on red tests then wait for my input (though this seems to be ignore when running in Copilot CLI, it was working through the VS Code UI at one point). The AI agents have done a good job creating tests, with good quality and coverage at all levels of the testing pyramid.

Checkout a recent CI build :

I have C# and F# unit test, Vitests and E2E tests running.

I asked Copilot Cli /caveman give me a report of all my automated tests (a table with # of tests, how long they take to run and what level of the testing pyramid they are at. Calculate a confidence score of correctness and ready to deploy based on the automated tests

Confidence score (correctness): 92/100. Reason: all layers green, big backend + unit volume, meaningful E2E coverage.

Ready-to-deploy score: 88/100. Reason: release-safety high from full green pyramid; minus for 2 skipped DB-constraint tests (provider limitation) + no explicit perf/load/security gate in this report.

Lessons Learned

1. Think Before You Prompt

“I thought of this as it was running…”

That costs tokens and rework.

✅ Lesson: Spend time in the Specify phase, review output before continuing, use /speckit.analyze after creating tasks.
❌ Don’t rush (“slow is smooth and fast is slow”).

2. Small Specs Win

Large specs:

• Increase token usage
• Increase error surface
• Increase ambiguity

✅ Use small, focused vertical slices

3. TDD Doesn’t Happen Automatically

Even with a “constitution” requiring TDD:

• AI skipped red-green cycles
• I had to enforce it explicitly

✅ Add clear TDD gates:

• Write failing tests first
• Human in the loop to review tests, AI will verify they fail
• Then implement and make the tests pass

Don’t forget the refactor phase.

4. Architecture Still Matters (A Lot)

AI does not guarantee good structure.

I had to enforce:

• Clean Architecture
• Ports & Adapters
• Separation of concerns
• Modular design

✅ Add architecture rules to your constitution ✅ Read Why Care About Agent Authored Code Quality

5. Specifications Need Maintenance

Specs can:

• Drift
• Become outdated
• Conflict with code

✅ Treat specs as first-class artifacts

• Mark: draft / active / superseded

This isn’t covered well in the documentation and I didn’t spend of time trying this in my project. Use AI to help you maintain the specs, where it can identify conflicts.

The most recent spec would be the most accurate, but having AI read the old then building that picture would take a lot of tokens. Perhaps there should be a /speckit.reconcile command to build the latest view of the whole system.

Consider looking into the spec-kit-reconcile and spec-kit-archive extensions mentioned in this discussion . There were various approaches mentioned in another discussion including having a master spec (using spec-kit-reconcile) or have a spec reference the other spec that it changes the behavior of.

🧪 You will have to experiment and figure out what works best for you.

6. CI/CD Early (Don’t Wait)

Don’t delay CI and testing.

✅ Set up:

• GitHub Actions early
• Test pipelines
• E2E validation gates

7. AI Needs Guardrails

Without constraints, AI:

• Makes assumptions
• Introduces bugs
• Violates architectural intent

✅ Guardrail examples:

• TDD enforcement
• Required validations
• Migration checks
• E2E completion criteria on PRs

8. Parallel Development is Possible

SpecKit can:

• Identify independent tasks
• Generate orchestration scripts
• Enable parallel work

This aligns with:

• Modern Software Engineering (Dave Farley)
• Modular team design

9. Costs Matter (Tokens + Time)

Spec-driven workflows:

• Require more steps
• Use more requests

Tradeoff:

• ✅ Better structure
• ❌ Higher cost

✅ Mitigation:

• Think before prompting
• Use smaller specs
• Research outside the coding model

10. AI is a Thinking Partner, Not a Replacement

Best value came from:

• Asking questions
• Challenging assumptions
• Highlighting edge cases
• Experimenting with prototypes

✅ Use SpecKit to improve thinking, analyze for missing details and find inconsistencies, not just generate code

11. Use Other Skills and Ideas to Augment SpecKit

Learn from Matt Pocock’s approach to skills from AIHero and use them. These could be a great alternative to SpecKit.

I’ve been using /caveman to reduce token usage by making it less verbose.

I tried out the msec:farley-score to analyze the tests and it had some good recommentations that I implemented via AI. I got a Farley Index: 8.48 / 10.0 (Excellent) on BikeCommuteTracker with all tests written by AI.

Burke Holland has a good 10 AI coding tips that actually work video .

Pros and Cons

✅ Pros

• Encourages good engineering practices
• Separates the design from the implementation
• Resumable workflows (by humans or AI by continuing a last spec)
• more visible work (though I’d want tickets/issues in GitHub/Jira to show it better than just the Markdown output)
• Better structured systems
• Built-in documentation
  • we can look back at the decisions for each spec

❌ Cons

• Mindset shift required
• Slower initially than Vibe Coding (but should be better in the long run)
• Requires discipline of the individual and team
• A lot of Markdown files are created, which can be overwhelming to review and maintain
• Costs (tokens, time) could be higher than Vibe Coding

Big Open Questions

These are still unresolved:

• Is code or spec the ultimate source of truth?
• Can specs and code stay in sync at scale?
• Are we re-learning lessons from Waterfall (or does this keep us in small spec feedback loops)?
• Is SpecKit the right tool for your current team and project?
• Are SpecKit alternatives better for you? Check out OpenSpec, Kiro or Matt Pocock’s skills from AIHero?

Key Takeaways

• AI amplifies both good and bad engineering
• Specification-Driven Development introduces intentionality
• Structure matters more than ever
• SpecKit is a good tool for the process and guiding AI
• Think before prompting and running
• Matt Pocock’s skills from AIHero are very helpful as an alternative or supplemental to SpecKit.
• Always keep learning about foundational principles of software engineering and architecture. Always keep learning about tools and techniques to use.

My Session PowerPoint

👉 My PowerPoint that you can download

Final Thoughts

We don’t want to become “vibe coders.”
We want to remain engineers.

SpecKit isn’t just a tool — it’s a tool and process to slow down thinking so we can speed up delivery.

References

• SpecKit (GitHub) and speckit.org
• Quick Start Guide
• Microsoft Spec-Driven Development Blog
• ThoughtWorks on Spec-Driven Development:
  • Spec-Driven Development: Unpacking 2025 New Engineering Practices
  • Spec-Driven Development
• Deep Dive into SpecKit
• SpecKit Tutorials
• Burke Holland SpecKit Videos
• What’s The Deal With GitHub Spec Kit
• SpecKit intro with workflow graphic
• Workflow Graphic I used in the PowerPoint
• SpecKit Parallel AI Agent Teams
• SpecKit Fleet
• GitHub Issue debate on the source of truth
• Spec-driven development with Spec-Kit is eating my tokens alive. What actually works?
• OpenSpec uses less tokens?
• SpecKit Token usage is high report
• Don Syme F# creator’s take
  • “TLDR: The supremacy of Code is King is being challenged, but the jury is out on where spec-centric programming will be viable”

Other Related Articles and Videos

• DORA 2025 State of DevOps Report
• Agentic Engineering (Addy Osmani)
• Intent-Driven Development
• Amazon Tightens Code Controls After Outages
• Why Care About Agent Authored Code Quality
• Is Spec Kit the future for software development - Johan Smarius - NDC Copenhagen 2026
  • quoted: Gartner: Spec-Driven Development
• Code Reviews
  • argues specifications won’t help alignment, but “intent-driven development” capturing the micro-decisions as you iterate with the AI is better.
  • “intent-driven development” is something I want to explore more. I agree that we have to iterate quickly and LLMs help us do that well.
• Matt Pocock’s skills from AIHero: https://www.aihero.dev/skills have been very helpful and I’ve learned a lot from him. I suggest you follow him
  • Tracer Bullets - honorable mention
• 10 AI Coding Tips That Actually Work by Burke Holland - great tips
• Headroom for less token usage?

My Past NE Code Presentations

Thank you to NE Code for another opportunity to present and be a part of the community. Here are my past presentations at NE Code:

• 2017: From JavaScipt Mess to Cleaner Code
• 2019: Getting Started with Unit Testing
• 2023: Clean Architecture

AI Usage Disclaimer: I did use AI to generate the outline from a lot of notes I took over the last couple of months (you can probably tell from the icons). However, I did go through and rewrite and refine most of it.

Thank you for reading and if you made it to my NE Code presentation I hope you found it useful.