Where an AI feature enters your SDLC and where it breaks it

A VP of engineering at an enterprise software company told me they made a deliberate, reasonable decision that caused them months of trouble. When they started building AI features, they chose to run them through the same software development lifecycle they used for everything else. Same planning, same branches, same review, same testing, same deploy, same monitoring. The logic was sound, a consistent process is a strength. And for most of the lifecycle it worked fine. The problem was that an AI feature does not move through a few specific stages the way normal software does, and those few stages were exactly where the process quietly failed, without anyone noticing until the failures piled up.

Most of the lifecycle fits, and a few stages do not

There is a temptation to treat AI features as either completely normal or completely different, and both are wrong. An AI feature is written, reviewed, deployed, and operated like other software, and forcing an entirely separate process for it would be wasteful and confusing. Most of your existing lifecycle applies, and it should.

But a handful of stages carry assumptions that AI features violate, and running them unchanged through those stages is where things break. Testing assumes deterministic output, so the testing stage produces brittle checks or false confidence for a feature whose output legitimately varies. Deployment assumes behavior lives in code, so the deploy stage does not track the prompt and model changes that actually drive the feature’s behavior. Monitoring assumes failures are outages, so the monitoring stage watches uptime and misses quality degradation. Review assumes the author understands the code, which frays when an agent wrote it. None of these stages announce that they are failing. The feature moves through them, looks like it passed, and the assumption that quietly did not hold shows up later as an incident that traces back to a stage everyone thought was fine.

This is why the trouble is so hard to diagnose. The process is not obviously broken, it is the same process that works for everything else, and it works for most of this feature too. The failures are localized to specific stages where a hidden assumption breaks, and because the rest of the lifecycle is fine, nobody suspects the process. They suspect the feature, or the model, or the team, when the real issue is a couple of lifecycle stages carrying assumptions that AI features do not honor.

Adapt the stages that break, keep the ones that work

The lesson is to keep your lifecycle and adapt the specific stages where AI features break its assumptions, rather than either forcing them through unchanged or inventing a whole separate process. The work is surgical, a few stages, not a rebuild.

The stages that need adapting for AI features.

Testing, where deterministic assertions fail a feature whose output varies, so testing shifts to properties and graded evaluation.
Review, where the assumption that the author understands the code frays with agent-written changes, so review adds an intent check.
Deployment, where behavior lives in prompts and model versions, not just code, so the deploy stage has to track and roll back those too.
Monitoring, where failures are quality declines rather than outages, so monitoring adds a quality signal alongside uptime.
Definition of done, where a feature that varies and can degrade is not done at first passing output, so the bar includes evaluation and operability.

Everything else in your lifecycle can stay. Find the few stages where the assumptions break, adapt those, and you get the consistency of a shared process without the failures that come from ignoring where AI is different.

How we approach it at Density Labs

The team that runs AI features through an unchanged lifecycle is the common case, and it is a defensible starting point. The trouble is that the failures are concentrated in a few stages and invisible everywhere else, so the process looks fine while a couple of its stages quietly mislead the team about a feature that does not obey their assumptions.

Our AI Opportunity Assessment is a fixed two-week engagement, priced at $2,500, that scopes the real work of shipping an AI feature. Part of that is mapping where the feature moves through your lifecycle differently, so you adapt the handful of stages that break and keep the rest of your process intact.

You do not need a new lifecycle for AI features. You need to find the few stages where your current one is quietly lying to you.