AI SDLC: How Spec-Driven Development Helps AltexSoft Deliver Up to 10x Faster

Becoming an AI-first company has helped AltexSoft accelerate delivery by 6-10 times on some projects, reducing feature time to market from months to days. Achieving that required changing how we work, including a major redesign of our software development lifecycle.

In an AI-enabled SDLC, AI supports work throughout planning, design, development, testing, deployment, and maintenance rather than being limited to code completion. Here, we share what we’ve learned from rebuilding our delivery process around AI and the results we’ve achieved so far.

What is AI SDLC: 5 stages of AI maturity

So how is AI SDLC different from a traditional one? The core phases stay recognizable, but the way work moves between them changes completely.

Under AI SDLC, AI moves beyond code completion and chat assistants into every stage of delivery. However, people still define the requirements, make architectural decisions, manage risk, and approve the final result.  

Also, while code remains critical, it’s no longer the key artifact. Alexey Taranets, a Solution Architect at AltexSoft, is very clear that “the specification becomes the asset the whole project is measured against; code becomes something generated from it rather than the thing itself.”

There is no universally accepted AI SDLC maturity model yet. Based on what we have observed across our teams and projects, we use five stages to describe the transition.

1. Traditional – humans do everything; no AI in the loop.
2. AI-supported – basic copilots or chat assistance for code completion.
3. AI-assisted – AI is formally applied to defined tasks such as planning, code generation, test creation, documentation, or code review; governance and repeatable practices begin to emerge, but the underlying delivery process remains largely unchanged.
4. AI-native – AI stops being an external tool and becomes the foundation the process is built around. Every phase of the lifecycle is designed with AI at the center; agents handle the heavy lifting while humans direct architecture and business outcomes.
5. AI-autonomous – AI agents operate independently, proposing, merging, and even rolling back code, with humans acting as strategic gatekeepers rather than implementers.

A large part of the market is currently at stage 3, using AI for specific tasks, but not redesigning the core workflow around it yet. Most of our teams are already pushing into stage 4. Stage 5 is a very high bar and requires a level of trust in autonomous decision-making that isn't realistic right now.

But moving to AI-first requires a lot of effort. Why do we need it at all?

Why the shift to AI SDLC is essential

As vibecoding took over the dev world, people began to believe that a complex system could be built overnight. It can’t, but that narrative has already shaped market expectations.

New market expectations

Alexey explained why this shift is becoming unavoidable: “The market is moving fast: clients now expect smaller teams, faster delivery, and meaningfully lower cost, and some competitors are already quoting half the budget for the same scope.”

Most teams were early to add some AI to their process, like a coding assistant here, AI-generated tests there. On individual tasks, such as writing code in a greenfield environment with no legacy complications, performance gains were impressive, reaching 7x.

But the overall delivery gains were more modest, i.e., around 15-20 percent improvement. That's good to have, but not enough anymore.

One reason for that was using AI… wrong.

Using AI wrong: Bolting on, not building in

Alexey reflects that “we were adding AI to a process designed entirely around human execution.”

Developers who are comfortable delegating implementation to AI tend to do it through chat-based, single-prompt patterns – and those patterns don't hold up at project scale. Prompts do not provide the essential project context. Even a simple feature depends on architecture, data flow, edge cases, security rules, and prior decisions that never make it into the prompt.

When that context is missing, AI starts to guess, and the guess can look plausible while missing the actual requirement.

Alexey described a common failure pattern: “A task that would normally take one to two days gets 'solved' in a few hours, the review turns up problems, and instead of stepping back to provide better context, the developer keeps patching it in the same chat session – correcting corrections until the AI starts hallucinating unrelated changes. At that point, the time saved is gone, replaced by manual correction and a burned token budget.”

So just giving a Copilot to each team member won’t cut it. Now, when coding is the easiest part, the bottlenecks just move upstream (to understanding requirements and planning architecture), and downstream (to reviews and validation).

As Ihor Pavlenko, Director of AI Practice at AltexSoft, shared, “We realized that to achieve significant delivery acceleration, we must actually build AI into the process rather than bolt it on.”

So what are the actual changes that lead to AI-native delivery?

The key changes

AI-native delivery requires teams to address the bottlenecks surrounding code generation. In our experience, that means redesigning three closely connected workflows: specs, QA, and review.

Specifications become the source of truth

Our engineers are increasingly moving toward specification-driven development (SDD). The concept is simple: you have to slow down upfront to speed up later.

A specification should capture the expected behavior, business rules, constraints, dependencies, acceptance criteria, and relevant edge cases. It then becomes the shared source from which AI can produce plans, code, tests, and documentation.

