Turning Client-Led Vibe Coding Into a Governed AI SDLC Process for a Legacy Retail Operations Platform

The biggest saving comes from reducing delivery effort per feature. AI doesn’t simply replace developer hours one for one.

In this project, that gap worked out to about 81% less delivery effort by person-months: three developers and eight months against a traditional estimate of seven specialists and 18 months.

The actual dollar savings depend on your rates and team structure, but the comparison shows where the economics come from: a smaller team, a shorter timeline, and less implementation work per feature.

Potentially, yes. For a SaaS product, shipping requested features faster can reduce churn and close gaps that are currently blocking new deals.

The size of the effect depends on the client’s actual churn, expansion, and win-loss data. For a legacy platform, the effect we usually see is fewer stalled deals and a shorter backlog of blocking requests, more than a single clean revenue jump.

We would look at more than developer productivity. The useful metrics are delivery time, engineering effort, cost per feature, churn, NRR, feature adoption, new deals won, and revenue previously lost because required functionality was missing.

For a legacy SaaS product, the strongest business case usually comes from combining two effects: lower delivery cost and faster revenue impact from getting the right features into customers’ hands sooner.

Potentially, yes, but only if the remaining engineers can cover a broader technical scope and the AI SDLC process is mature enough to support them. AI can take over a significant share of implementation work, but it also shifts more responsibility onto developers: they need to define specifications clearly, keep project context current, set guardrails, make architectural decisions, and work confidently across parts of the stack they may not know deeply.

That is where the trade-off appears. A smaller AI SDLC team can work, but only if you have engineers with enough breadth to judge unfamiliar code, prevent unnecessary technologies from creeping into the stack, and keep architecture and specifications aligned as AI moves faster.

For MobiDev’s legacy retail software client, our Solutions Architect, Yevhen Kuzminov, compared the actual AI SDLC delivery with a traditional team estimate:

Around 3 Ruby developers working with AI agents delivered the last 8 months of work. Based on his experience, the same scope would traditionally have required roughly 7 people (2 Ruby, 2 TypeScript/React, 2 Golang, and 1 BA) and at least 18 months.

That reduction comes with prerequisites. Developers need broader technical judgment, the ability to create and maintain specifications, enough architectural understanding to set guardrails even in an unfamiliar language or framework, and discipline around stack consistency. Without that, AI can easily introduce new technologies where the existing stack would have been enough, because there is less upfront discussion and planning than in a traditional team.

For a product owner, vibe coding can feel like a pure act of creation: an idea moves almost directly from their head into the product. The prototype itself becomes the specification. Instead of going through BA → requirements → design → Figma → development → feature, they can sketch the equivalent of a back-of-the-napkin idea and see it working almost immediately.

That speed is exactly why product owners are often willing to sacrifice things they cannot see right away: scalability, maintainability, clean architecture, documentation, extension points, testing, CI/CD, and sometimes even systematic functional validation. The problem starts when a prototype that was meant to prove an idea quietly becomes production software. Code may be rewritten heavily every few days, documentation never catches up, review becomes almost meaningless, and testing gets pushed onto whoever has to integrate or use the service.

The main risks we see are:

Low code quality and maintainability. AI can keep rewriting large parts of the implementation, making the codebase difficult to stabilize, understand, and maintain.

Missing documentation. Service documentation, architecture notes, and integration instructions are often incomplete or absent, leaving important knowledge inside prompts or individual sessions.

No reliable engineering safeguards. Tests, linters, CI/CD pipelines, and automated quality gates may never be established because the focus stays on getting the next version working.

Testing gets pushed downstream. Without systematic functional testing, defects are often discovered by the people integrating or using the service rather than during development.

Code review becomes almost impossible. If AI rewrites a large share of the code every few days, engineers cannot meaningfully review changes, track architectural decisions, or recommend improvements before the implementation changes again.

AI SDLC addresses this by putting context, documentation, testing, validation, review rules, and change boundaries around AI-generated development. The goal is to keep the speed of AI without allowing constant code generation to undermine the engineering foundation of the product.

Our AI SDLC approach lets that act of creation keep going. We add just enough structure to keep it moving without letting it stall. That sometimes means accepting that imperfect code will exist for a while, then adding the right engineering supports at the right moment: context, tests, documentation, architectural boundaries, CI/CD, review, and refactoring when the idea is ready to move toward production.

Overengineer too early and you kill the momentum that made vibe coding worth trying. Ignore it too long and experimental code becomes the production foundation by accident.

It depends on your current development process, team size, legacy complexity, AI experience, security requirements, and how much of the lifecycle you want to cover. In most cases, the transition takes around 6-12 months, moving from basic rules and shared context to team-wide AI SDLC practices and deeper automation.

For a mature legacy product, the process usually takes longer than for a greenfield project because AI needs more context, tighter boundaries, and stronger validation before it can safely take on more of the development workflow.

We implement AI SDLC gradually rather than introducing a new AI tool and expecting the team to change overnight. On this project, the transition took about a year and moved through five stages, from occasional AI use to AI SDLC becoming part of the development lifecycle.

Stage 1. AI Is Allowed, but AI SDLC Is Not Yet a Process. The client had approved AI use, but the team was still using it ad hoc. There were no maintained AI context files, no shared project context, no agreed primary tool or fallback, and no clear definition of which development tasks should involve AI. The first step was to establish the rules of the game before increasing AI usage.

Stage 2. Build the AI SDLC Foundation. We agreed on approved tools, accounts, data restrictions, fallback options, and basic working rules. We also introduced the first persistent project context so AI had access to the product, stack, common commands, and development conventions instead of relying entirely on individual prompts.

