How We Work
Not “we use AI.” An engineering system where AI is a full participant in the process — bounded by our rules, and verified by our own controls — through Spec-Driven Development.
Why this isn’t another AI article
Every other studio today says “we do AI.” The only thing that matters is whether there’s engineering discipline behind it, or just marketing. Here’s how it actually works for us — with specifics, not slogans.
The core: Spec-Driven Development
We build through Spec-Driven Development (SDD). This isn’t a detail — it’s the reason AI gives us predictable results instead of guesswork.
The model never works from a vague “build this feature.” First comes a clear specification that becomes a contract for both the human and the AI:
- Spec first — we define expected behavior before any code is written
- Implementation within the spec — the engineer drives the AI along the contract, not the other way around
- Full test coverage — tests confirm conformance to the spec, not abstract coverage numbers
- Automatic deployment — passes the pipeline → it ships, no manual busywork
- AI verification of the result — a separate verification layer on top of the tests
The point: AI is never left unchecked. Spec on the way in, tests and AI review on the way out. That’s why speed never costs us quality.
A real task, in numbers
To avoid speaking in abstractions. Take a typical feature — integrating a payment provider into a B2B product:
- Before: ~10 working days — ramp-up, implementation, tests, review, fixes
- Now: ~2.5 days at the same level of coverage and quality
- Where the time was saved: ramping up on the API and docs — hours instead of days; initial implementation and tests in parallel; first-pass review — AI catches the obvious before a human does
- What did NOT change: the final call on architecture and edge cases stays with the engineer (the spirit of CTO-as-a-service)
This isn’t “AI did everything.” AI removed the rote work, and our people reinvested that time where they’re irreplaceable.
What practice taught us (not tutorials)
The real value isn’t the tools — it’s knowing their limits. A few lessons that show we genuinely live in this:
- Coverage ≠ test quality. AI will happily generate tests that hit 90% coverage and verify nothing meaningful. We’ve learned to demand behavior- and edge-case tests, not line-chasing.
- More context ≠ better output. Dumping the whole codebase on the model is worse than handing it a precise slice. Curated context wins. At scale, that’s the difference between a working solution and mush.
- AI is confidently wrong. The most dangerous output is plausible-but-incorrect code. That’s exactly why everything goes through spec + tests + verification, not “looks fine → merge.”
The full set of our processes, skills, and templates is our intellectual property. But the depth at which we can talk about it is the proof that it exists.
How we keep quality and security with AI
Speaking directly to what a CTO worries about:
- Code security. Generated code goes through the same reviews and checks as human code — plus a dedicated AI pass for vulnerabilities. AI gets no bypass.
- Client data & IP. We work in environments where client code and data are not used to train models; sensitive projects run under a separate access regime.
- Maintainability. SDD ties code to a specification and tests — anyone on the team can maintain it, not just the original author.
- Hallucination control. Spec + tests + AI verification are three independent filters. A plausible error doesn’t survive to production.
Tooling: the right model for the task
Our approach is pragmatic, not religious. It doesn’t matter which IDE an engineer uses — Cursor, Copilot, Figma AI, and others are all in play. What does matter: on critical work, we don’t cut corners on model quality. We match the model to the context — the strongest where the cost of error is high, and we don’t burn resources where the task is simple.
The team: a standard, not individual chaos
- Documented processes and constraints for working with AI — the same for everyone
- Onboarding and training — new people are brought into the methodology, not left to figure it out alone
- A strong team — knowledge circulates, there’s always someone to ask; the bar doesn’t depend on “getting lucky with an AI enthusiast”
The result
3–5× faster at the same level of quality.
No compromise — the speed came from methodology, not cut corners. Scale, flexibility, security — proven in practice, not in theory. You get a battle-tested system, not an experiment.
Frequently Asked Questions
Spec-Driven Development is an approach where a clear specification is written before any code, becoming a contract for both the engineer and the AI. The model implements within the spec, tests confirm conformance, and a separate AI review verifies the result. It is how we get predictable output from AI instead of guesswork.
Generated code goes through the same reviews and checks as human-written code, plus a dedicated AI pass for vulnerabilities — AI gets no bypass. Combined with the spec and tests, that gives three independent filters, so a plausible-but-wrong change does not reach production.
Not the way we work. Speed comes from methodology, not cut corners. Spec-driven development ties every change to a specification and tests, so any team member can maintain it — not just the original author. Coverage alone is not enough; we demand behaviour and edge-case tests.
The most dangerous output is plausible-but-incorrect code, so we never merge on “looks fine.” Spec, tests, and AI verification act as three independent filters, so a confident-but-wrong result is caught before it ships.
On a typical feature — integrating a payment provider into a B2B product — we went from about 10 working days to roughly 2.5 at the same quality: 3–5× faster overall. The speed came from methodology, not from lowering the bar.
AI is everywhere right now, wrapped in equal parts hype and fear. We’ve skipped both. At Dreambit, AI isn’t a trend we’re chasing or a threat we’re bracing against — it’s a tool we’ve learned to use well, with intention. This is where we stand on responsible AI software development.
AI is a tool, not a shortcut
We don’t use AI to do less thinking. We use it to spend our thinking where it matters.
The boring parts of building software — digging through unfamiliar code, writing the first draft, chasing down a bug, reading documentation — AI handles faster than we ever could alone. That frees our people to focus on the things AI can’t do: judgment, architecture, the hard product decisions, knowing what should be built in the first place.
A tool doesn’t replace the craftsman. It makes a good one faster. That’s exactly how we treat it.
Quality is non-negotiable
Speed means nothing if it costs quality. So we built our process to make sure it never does.
We work spec-first: before anything gets written, we define what “correct” means. Everything is covered by tests that check real behavior, not vanity metrics. AI-generated work passes through the same review — and the same scrutiny — as anything a human writes. Nothing skips the line.
AI is fast, and fast can be dangerous: it produces work that looks right with total confidence. That’s precisely why we never let it run unchecked. A specification on the way in, tests and review on the way out. Confidence is earned, not assumed.
Everyone, not a chosen few
In a lot of companies, “using AI” means one enthusiast in the corner while everyone else watches. Not here.
AI is part of how every engineer, designer, and manager at Dreambit works — every day. We don’t hand off “the AI tasks” to a special team. We’ve made fluency a shared standard, with real onboarding, documented practices, and a team that helps each other level up. The result is consistent, not dependent on who happened to learn the tricks.
We respect the limits
Knowing what a tool can’t do is as important as knowing what it can.
We’ve spent real time learning where AI breaks — where it hallucinates, where it falls apart at scale, where bigger isn’t better. We don’t pretend those limits don’t exist. We design around them. That hard-won understanding is the difference between a flashy demo and software that actually holds up in production.
Honest about what AI is — and isn’t
We won’t tell a client AI is magic, and we won’t pretend it’s useless. Both are lies.
We’ll tell you where it genuinely creates value, and where it would just burn budget. We think being straight about that is the whole point. The companies that win with AI aren’t the loudest — they’re the ones who actually understand it.
Why responsible AI software development is the right way to build
Because we think responsible AI software development is simply the right way to build now.
AI done carelessly produces fragile, insecure, throwaway work — and gives the whole field a bad name. AI done with discipline lets a strong team move faster than ever without giving anything up. We’ve chosen the second path, and we’ve put in the work to walk it properly.
That’s our take. Not hype, not fear — just craft, brought up to speed.
Frequently Asked Questions
We treat AI as a tool, not a shortcut. It handles the repetitive work — exploring unfamiliar code, first drafts, debugging, documentation — while our engineers keep judgment, architecture, and product decisions. Every AI-assisted change is spec-first on the way in, and fully tested and human-reviewed on the way out.
Yes, when it earns it. AI is fast and can look right with total confidence, so we never let it run unchecked. AI-generated work passes the same code review, tests, and scrutiny as anything a human writes. A specification goes in; tests and review come out. Confidence is earned, not assumed.
Not the way we work. Speed means nothing if it costs quality, so our process is built so it never does: spec-first definitions of correct, tests that check real behaviour, and review on every change. Responsible AI software development makes a strong team faster without giving anything up.
No. AI accelerates a good developer; it does not replace one. It cannot do judgment, architecture, the hard product decisions, or know what should be built in the first place. A tool makes a good craftsman faster, and that is exactly how we treat AI-assisted development.
In the repetitive, time-consuming parts: digging through unfamiliar code, writing first drafts, chasing bugs, and reading documentation. Automating those frees our people for the work AI cannot do well. We also respect AI limits, where it hallucinates or fails at scale, and design around them.