"I'm using AI" is something almost every engineer can say today. But what that means varies wildly. For some, it means pasting an error message into ChatGPT once a week. For others, it means they've rebuilt their entire workflow around AI agents. Same statement. Different universe.
As a director of engineering at STRV, I see this play out across dozens of engineers, including myself. To bring some structure to the process, I mapped AI adoption into levels.
The six levels of AI adoption, at a glance:
- The Skeptic: Skeptical; limited hands-on experience
- The Tourist: Uses AI occasionally, not in daily workflow
- The Assisted Coder: AI in IDE; autocomplete and boilerplate
- The Prompt-Driven Developer: Delegates well-defined tasks via prompts
- The AI-Native Engineer: AI-first approach; reviews output over producing it
- The AI Architect: Designs systems where AI is a first-class participant
This is to understand where people are, what holds them there and what moves them forward. Because your AI strategy is only as strong as the people behind it.
And I get why people may resist. It’s easy to be skeptical at the start. Then it feels threatening to go deeper, like admitting the way you’ve been working isn’t good enough. But once you break through that entry barrier, it’s rewarding. You look back and realize how much you were leaving on the table. And at every stage, the same thing applies: you don’t know what you don’t know.
Level 0: The Skeptic
"I've been writing code for X years. I don't need a text predictor."
These may be the most experienced engineers. Seniors, specialists, people who've invested years into mastering their craft. They take pride in the quality of what they write, and they should.
When AI comes up, their response is almost always the same: stories where AI failed. Their own experiences, things they've heard: hallucinated code, nonsensical suggestions, output that wouldn't survive a code review. A lot of that is real. AI does produce garbage sometimes. But it's far from the full picture, and one bad experience becomes the reason to dismiss everything that came after.
I want to be honest about what's underneath the skepticism, because I've felt it myself. When you've spent years building a skill and genuinely hard-won expertise, and something comes along claiming to do the "same thing" faster, that doesn't feel exciting. It feels threatening. That's not a weakness. That's human. It's an identity question: if a machine claims to be able to do what I do, what was all that effort for?
The answer, I think, is that AI is a multiplier, not a replacement. And if you're an engineer reading this, you can do the math. The more skill and domain knowledge you bring, the more AI amplifies. Which is exactly why it's a problem when the most experienced engineers opt out. They're the ones leaving the most on the table.
You're at Level 0 if: you have strong opinions about AI-generated code but haven't spent more than an afternoon actually using it.
What moves you to Level 1: Just try it. Genuinely. The worst that may happen is that you're right.
Level 1: The Tourist
"Yeah, I use AI sometimes."
They see some benefit; it's Google or Stack Overflow on steroids. Useful, sure. But ask for specifics, and there's not much behind it. AI isn't part of their daily work. It's a browser tab that gets opened when other approaches fail. A tech-savvy grandma can be a tourist too. And that's fine for her. But for an engineer, there's a lot more to unlock.
Some engineers pass through this level fast. The curious ones fall down the rabbit hole on their own. For the rest, exposure may be the driver.
I remember when one of our senior engineers was paired on a project with a more junior one who was already deeper into AI tooling. Within two weeks, the senior was excitedly showing us his configured AI setup (already on level 3). Nobody told him to level up; he watched someone work differently, and it clicked. That inner explorer is why he became a senior in the first place. He just needed a spark to reignite the curiosity. And if that doesn't happen organically, the manager needs to be the catalyst.
You're at Level 1 if: You use ChatGPT in a browser tab, but your IDE has no AI integration. You wouldn't notice if AI disappeared.
What moves you to Level 2: Get AI into your editor. Into your line of sight, always on, always available. The shift from "tool I visit" to "thing that's there while I work" changes everything.
Level 2: The Assisted Coder
"Copilot saves me a lot of typing."
AI is in the IDE now. It autocompletes lines, suggests function bodies, and fills in the boilerplate. The engineer knows exactly what they want to write - AI just saves them the keystrokes. Autocomplete on steroids. And the benefit is real. Noticeable. Measurable, even.
That's exactly the trap.
You're using AI coding assistants in a way that's more advanced than most non-engineers. You see the time savings. Sometimes AI misses even simple completions, which reinforces the feeling that this is the ceiling. So you settle in. Good enough, right?
The oversight here is subtle. In practice, they still own every decision: what to write, how to structure it, and which approach to take. An AI coding assistant helps with the typing, not the thinking. The gap isn't awareness. It's trust. They're not yet ready to let go of even a little control to delegate something meaningful to AI and see what comes back. And yet, when they do, the results can surprise them.
One of our engineers was wrestling with a third-party API integration. On a whim, he described the problem in a prompt. It handled the whole thing. That kind of moment is what cracks the ceiling, just enough to glimpse what the next level looks like.
You're at Level 2 if: AI makes you faster at writing code you've already decided to write, but it has zero influence on your decisions.
What moves you to Level 3: Stop giving AI your code. Start giving it your problems.
Level 3: The Prompt-Driven Developer
"Let me describe what I need and have AI build the first pass."
This is the level where something clicks. The engineer realizes they can put text in and get code out, not just autocomplete but actual delegation. They describe what they want, and AI delivers. They start using it for brainstorming, research, documentation, not just writing code. They hand off small, well-defined tasks with detailed, specific prompts.
And it feels like the finish line. You feel ahead of most engineers you know. You're measurably faster. If someone asked, "Do you use AI effectively?" you'd say yes without hesitating. That confidence is earned, but it's a double-edged sword. It feels like a pure win. And pure wins don't make you question your approach.
But the work is still sequential. The developer is the bottleneck between every prompt. There's no parallelism. The workflow is essentially unchanged: sprinkled with AI at every step. These engineers are genuinely faster and delivering noticeably more value. But they're doing the same work faster.
You're at Level 3 if: you write detailed prompts and review every output, but your workflow is still fundamentally yours with AI bolted on.
What moves you to Level 4: Stop thinking about individual prompts. Start thinking about your entire workflow. What would it look like if AI were there from the beginning, not added after the fact?
Level 4: The AI-Native Engineer
"AI first. Me as fallback."
For every task, the first question becomes: "How do I get AI to do this?" You direct, you review, sometimes you step in, roll up your sleeves and write it by hand. Welcome to agentic development.
A reality check, though: the impact at this level depends heavily on what you're working on. System design requiring massive context, data-heavy exploration, problems where the requirements themselves aren't clear yet. AI helps, but it's not the multiplier it is elsewhere. Where this mindset truly pays off is in work with clear specifications: well-defined features, well-isolated services, MVPs or greenfield projects.
This is where your toolchain explodes. You start discovering and configuring: rules files, custom instructions, Model Context Protocol (MCP) servers, project-level context. Now you're learning it's significantly more powerful when tailored to your specific project and codebase. You start talking about "context window" way too much. And then you keep reconfiguring because something you set up two months ago is already legacy, or you simply found a better way to do it.
The experience changes too. It feels like having a very motivated junior engineer, one with occasional brain fog and the odd flash of genius, who works nonstop and is diligent about reporting back to you. At some point, you start running multiple AI sessions in parallel, each working on a different task while you move between them. Work that was sequential at Level 3 begins to run on multiple tracks.
But more output means you have to let go of more control, and that takes real adjustment. You may not review every single line the way you did at Level 3. Your judgment about what to review closely and what to just skim becomes the skill. (If you want to go deeper on what it means for AI output to be trustworthy vs. just fluent, Jirka Koutny's Beyond the Prediction Engine digs into exactly this.)
You're at Level 4 if: your first instinct for any task is "How do I get AI to do this?" and you spend more time reviewing output than producing it, but your codebase and workflow are still designed for humans, not agents.
What moves you to Level 5: Flip it. Start tailoring your workflow and your codebase to AI.
Level 5: The AI Architect
"I don't just use AI. I design systems where AI is a first-class participant."
The core realization: until now, you've been shaping AI to fit how humans work. Level 5 flips that. Your codebase stops being just a place where code lives. It becomes infrastructure for agents to operate on.
This level is less a standard today and more a frontier I see emerging. A small number of engineers are already experimenting here, but the patterns are still forming. What I can share is the mindset shifts that define it:
How Do AI Architects Manage Context?
AI architects don't write single instruction files. They build context in layers: a core set of rules that loads every session, custom agents for specific task types and product knowledge pulled in on demand.
Some of our engineers are already experimenting with agent trees that query long product specifications to optimize the context window of the main agent. Get these wrong, and you'll see it immediately: agents repeating the same mistakes, hallucinations, ignoring parts of your instructions and jumping to conclusions instead of asking questions. And the tricky part, asking the agent if it has a context problem, doesn't help. It doesn't know what it's missing.
From writing code to managing agent teams
Git worktrees. A feature most developers never needed becomes your best friend. You decompose work into isolated tasks, spin up parallel agents and spend your day reviewing their output. Your day looks more like a tech lead's than a senior IC's. The dev job becomes an ops job. You haven't written the code, but you're the person in charge when it breaks.
I had a moment here that stuck with me. I was running a team of orchestrated agents where I'd intentionally built tension into the instructions - e.g. a developer agent vs. a reviewer agent. They got stuck in a dead loop of feedback, neither backing down until the lead agent escalated it to me to decide. I've read the conversation between them and got a flashback to real PR escalations where engineers couldn't close a review. That's when "dev job becomes ops job" stopped being a metaphor.
From "does it work?" to "are my guardrails holding?"
AI output is probabilistic. The same prompt won't always produce the same result. Instead of catching problems in review, you build verification loops into the workflow itself. Agents that test other agents' output, linters that enforce architectural rules, automated tests and validations that run before code ever reaches you.
This is essentially different work. And it's not new; when engineers moved from assembly to higher-level languages, the early experimenters defined how everyone else worked for decades. The same thing is happening now. (For the company-level view of this shift, Lubo Smid's Why Legacy Companies Will Win the Agentic Engineering Era covers why domain expertise becomes the real differentiator.)
You're at Level 5 if: you spend more time designing context, specs, and guardrails than interacting with AI directly. Your codebase is structured for agents to navigate, not just humans.
Few engineers are fully here yet. But I'm happy that people around me are actively experimenting - tweaking architecture, redesigning workflows, building context systems. This level is still taking shape. Knowing where it's heading gives you a direction.
How Do Engineering Teams Progress Through AI Adoption Levels?
What moves someone forward is different at every stage, and whether you're managing a team or trying to level up yourself, understanding that difference is the whole game.
Getting someone from Level 0 to Level 1 takes compassion and a well-targeted push. Acknowledge that feeling threatened is normal. But be clear about the expectation. Remember: The goal is not to abandon expertise; it's to amplify it.
Level 1 to Level 2 is a tooling problem. Get AI into their IDE: always visible, always available. Most engineers who try it in their actual workflow don't go back.
Level 2 to 3 is the hardest jump, and it requires a mindset shift. The engineer has to go from "AI helps me type faster" to "I describe problems and AI builds the first pass." What helps are aha moments - you can wait for them to happen organically, or you can help them by pairing engineers with someone a level ahead. That does more than any workshop.
Level 3 to 4 is a workflow redesign, and it requires two things many teams don't have: permission and opportunity. Permission to make initial mistakes, to be messier for a stretch. And an opportunity where the stakes are low enough that experimentation won't blow up. If you're a manager, this is where your cover matters most.
The leap from Level 4 to 5 is different; not everyone needs to make it. Just like today, you don't need a team full of architects. You need a few Level 5 engineers designing the infrastructure and a team of Level 4 engineers who build effectively on top of it. The job for directors and CTOs is knowing which distribution your team actually needs.
That's why I see AI adoption as two separate tracks: individual adoption and engineering-level adoption. You have to start with the individual. Only when your engineers are mature enough in their own AI workflow does it make sense to introduce team-wide processes and shared tooling. Without proper individual adoption, who's going to use them? Who's going to build them? Get the people right first. The systems follow.
If you're still waiting for your leap of faith, just do it. The entire interface of AI is human language. It literally cannot be easier to begin.
And if you're already in the agentic world, remember that speed doesn't transfer responsibility. The AI writes the code. Your name is on the commit. Enjoy your ride on this “German autobahn," but keep your hands on the wheel.
