8 Stages of AI Engineering Maturity for Teams | Upsun Formerly Platform.sh<br>EnglishEnglish<br>français<br>Deutsch

Docs<br>Login

EnglishEnglish<br>français<br>Deutsch

Docs<br>Login<br>Talk to an expertTry for free

Talk to an expertTry for free

BlogBlog<br>BlogProductCase studiesNewsInsights

Blog

The 8 stages of AI engineering maturity: a framework for teams<br>AIAI Engineering<br>09 June 2026

Fabien Potencier<br>Chief Product and Technology Officer

Share

This post is also available in German and in French.<br>A few months ago, Steve Yegge published his 8 levels of AI-assisted development, and it clicked the moment I read it, because I had lived that exact progression myself, moving from autocomplete to running agents one step at a time. Framed as an AI trust gradient, it finally gave the industry a vocabulary for something most of us were already going through without a name for it. If you haven’t read it, save it for later.<br>Yegge's levels focus on the individual developer. And that’s the thing: when you’re leading an engineering team, you’re not managing one trust gradient, you’re managing a whole distribution of them. You’ve got someone running parallel agents all day, sitting next to someone who still thinks of AI as a fancier autocomplete, and both of them are shipping code. This is why the 10x productivity boost everyone keeps talking about almost never shows up at the org level. The hard part is getting the whole organization to move together, without the fast movers creating chaos and the slow adopters quietly falling behind.<br>So we took the same principles and looked at them from another angle: not the individual developer Yegge describes, but the team and the organization the team lives in. Eight stages of maturity, from “nobody has decided anything” to “the factory runs itself”.<br>A quick word on vocabulary, because we lean on it throughout. When we say team, we mean a group of people working together toward the same outcome: engineers, yes, but also product, design, QA, whoever it takes to ship software. When we say organization, we mean the entire collection of those teams, plus the leadership, budgets, and governance that sit above them.<br>And here’s the part that makes this an SDLC story and not just a developer story: the new software development life cycle isn’t just about developers. It’s about the whole team. The old boundaries between product, design, and engineering are getting blurry. A product manager can now vibe-code a working prototype instead of writing a three-page spec nobody reads. A designer can ship real HTML and CSS, not just a design system and a Figma file to hand off. That shift is the whole point, and it’s why thinking in terms of individual developers stops being enough.<br>Let’s lay out the whole map before we walk through it.

Stage 1: The vacuum<br>Leadership hasn’t taken a real position; at most, it bought a batch of licenses and stopped there. Developers form habits without guardrails: pasting code into whatever chat window is open, no shared context files, no agent setup, no managed API keys. This is a learning phase, and I think that’s fine: people are building intuition for what these models can and can't do. That intuition is the real return right now. Don’t mistake silence for inaction. Your developers have already decided for themselves.<br>Stage 2: The drift<br>Stage 1 was about what the organization hadn’t decided; Stage 2 is about what individuals have decided on their own. One engineer quietly has agents handling a big chunk of their output, running off a personal stash of prompts, custom skills, and a carefully tuned AGENTS.md they keep on their own machine. The person beside them hasn’t changed anything in two years, and nobody flags it because individual variation has always looked normal. This is the last stage where inaction is free. Once the drift becomes visible, and it will, it turns into a team-level problem.<br>Stage 3: The islands<br>The gap that used to run between individuals now runs between whole teams, and it shows up on the delivery calendar where everyone can see it. One team has shared AGENTS.md files, wired up MCP servers, and built reusable skills. Its throughput jumps. The team next door still writes code like it's two years ago.. What starts as a tooling gap hardens into resentment, and that's much harder to repair.<br>Stage 4: The standardization bet<br>The first stage that requires real commitment from leadership is that AI becomes a capability you build deliberately. Three things matter here. Context engineering becomes explicit work, with shared AGENTS.md files and a curated skill and prompt library in the repos, so the team encodes its knowledge once instead of every developer teaching the AI the same lessons. Security and governance come before scale: SSO and SCIM, secret scanning, PR gates that run on agent output, audit logs, and an approved list of models and tools behind a gateway, built before people run at full speed. And training is ongoing, not a one-off workshop, usually...