The AI Lifecycle

A Solution to the Chaos AI Teams are Feeling Right Now

I have a secret to share: most AI teams are in chaos right now, across many industries. I’ve seen it first hand, heard it from other AI leaders, and read stories online. In the article below I outline what I see as the common path that leads to this chaos, how different actors can avert this chaos, and propose an AI Lifecycle (AILC) framework. I believe, if adopted, that the AILC can help your organization successfully form and execute an AI strategy.

The Path to Chaos

Here’s the typical sequence of events that turns the flow turbulent

1. Company growth slows because of high interest rates.
2. The board sees AI as the best hope of accelerating growth (or of surviving at all)
3. The board pressures the C-suite to define a grandiose AI strategy and execute it at lightning speed. But they have no capital to invest in more resources (because growth slowed).
4. Pressure lands on product and engineering leaders who are understaffed and have little experience with AI.
5. AI features are treated like software features. Product defines requirements that are implemented by engineers. But because AI is non-deterministic and hard to validate, the feature doesn’t work as planned.
6. AI features are delivered in one of 3 ways:
   1. on-time and on-budget with low quality and low customer value
   2. delayed and over-budget with acceptable quality and real customer value
   3. never (but at great cost)
7. Customers either lose trust and churn, or lose patience and, again, churn.
8. The board sees growth stall even more. It either applies more pressure (and the cycle continues) or gives up and does layoffs.
9. Meanwhile, data science and ML teams already know how to handle non-deterministic systems and could have broken this vicious cycle. But too often they are misunderstood by leaders and either under-invested in or asked to operate like engineering teams.

How to Avert Chaos

There’s a lot to unpack here. But let’s look at the most important intervention points in this process where specific participants can take action to break the cycle.

1. For board members and the C-suite:
   1. The first thing to realize is that your competitors are all bluffing. Every marketing team claims to have a magic, agentic solution that revolutionizes the industry. The truth is, they don’t. It’s a facade. A vision. A dream. But not a reality. Not now and probably not soon.
   2. You have more time than you think you do to release AI features. If your competitors beat you to it, it’s probably because they took shortcuts. Some gullible customers may defect in the short term, but in the long term they will see through your competitor’s facade. And if you take your time to ship a proper solution that actually meets their needs, they will be back.
   3. Very few managers have figured out how to manage the lifecycle of AI projects. And very few doers have learned all the new techniques required to execute on AI projects. This is why I know your competitors are bluffing. And this is why it’s wise to invest in both new talent and skill development. If there’s no budget for more people, either increase training or rebalance the org to have more of the right skills.
   4. The AI lifecycle differs from the software development lifecycle (SDLC). It requires research before implementation. If your company doesn’t have a research function yet, now’s a great time to start one. And if you want to be an AI-first company, consider making a big investment in your research team.
2. For product, engineering, and research teams:
   1. LLMs and agents are so new that no one has as much knowledge and experience with it as they would like, especially relative to their seniority level. For example, a VP with 15 years work experience only has at best 1-2 years experience with AI. A staff engineer with 8 years work experience only has at best 1-2 years experience with AI…You get the point.
   2. So everyone needs to be learning as much as possible as fast as possible. This is an opportunity for junior-level folks with a learning mindset to catch up to senior-level folks who might be stuck in their ways.
   3. But that creates power struggles, contributes to impostor syndrome, and drives a host of other negative outcomes. And the high pressure from leaders to deliver exacerbates the problem and drives team dynamics to the brink.
   4. Team leads and first-time managers are in an especially precarious position. At this level, many lead by being the smartest person in the room. Their power comes from knowledge. But their knowledge advantage erodes quickly with AI (old knowledge is less valuable, junior team members spend more time hands-on-keyboard learning the latest techniques). But these young managers have the opportunity to mature into the mindset of leading as the dumbest person in the room, which in my opinion is necessary to reach the level of director, vp, and beyond. Young managers also have the option to delay this transition and stay hands-on-keyboard. During this critical moment where the way work is done is shifting under our feet, it’s not a bad option. I personally made that decision 2 years ago to stay hands on keyboard so I could stay on the technical edge of emerging AI techniques. This gave me a strong foundation to now shift back towards a focus on management and leadership.
   5. Last but not least, to deliver a successful AI project, it needs to be decomposed into phases of the AI lifecycle (see below). My hope is that the more people that learn about the AILC, the more likely that someone will raise the red flag when AI projects begin following the traditional SDLC instead of the AILC.

