Our Approach

The engineering practices at Digital Speed have evolved over the years. But one thing that hasn’t changed is our focus on writing high quality, maintainable code. And since the advent of AI and vibe coding, it’s become far more important to ensure clean and maintainable code is being written.

What is vibe coding I hear you say? Below is a quote directly from Merriam Webster:

"Vibe coding is a recently-coined term for the practice of writing code, making web pages, or creating apps, by just telling an AI program what you want, and letting it create the product for you. In vibe coding the coder does not need to understand how or why the code works, and often will have to accept that a certain number of bugs and glitches will be present."

Vibe coding is inherently risky because, unless there’s a significant amount of time invested in reviewing the AI-generated code, it’s very likely to introduce issues. Not only that, but the code is harder to maintain and the transfer of knowledge is challenging at best. For those reasons, our team only used AI to write tedious refactors or edit inline code segments, as opposed to vibe coding full features. But times are changing.

This is where GitHub’s Spec Kit comes in. This is an open-source tool that allows any developer to swap vibe coding with Spec-Driven Development (SDD). Now why is this better than vibe coding? It’s because it forces everyone in a team to establish shared context before any implementation begins, which means AI agents and teams build exactly what was intended. By separating intent from code, we can avoid the chaos of assumptions and ensure every decision is explicit, reviewable, and easier to evolve. Dive into more detail about SDD in this blog post by Den Delimarsky, Principal Product Engineer at Microsoft’s CoreAI division.

This fantastic tool is a game-changer. And it makes sense. We have learned a lot after building many products for our clients over the years here at Digital Speed. There’s an industry best-practice behind every successful product launch, and it starts with creating detailed specification documents. This is what Spec Kit was designed to do.

Spec-Driven Development with Spec Kit is a feature-based approach to writing code, and it all starts with generating detailed documentation. The core concept is to produce enough accurate detail about intent so that the AI has the contextual foundation to build the feature correctly. The idea is to produce a set of files based on pre-determined commands. Those files are generated as markdown files. It’s important they’re generated in the following order as each prior step gives context to the next:

• Constitution: defines the project constitutional guardrails. These are the non-negotiable principles that must be adhered to at all times.
• Specification: build a specification document and requirements checklist based on your prompt.
• Clarify: asks 3 to 5 clarification questions on the spec to help prevent ambiguities.
• Plan: create a technical plan for the specification.
• Tasks: break down the technical plan and the spec into a set of individual tasks.
• Analyse: analyses the spec, plan, and task breakdown for any inconsistencies.
• Checklist: create “unit tests for English” for your specification, enabling you to quickly find blind spots in your domain thinking.
• Implement: implement the project based on all of the combined artefacts.

Clarify, Analyse and Checklist are intermediary commands we can run between each doc generation step which helps us to clarify, analyse and update the generated artefacts. This is outlined in the diagram referenced above.

Ultimately, you end up with a directory structure like this, alongside the rest of the files and directories for your project, in your codebase:

.specify
memory
constitution.md
scripts
bash
check-prerequisites.sh
common.sh
create-new-feature.sh
setup-plan.sh
update-agent-context.sh
templates
agent-file-template.md
checklist-template.md
plan-template.md
spec-template.md
tasks-template.md
specs
001-example-feature-one/
002-example-feature-two/

And within the individual feature directories (which by the way, are also the name of the feature branch you are now working on - all executed because of Spec Kit) shown in the specs directory above, you’ll have your generated files which typically look like this:

specs
001-example-feature-one/
checklists
requirements.md
contracts
example.md
data-model.md
plan.md
quickstart.md
research.md
spec.md
tasks.md

The final step is to run the implement command and let the LLM go to work implementing the tasks created in the tasks.md file. But before that, we get our AI Agent of choice, we use Claude Code at Digital Speed, to use GitHub’s CLI tool to create a Pull Request from our current branch 001-example-feature-one to main with a detailed description, to make sure that the effort is properly tracked and our entire team can view the spec documentation before implementation.

Once implemented, we’re able to release this feature branch 001-example-feature-one onto our CI/CD pipeline to QA the results, and we’ve been having astounding results thus far.

If you are looking to bring spec-driven development to life in your own organisation, our engineering team can help you move from idea to production with clarity, pace and confidence. Reach out to us and explore how we can accelerate your next build or check out our services to find out more.