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 (Poor architecture, Tight coupling, Hard-to-change systems).

we can now create unmaintainable systems faster than ever.

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. Define specifications
2. Generate a plan
3. Break into tasks
4. 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
• Scaffold the code projects needed
• Break down into small specs
• Iterate gradually
• 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 25+ 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.

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.
❌ 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
• Verify they fail
• Then implement

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

5. Specifications Need Maintenance

Specs can:

• Drift
• Become outdated
• Conflict with code

✅ Treat specs as first-class artifacts

• Mark: draft / active / superseded
• Archive old ones

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

I delayed CI and testing.

Big mistake.

✅ 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

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

✅ Use SpecKit to improve thinking, not just generate code

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
• Requires discipline of the individual and team
• A lot of Markdown files are created, which can be overwhelming to review
• Costs (tokens, time)
• Spec maintenance overhead

Big Open Questions

These are still unresolved:

• Is code or spec the ultimate source of truth?
• Will specs become obsolete as AI improves?
• Can specs and code stay in sync at scale?
• Are we re-learning lessons from Waterfall?

Key Takeaways

• AI amplifies both good and bad engineering
• Specification-Driven Development introduces intentionality
• Structure matters more than ever
• Think before prompting
• Matt Pocock’s skills from AIHero are very helpful as an alternative or supplemental to SpecKit.

My Session Slides

👉 [Add PowerPoint link here]

Final Thoughts

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

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

References

• SpecKit (GitHub)
• 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
• 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

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:

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