AI Lifecycle

Now I will introduce my sketch for an AI Lifecycle framework that is informed by my AI and ML experience across 10 years and 5 companies. Then I will provide an AI-generated report (lightly edited) that compares this framework to existing frameworks and highlights its main insights.

Here are the high-level steps of the AI Lifecycle (AILC).

1. Problem identification
2. Exploration of solution space (research) (early exit possible)
3. Prototyping and proof of concept for chosen solution, with evals complete (research) (early exit possible)
4. Decision on whether it’s worth implementing given expected customer value and technical complexity (early exit possible)
5. SDLC ensues (product defines requirements, engineering implements)
6. Evals and iteration owned by research team, with observability and implementation of enhancements owned by engineering

Now I’ll let AI take over to put this framework in context and flesh out some details. I have reviewed these AI outputs and give them my stamp of approval.

The rest of this article is an AI-generated report, so I will sign off here with one final thought: I truly believe that the dynamics between board pressure and AI implementation challenges are a powder keg. If you feel this too, I hope you will share your story. If the industry can collectively recognize the problems, it can collectively find solutions.

AI-Generated Report: Comparing the AI Lifecycle to Other Frameworks

What you are calling the AI Lifecycle is not only legitimate — it is already implicitly recognized by the most mature ML organizations — but it is rarely made explicit, and almost never enforced at the board / product / engineering boundary. That gap is exactly why the chaos you describe exists.

Below I will do three things, in order:
1. Show that versions of this lifecycle already exist (but are fragmented, under-named, or misapplied)
2. Extract the common structure across those prior frameworks
3. Propose a clean, opinionated AI Lifecycle (AILC) that fits your article and directly explains why SDLC-first thinking fails

This will let you say, credibly: “This isn’t my opinion — this is what the industry’s most mature AI builders already do, even if they don’t talk about it this way.”

⸻

1. Have others proposed an AI lifecycle before?

Yes — but never as a first-class alternative to SDLC, which is the critical insight in your article.

A. Google / Production ML literature (implicit lifecycle)

Google’s production ML papers (Sculley et al., Breck et al.) repeatedly emphasize that:
• You cannot specify correct behavior up front
• You must validate models empirically
• Many projects should be killed early

They describe:
• Data validation
• Offline evaluation
• Online experimentation
• Monitoring and retraining loops

But they frame this as “production readiness”, not as a gating lifecycle before SDLC.

This is the root problem: organizations read these papers and still push AI work directly into engineering pipelines.

Citations: Google’s “ML Test Score” and “Hidden Technical Debt in ML Systems”

⸻

B. Thoughtworks / Continuous Delivery for ML (CD4ML)

Thoughtworks and Martin Fowler propose CD4ML, which clearly separates:
• Experimental model development
• Evaluation and reproducibility
• Productionization

However:
• CD4ML is written for practitioners
• It assumes the organization already accepts ML as different
• It does not explicitly warn boards and product leaders that most ideas should die before engineering starts

Your article does something CD4ML does not: it explains why forcing ML into SDLC creates systemic failure.

⸻

C. Academic research on ML-enabled product development

Multiple empirical studies (Nahar et al., Shankar et al.) explicitly state:

Product requirements cannot be established without early model prototyping and experimentation.

This is crucial: requirements emerge from research, not the other way around.

But again:
• This insight lives in academic papers
• It has not crossed into executive or product leadership doctrine

⸻

D. MLOps frameworks (Databricks, Google, etc.)

Most MLOps diagrams look like:
• Train → Validate → Deploy → Monitor → Retrain

These are post-decision frameworks.
They assume:
• The problem is valid
• The approach is feasible
• The value proposition is known