Stage 3. Apply AI SDLC to Real Development Tasks. AI SDLC then became part of daily delivery. Before generating code, engineers defined the task scope, expected outcome, constraints, and acceptance criteria. AI-assisted changes went through builds, tests, linting, and code review, with stricter boundaries for legacy workflows than for new functionality.

Stage 4. Make AI SDLC a Team Practice. The next step was consistency across the team. AI configurations, task specific context, prompts, review practices, and successful patterns became shared project assets instead of personal developer habits. Context was updated together with architectural decisions, and reusable knowledge from complex tasks remained available for the next engineer.

Stage 5. Integrate AI SDLC Across the Lifecycle. At the most advanced stage, AI SDLC extended beyond code generation into planning, testing, review, documentation, and maintenance. Repeatable checks and lower risk decisions could be automated, while engineers remained responsible for architecture, security sensitive areas, complex business logic, and changes with a high impact on the legacy system.

For legacy software, we increase AI autonomy only as fast as context, verification, and team practices mature enough to support it, not as fast as the tooling allows.

MobiDev starts by separating experimentation from production development. The team agrees which AI tools and accounts are allowed, what project data can be exposed to them, and which types of changes can be generated with AI. Client- or developer-generated code then enters the normal engineering flow through defined branches, review, testing, and production gates rather than being treated as production-ready because it works locally.

That is what we did on this project. The product owner could keep using AI to turn ideas into working changes, but MobiDev added the engineering layer around those changes: project context, architectural constraints, acceptance criteria, automated checks, and human approval for higher-risk areas.

The same idea applies to agentic engineering generally: what separates it from vibe coding is the structure, verification, and human judgment around the model’s output, not the model itself.

Standardizing every prompt isn’t realistic. What we standardize instead is the engineering context and rules AI works against.

At a minimum, that means agreeing on a primary AI tool and fallback, then maintaining shared project artifacts such as CLAUDE.md, AGENTS.md, .cursorrules, or copilot-instructions.md. Those files describe the stack, conventions, architectural boundaries, prohibited approaches, common commands, and other rules AI should not have to rediscover on every task.

For more complex work, we add task-specific context: the affected module, dependencies, expected behavior, change boundaries, and acceptance criteria. At higher AI SDLC maturity, those context files are versioned with the codebase, updated when architecture changes, and complemented by reusable prompts, playbooks, and task-specific context packs.

That was particularly important on this client’s platform because several engineers and the product owner were all experimenting with AI. The goal was to prevent each person from effectively working with a different version of the system in their AI context.

Google’s framework describes the same shift from prompt engineering to context engineering, including architecture, conventions, memory, examples, tools, and guardrails, and recommends treating the static/dynamic context boundary as an engineering decision rather than an ad hoc prompting choice.

You cannot solve that by asking senior engineers to review more pull requests faster. AI SDLC has to move part of the verification before human review.

In MobiDev’s approach, the task is framed first: scope, expected result, constraints, and acceptance criteria. AI-assisted changes then go through an agreed minimum set of checks such as build validation, linting, automated tests, regression tests, and AI-assisted first-pass code review. Tests are created alongside the implementation rather than being postponed until the end.

Human review is then applied according to risk. Routine changes that pass deterministic checks require less manual attention, while engineers spend more time on business logic, architecture, security-sensitive code, ambiguous requirements, and changes that touch several legacy dependencies.

For more advanced AI SDLC setups, evaluation can cover both the output and the agent’s execution path. The Google paper distinguishes final-artifact checks from trajectory evaluation and also describes AI as a first-pass reviewer before human review.

That distinction matters because AI implementation can accelerate much faster than human judgment. The paper notes that implementation may compress from weeks to hours while architecture and verification remain human-paced, which is exactly how review becomes the next bottleneck if the process is not redesigned.

A legacy product needs a different AI SDLC flow from a greenfield MVP.

For new development, AI can often work from a specification and generate a relatively large part of the initial structure. In a brownfield system, the main risk is that the AI produces code that is technically valid but conflicts with an existing dependency, business rule, integration, or architectural decision that is not obvious from the files being changed.

MobiDev gives AI two layers of context here too: the same persistent context described above, plus task-specific detail. We answer questions like: which module can change, which dependencies matter, what must stay untouched, and what counts as done.

We also limit autonomy according to the area being changed. A new isolated module may allow broader AI generation. A critical legacy workflow may require narrower task decomposition, more human checkpoints, stronger regression coverage, and explicit code review before each step moves forward.

On this seven-year-old retail platform, that distinction was essential. The real teaching wasn’t about how to write code. It was about how this particular product works and where AI is allowed to change it.

This matches the broader agentic-engineering view: legacy systems can benefit from AI, but only with specifications, tests, and guardrails around the generation process.

AI SDLC works with whatever AI tool the team already uses [name primary tool/fallback used on this project]. The persistent project context is what actually carries the stack-specific knowledge: CLAUDE.md, AGENTS.md, .cursorrules, or equivalent.

A failed build, test, or lint check sends the change back to the developer before it reaches human review. Failures touching legacy business logic, security, or architecture escalate to a senior engineer for manual review. How fast something escalates depends on how close it sits to core legacy workflows.

We treat it as a scope conversation. If a guardrail blocks something genuinely needed, we look at whether the constraint should change. Where the guardrail exists for real risk, such as security or data integrity, we lay out the trade-off in business terms and let the client decide with the risk stated plainly.