This also changes how teams evaluate work. A human-verified specification becomes the contract against which implementation is generated and validated. When the requirement changes, the specification should change first.

It’s worth noting, though, that SDD is not always faster task by task. Arkadii Hetmantsev, Solution Architect at AltexSoft, gave an example: “In one internal demo, a simple password generator took 20-30 minutes through direct AI chat, but 2-3 hours through a full specification, execution, and verification workflow. The trade-off was greater upfront effort for a more stable, production-ready result with less risk of later rework.”

Choosing how to write and manage those specs is a decision in itself, and we'll cover the main frameworks later in this piece. But the rule that holds across every framework we've tested is: make the intent explicit first, then let the AI execute.

A spec alone isn't the whole picture, though. It tells an agent what to build, but not how the existing system works or what a change might affect. Without that context, even a strong spec can lead to rework.

That is why we built Interlace, our codebase-intelligence product. It maps code structure, dependencies, and data flows into a knowledge graph that agents can query before implementation. This is especially useful for large enterprise systems, where no single specification can provide enough context for an agent to work safely.

Testing moves left

Once a team can generate features and releases faster, the queue backs up at QA, and manual review becomes the new ceiling on delivery speed.

The fix is to involve QA earlier. Instead of looking for bugs after development is “done,” QA specialists, business analysts, developers, and product owners must define acceptance criteria, risk scenarios, and expected behavior before implementation begins. These requirements should be precise enough to support automated test generation and deterministic validation.

Automated review, CI/CD gates, and AI self-testing loops (agents that write a test, run it, and fix their own failures before a human reviews anything) become the actual judge of quality.

Review becomes a gate, not a phase

The same logic applies to code review. When code can be generated extremely fast, it's just as easy to lose architectural control, and review overload becomes real. So review has to become an automated gate integrated into the workflow rather than a manual phase at the end of it.

Spec-driven development tools

The spec-driven development frameworks we tested fall into two categories.

Full-lifecycle frameworks like BMAD and GSD manage the entire project, including requirements, epics, architecture, development, and testing, from a single continuous context.  

Delta-spec frameworks like OpenSpec, GitHub Spec Kit, and Superpowers don't try to hold the whole project; they scope a specification to the next change only, whether that's a feature or a bug fix.

Note that this comparison reflects our own hands-on experience testing these frameworks across internal and client projects. Ratings are directional, not benchmarked scores.

BMAD

BMAD is the most rigorous framework we’ve used. It covers the full process from requirements and architecture to epics, stories, implementation, and review. Rather than maintaining one continuous context, it passes structured artifacts between specialist agents and fresh sessions.

That rigor also makes BMAD the most token-intensive option we've seen, requiring a dedicated usage budget rather than a basic subscription. Alexey is very direct about it: “It eats tokens like there's no tomorrow. If you think a standard $50 Cursor subscription or $20 ChatGPT plan will be enough – forget it, you'll hit your limits almost immediately. To actually extract the maximum value out of BMAD, you need a pro or max subscription, or be prepared to allocate a dedicated AI budget of $50 a day or $1,000 a month, minimum.”

However, he also suggests a middle ground: “That's a premium cost, but if you don't have that budget, don't skip BMAD completely. There's a hybrid option: Use BMAD during elaboration and design to create a highly detailed specification, then hand that specification over to a lighter framework for actual development.”

GSD

GSD also covers the full development cycle but focuses more heavily on context engineering. It stores requirements, plans, decisions, and project state in repository files, while assigning tasks to agents with fresh context windows. This helps prevent “context rot” during long projects.

In our experience, GSD consumes fewer tokens than BMAD, although more of the validation burden remains with the team.

OpenSpec

OpenSpec is a lighter option for teams that understand their codebase and primarily need a reliable specification for the next change. Each feature or fix gets its own proposal, requirements, design, and task list. Once completed, the change updates the main specification and is moved to an archive, preserving its history.

This was the right fit for the operations platform we mentioned earlier. A solo architect built an 80-operation simulator covering roughly two-thirds of the platform in about a month. A backend engineer then used OpenSpec to deploy the approved logic to production about 4 times faster than with the traditional approach, helping the team meet a 5-week licensing deadline.

GitHub Spec Kit

GitHub Spec Kit provides a more structured, feature-oriented workflow. Its constitution defines the project’s non-negotiable principles, while subsequent stages cover specification, clarification, planning, task breakdown, implementation, and verification. This is particularly helpful when team members have uneven knowledge of the architecture or engineering rules.