Your article is about what happens before that — where most failures actually occur.

⸻

2. The missing insight across all prior art

Every mature framework agrees on one thing — but fails to say it loudly:

AI work is a discovery process before it is a delivery process.

Your article’s contribution is naming the consequences when organizations ignore that truth:
• Invalid roadmaps
• Fake commitments
• Quality vs. speed false tradeoffs
• Burned teams and churned customers

What is missing in existing frameworks is:
• A clear early-exit philosophy
• A hard boundary between research and SDLC
• Ownership clarity for who decides whether an AI idea deserves engineering investment

That is exactly what your AILC should formalize.

⸻

3. A clear, defensible AI Lifecycle (AILC)

Below is a refined version of your lifecycle, tuned to be:
• Intellectually defensible
• Easy to visualize
• Explicitly contrasted with SDLC

You can present this as “The AI Lifecycle (AILC)” and position it as a prerequisite to SDLC, not a variant of it.

⸻

The AI Lifecycle (AILC)

Phase 1: Problem Identification (Product-led, Research-informed)

Goal: Identify a customer or business problem that might be amenable to AI.

Key characteristics:
• Framed in terms of outcomes, not features
• No commitment to AI as the solution yet
• Explicit acknowledgment of uncertainty

Failure mode this avoids:

“We promised an AI feature before we knew if AI could solve the problem.”

Early exit criteria:
• Problem is not meaningfully improved by probabilistic systems
• Deterministic or rules-based solutions are sufficient

⸻

Phase 2: Solution Space Exploration (Research)

Goal: Explore whether AI can solve the problem, and how.

Activities:
• Model / prompt class exploration
• Data availability and quality assessment
• Latency / cost / accuracy tradeoff discovery
• Failure mode enumeration

Outputs:
• Feasible approaches
• Known limitations
• Initial performance ceilings

Ownership: Research / Data Science

Early exit criteria:
• Performance ceiling too low
• Costs too high
• Risks unacceptable

This phase is where most AI projects should die.

⸻

Phase 3: Prototyping & Proof of Concept (Research)

Goal: Prove the best candidate solution works under controlled conditions.

Activities:
• Prototype implementation
• Offline evals
• Human-in-the-loop validation
• Error analysis

Critical rule:

No roadmap commitments without completed evals.

Outputs:
• Quantified performance metrics
• Known failure modes
• Confidence intervals, not guarantees

Ownership: Research

Early exit criteria:
• Marginal improvement over baseline
• Inconsistent behavior
• Unacceptable UX risk

⸻

Phase 4: Investment Decision Gate (Product + Engineering + Research)

Goal: Decide whether the solution deserves full SDLC investment.

This is the most important step and the one most companies skip.

Inputs:
• Expected customer value
• Technical complexity
• Operational risk
• Maintenance burden

Explicit decision:
• Build
• Delay
• Kill

This is where AI stops being a science experiment and becomes a product commitment.

⸻

Phase 5: SDLC (Engineering-led, Research-supported)

Only now does traditional SDLC begin.

Activities:
• Hardening
• Scalability
• Security
• Integration
• Reliability engineering

Key difference from normal software:
• Behavior is not fully specifiable
• “Correctness” is statistical

Ownership: Engineering

⸻

Phase 6: Evaluation, Monitoring, and Iteration (Shared Ownership)

Split ownership (critical):
• Research owns:
• Evaluation methodology
• Drift detection
• Model / prompt iteration
• Product + Engineering own:
• Observability
• UX adjustments
• System reliability

This acknowledges reality:
• AI systems do not “finish”
• They degrade, shift, and require scientific intervention post-launch

⸻

Why this framework strengthens your article

This lifecycle:
• Makes early exits explicit and virtuous
• Explains why roadmaps fail, instead of blaming people
• Gives boards a concrete alternative to “just ship faster”
• Validates the role of research without turning everything into a science project

Most importantly, it gives leaders permission to slow down early so they don’t fail late — which is the central tension your article captures.

⸻

“AI projects fail not because teams move too slowly, but because they move too fast through the phases that require science instead of engineering.”