Implementing AI in the SDLC

Most teams adopt AI in one place: the editor. An engineer installs a coding assistant, autocomplete gets smarter, and leadership declares the organization "AI-enabled." That's not implementing AI in the SDLC — that's implementing AI in one developer's keyboard.

The real leverage shows up when you treat the software development lifecycle as a pipeline and ask, at every stage: where does work queue up, and can a model shrink the queue? After running AI-assisted delivery on commerce implementations for the past couple of years, here's where I've seen it actually pay for itself — and where it doesn't.

Requirements and discovery

This is the most underrated phase for AI, because the raw material is language, and language is what models are best at. Discovery calls, RFP responses, legacy documentation, support tickets — all of it can be distilled into draft user stories, open questions, and risk registers before a human ever formats a backlog.

The discipline that matters: AI drafts, humans decide. A model will happily produce forty plausible user stories from a transcript, including several the client never asked for. The output is a starting point for a conversation with the stakeholder, not a signed scope document.

Design and architecture

Architecture is where I trust AI the least on final answers and value it the most as a sparring partner. Asking a model to argue against your proposed design — "what breaks at 10x traffic, what does the integration team hate about this, where does this couple us to the vendor" — surfaces objections in minutes that would otherwise arrive in a design review two weeks later.

Two practices make this stick. First, write architecture decision records and keep them in the repo — they become context that agents and new engineers both consume. Second, never let a model pick between platforms or vendors unsupervised. It will confidently recommend whichever option is best represented in its training data, which is not the same as best for your contract.

Implementation

The headline shift here isn't autocomplete — it's agentic workflows. The unit of delegation moves from "complete this line" to "implement this ticket, run the tests, and show me the diff." That changes what the engineer's job is: less typing, more specifying, reviewing, and correcting.

• Invest in your repo's context files. An agent that knows your conventions, your directory layout, and your deployment quirks produces code that looks like your team wrote it. One that doesn't produces plausible code that fails review for a hundred small reasons.
• Keep tasks small and verifiable. Agents excel at well-scoped tickets with a clear definition of done and fail expensively on "refactor the checkout."
• Make the agent prove its work. "Tests pass" is table stakes; require it to exercise the change end-to-end where possible.

Code review and QA

AI review and human review catch different things, and you want both. Models are tireless at the mechanical layer — null paths, missing error handling, inconsistent naming, the N+1 query nobody noticed. Humans remain better at "this is technically correct but solves the wrong problem." Run AI review first so human reviewers spend their attention on intent, not on nits.

On the QA side, test generation is the quiet win. Legacy modules that nobody wanted to write tests for can get meaningful coverage in an afternoon. The trap is coverage theater: a model will cheerfully generate tests that assert the code does whatever the code currently does, bugs included. Review generated tests for what they assert, not just for whether they pass.

Deployment and maintenance

Post-launch is where AI compounds. Release-note drafting, log triage, incident summaries, "explain this stack trace against this diff" — each one is a small saving that recurs every week, forever. For long-lived commerce platforms, the maintenance phase dwarfs the build phase, so a 20% saving here outweighs a 40% saving during implementation.

What actually determines success

None of this is a tooling problem anymore. The teams that get real gains have three things in common: they picked specific stages to attack rather than boiling the ocean, they wrote down their conventions so both humans and agents could follow them, and they measured cycle time before and after so they knew — rather than felt — that it was working.

AI doesn't replace your SDLC. It compresses every stage of it — and exposes any stage that was already broken.

If your requirements were vague before AI, you'll now build the wrong thing faster. Fix the process, then accelerate it.