Superpowers

Superpowers is the strictest option during implementation. It combines design refinement, planning, subagent execution, reviews, and test-driven development. Its central rule is uncompromising: no production code before a failing test. Code written first must be deleted and recreated from the test. That discipline is valuable when reliability matters more than speed, but excessive for rapid prototypes.

As we mentioned, a hybrid approach is possible: for example, using BMAD for design and a lighter tool for implementation. The drawback is that their tracking systems do not synchronize automatically. Once implementation moves elsewhere, the original framework may no longer know what has actually been built. So in practice, we recommend choosing one primary framework and using it throughout the project.

The key challenges of AI SDLC adoption

None of this is a clean rollout, and pretending otherwise would undercut the argument for doing it. In our experience, four challenges consistently require attention.

Mindset

Resistance, particularly among experienced engineers, is a common issue. Many of them still don’t fully trust AI, while others struggle with the shift from writing code themselves to defining specifications and reviewing AI-generated work.  

And partial adoption creates a sync problem. If one team on a project uses spec-driven development and another doesn't, or someone bypasses the process to hand-code a quick fix, the artifacts stop reflecting reality. Arkadii admits that we don't have a clean answer for this yet, beyond re-running the codebase mapping step to catch up.

The opposite risk is just as real and, in some ways, harder to catch: some staff swing from distrust to overreliance, merging AI-generated code without genuinely reviewing it because it's fast and it compiles.

Ihor Pavlenko notes that this change-management challenge can be more difficult than deploying the tools themselves. Teams need time to learn to use the tools properly and to develop confidence in a different way of working, while retaining healthy skepticism.

Skills

Ihor also explained that “Writing a specification precise enough for an AI to build correctly from is not something most teams have practiced. Non-tech team members need real training to write specs that agents can build from directly.”

The tools and models also change rapidly. Teams therefore need continuous learning, shared internal guidance, and regular updates to their working practices.

Governance and control

AI agents may access source code, project documentation, internal systems, command-line tools, and production-like environments. In our case, even launching a few internal bots required us to reconfigure permissions, rewrite services, and introduce more granular role-based access in our systems.

As Ihor explains, “If an AI bot has wide permissions and someone gains access to it, it could expose sensitive information across delivery.”

That’s when governance becomes critical. Organizations need clear rules defining which models and providers teams may use, what data can leave the company environment, which repositories agents can access, and which actions require human approval.

They also need audit trails, secret-management policies, permission boundaries, deterministic quality gates, and safeguards against agents making unintended changes outside the scope of a task.

Budget

A stage 3 budget (the $20-50 monthly subscription most teams already have) works fine when AI is helping generate drafts, and you're still leading the specification and development. It does not work for stage 4.

Getting real AI-native throughput on a single feature realistically costs about $50 in AI spend per day. Parallelize with git worktrees to run two or three features at once, and that budget multiplies directly: instead of $50 a day, you're looking at roughly $200 for four features in flight.

We saw teams on baseline $20 subscriptions easily burn through token equivalents of $1,500+ without realizing it. If a team is serious about reaching stage 4, the AI budget conversation has to happen before the framework conversation, not after.

Our key lessons learned

Here are some lessons we’ve learned on our AI adoption journey.

The gains are real, but they're not evenly distributed. Some of our results are a 4x improvement, some are reaching 10x. Quoting a single number for how much faster AI SDLC makes you would be the kind of overclaim we'd push back on if someone else made it.

The range depends heavily on the project stage, how well-scoped the spec is, and how well the team has adapted to the new process.

Context is the biggest constraint. The teams getting the most out of this are the ones who've gotten disciplined about capturing architecture, edge cases, and business rules in the spec before any code gets generated. Skipping that step is the single most common way we've seen teams turn a potential time-saving into a longer, more expensive rework cycle.

The ownership model must change. Ihor described an internal pilot where moving from two-week sprints to daily delivery quickly created confusion. The existing model assumed that one person owned the specification while the rest of the team worked from a stable version.

But when a business analyst, architect, and designer were all updating it in real time, the spec stopped aligning the team and began creating conflicts instead. The solution was to assign ownership by delivery stage, e.g., prototype, production build, or release, rather than by job title, with one clearly designated spec owner at each stage.

Budget policy needs to be part of the rollout plan, not an afterthought. Teams that treated AI spend as a fixed, small line item hit a wall the moment they tried to move past stage 3.

We're still mid-journey on most of this ourselves. Some of our teams are further along than others, and the honest answer to "have we fully solved this" is no; but the direction, and the economics behind it, aren't really optional anymore.