The 3 Phases to the Agentic Epiphany

or: How We Learned to Stop Coding and Love the Factory

Most engineering teams use AI to write code now. But how effectively they use it - and how much faster they ship because of it - can be WILDLY different team to team and company to company.

My team and I have talked with hundreds of engineering leaders, VPs, and CTOs about rolling out agentic coding, and we've also been through it ourselves here at OpsLevel.

This article is a detailed breakdown of all the steps (grouped into 3 main phases) that we've seen take companies from zero usage to heavily automated Software Factories.  (And you'll be able to skip to the part you're at.)  

Obligatory: why should I care about agentic coding adoption?

Now before I get into adoption tactics, I want to preface: this isn't an article about WHY you should want heavy agentic adoption. But if you're not already on the bandwagon enough to happily read the rest of this article, then read this part first.  

Adopting agentic tools - including and especially agentic coding tools - isn't optional.  There's a reason that the frontier model companies decided to tackle agentic coding before literally any other vertical: because dramatically increasing their pace of development can be a massive competitive advantage for them. And - conversely - ignoring this means they will fail to their competitors.

It's the same for everybody else. In a year or two, all companies will be bucketed into 2 binary segments: those that are AI-native, and those that aren't.  If you existed pre-AI, you're slowly but surely moving towards one of these two buckets right now.  (And most new startups being built today - at least the ones that have a shot at ending up successful - are entirely AI native.)  

AI-native engineering organizations (when they effectively crack that nut, mind you ) get more output per engineering dollar, and ship faster than their competition.  Sometimes vastly more.  Their advantage compounds every day.

The 3 Phases

There are roughly 3 main Phases that teams tend to go through on their adoption curve.  Each phase sees gains in usage and value, but also creates its own new bottlenecks that causes a plateau in value/adoption.  (e.g. the super common "the new bottleneck is at code review" complaint.) These plateaus are where many engineering teams get stuck - sometimes indefinitely.

Getting stuck in these plateaus feels like you're still slowly making progress, but really the gains flatten out. Getting past each plateau takes a deliberate push of its own - and that's what the next Phase gets you through.

I wrote up what I've heard from many conversations into this article. I've tried to be comprehensive - it starts with how to make your very first push at getting everyone to truly experience their first wins using AI, and ends with building Software Factories: where work moves through the whole SDLC on its own, and people step in only where their judgement is needed.

You might be anywhere on this path already. Find your phase (or plateau) and start there:

• Phase 1:  Individual Adoption. This is where everyone started. The bottlenecks going in are belief and skill. A first win can cost more effort than people expect to get back. Building champions, showcasing wins, and stacking hackathons lower that cost and get momentum started.
• First Plateau: Stuck in tinkering mode. People use AI inside unchanged expectations and workflows, so the rational move is to do the old work a bit faster, sometimes.
• Phase 2: Org-wide adoption. Resetting expectations on productivity, mistakes, and even people's very job. Guardrails follow to rein in the chaos.
• Second Plateau: Bottlenecks have moved. Coding stopped being the constraint. Bottlenecks in your pipeline just shift around.
• Phase 3: Build systems. Measuring and agent-ifying the entire SDLC comes next. Then taking the most successful workflows and turning them into continuously running/improving factories.

‍

‍

Phase 1: Individual adoption. Get people using it.

1. Create an emotional moment for the team

So, to preface: this was more needed a year or two ago, when it wasn't clear exactly how AI would change software development. Now it's fairly clear, BUT - some teams still haven't grasped the reality that's slapping them in the face.

For those not using agentic tools at all, it's time for a reality check.  This isn't a fad that everyone's going to be sick of in a few months.  They need to hear the truth.

A good approach goes something like this:

"Your job - as you knew it - is disappearing. It simply won't exist in a couple of years. Full stop.

Hell, in many companies it doesn't exist anymore. It's just the reality. These companies are still employing tons of software developers - but their job isn't the same as your job.

I want to help you on this journey. Nothing has ever changed this fast in our careers. We're going to learn a lot, and if we're successful we'll improve our productivity here, but we're also going to make you a lot more employable in general. So it's win win."

And this should be in a venue where you can be speaking to everyone, like an all-hands or team meeting.

You won't get everyone, but even capturing the attention of 20-50% is a win.

2. Give them whatever they want

Cursor, Claude Code, Codex, etc. Let people try whatever they want. Don't worry about standardizing anything yet (you'll deal with that in Phase 2). Right now you just want to get people using it.

If someone needs extra credits or wants the $200 upgrade, sure. Let them experiment. You can look for specific ROI later. At this point you should worry way more about people not trying it than about what it costs.  (You will focus more on that later - don't worry!)

20% of the org will really grasp it, and the rest will dismiss it with something to the tune of "I tried it, I didn't like it" or "I tried getting Claude to do X, but it did something stupid." (Which is probably true - although you'll find they didn't really put in much effort either.) Getting good results out of these tools takes some practice and a learning curve: figuring out what kind of work they're good at, and where you need to step in and correct them. Most people won't grind through that on their own yet, and that's ok - we'll get to them in step 4.

But you'll get SOME people that latch onto what it can do. They'll actually put in the effort, even after it does something stupid.

3. Find your champions, and put them on stage

Find your first set of champions: even on a smaller team of 20 people, you'll have 2-4 who will be like "let me show you what I can do."

What you're looking for: as leaders, you're expected to be a bit crazy, out in front, on a limb - but you need normal folks to go on the journey too. Your team will identify more with their peers vs you. When you say this stuff is amazing, people kind of expect that from you. But they actually believe it when someone on the team shows it working in your own codebase.

Once you have these champions, build momentum. Start to socialize a bunch of wins. Do little demos: show what you did, how fast it was, how easy it was, where you needed to correct it, etc. (Don't skip the corrections! They keep the demos realistic, and show everyone else some of the learning curve.) You could also have people circulate videos of their wins.

What we did: a weekly AI Lunch and Learn. We had 3-4 people volunteer each week to show their wins & what they were able to do. So every week, people got to watch their own teammates show off (A) what they've built, (B) how they built it, and (C) how they use it.

4. Dedicate time - give everyone a slam dunk

Next: dedicate some time. Run a mini hackathon, or hijack a sprint, etc. Tell everyone: "we're going to practice really hard on agentic stuff." In a normal sprint (with goals and deadlines) it's always going to feel faster to just do it the way you already know. So dedicate time, have the end product goal be flexible, and code only with agentic tools during this time.

When we did this, we stacked the deck on things we knew agentic would do a good job with. By now you've got a handful of people on the team (your champions from step 3) who know that Cursor would crush problem X vs some problem Y where it might get wrapped around the axle. So take their ideas, and dole them out as hackathon projects. Save the problem Y stuff for later, once people have had some practice.

The idea: you want to give the non-champions a win. Something where they'll see good success easily - they're not ready yet to grind their way to get a win. So you want to give them a slam dunk, to get them addicted. A lot of them will start putting in the effort on the problem Y stuff too, once they've seen it work for real on something they did themselves.

‍

First Plateau: Stuck in tinkering mode

Ok great: you've not only got people using it, but actually impressed at what it can do - at the right time and place. You've got a bigger set of folks that include AI tools in their toolbelt.

At this point, however, after some weeks/months, you might plateau on either usage or the value you're seeing from it. It'll feel like "ok we're using AI but... kind of just working like we were before, just a bit faster." SOME individuals are using AI here and there regularly, some not - but overall they're working with the same constraints and workflows they used to. There is AI use, but behaviors haven't changed.

‍

Phase 2: Org-wide adoption. Make it the default.

5. Be clear that productivity (and quality!) expectations have changed

Yin: Productivity. Time to sit folks down again and tell them the truth:

"You've all seen what's possible. There's very visible and irrefutable proof that you can move a lot faster now, at least on certain tasks. And we can clearly see some individuals or teams are moving a lot faster now. So you no longer have the option to be as productive as you were in 2024. My expectations - and the whole business' expectations - on you are higher."

(They might think: Was this a trap? Should I have not tried before, because then expectations wouldn't have gone up?)

No - it's not about you. It's about whether we can survive as a company. The stakes are much higher than you might think. Even if everyone here buries their head in the sand, the rest of the world isn't. Competitors are figuring this stuff out. In fact our whole industry* is under fire. If we don't adapt and improve, we're going to fail to those that have figured out this shift better than we have. It's only a matter of time.

(* This feels true for nearly every industry at the moment...)

Yang: Quality/reliability. On the flip side, you can't expect that everyone is going to double their productivity without any learning curves. There are going to be mistakes made, and quality might temporarily take a hit here and there.

So likewise, as you're setting expectations for productivity, you have to also be clear that quality expectations are more flexible as we learn. This is extremely important and it won't just naturally happen on its own.

Everyone has to be taught that it's ok to make mistakes, so long as we fix them quick and then learn from them. (Make a mistake, remediate quickly, then put up a guardrail preventing it from happening again.) There might be some sacred cows - like not compromising security - but be very clear on what is and what isn't.

But we can't go into it with the mindset of doing it without any mistakes or code quality issues, or we'll NEVER move forward. Sometimes this can be hard for management to accept, but we also found that this can be extremely difficult for a lot of engineers to accept too.

6. Actually change people's jobs

Remember back in Step 1 where we told everyone their job was changing? Well it's time to make that literal.

It's not so much how they do the job that's changing (although it certainly is - now instead of coding they can just ask their little coding buddy to do it), but the scope of what they do should change too.  It gets much broader.

We experienced this directly at OpsLevel, shifting our expectations on where people should be involved. Before, our developers were "Software Engineers" that got requirements from a PM and build the product exactly as spec'd. We've worked through (and continue to work through) transitioning people to be "Product Engineers" who take more end-to-end ownership on product outcomes: they now prototype more based on problems they see, work closer with customers, and collaborate more with the PM on solutions.

(Aside: you might see a little bit of organ rejection here, or even earlier. Some people just won't be ok with the switch. Everyone's job is fundamentally changing, in many different ways. Some might grieve the loss of the value of some of their well-honed skills, and that's natural and ok - it will pass as they see the value of their other skills grow. Others might just simply not like their new job. That can be harder: we've seen some amazing people leave not just the company, but the industry; disillusioned by the change and wanting something different. Long-term it's for the best, but it hurts at the time. We'll discuss all this in another article that digs into some of these kind of hard things.)

7. Rein in the chaos. Figure out guardrails

Ok, you might be actually picking up some serious steam now. If you can get a bunch of people adopting new tools and thinking outside of the box they used to work in, you're going to see a lot of cool stuff. But things might also start to get a little crazy here.

People will say "this is cool... let me go do a bunch of things in this code base I don't own or understand." Or people will start throwing around slop grenades: sending giant PRs for code review where they didn't even look at it properly themselves.

Experienced devs might get overwhelmed with pull requests from less experienced devs. (Or pull requests from people who aren't even devs!) So senior people get jammed up reviewing PRs of questionable quality, and it creates a bunch of chaos.

Remember though: this is great. You're getting momentum and excitement. Don't put the hammer down or anything like that.

But the next step: how do you add more guardrails to rein in the chaos? "Productionize" it.

• AGENTS.md in your repos. Keep it short.
• Turn what works into shared skills/plugins/etc. Find ownership for these, like a platform team.
• Set some PR ground rules if there aren't yet.  (Like... reading your own PRs first. Keeping them small.  Etc.)
• Make sure CI is in a good spot and doing a lot of the standard / "boring" checks.

Basically: write more documentation (for agents and people) and overall start standardizing on what works.  This doesn't all have to happen at once.

‍

Second Plateau: Bottlenecks have moved

Ok great! You've seen some real change. People are using AI and agentic tooling across your teams, and you've seen adoption rise dramatically. And wow, can code ever be written more quickly than before. But... are we actually delivering that much faster?

Some folks see another plateau here. We've made one part of the SDLC (coding) much much faster, but the rest hasn't improved. So, we're coding faster but aren't really shipping all that much faster than before. And there are still huge discrepancies of productivity between teams. Some behaviors have changed, but overall the way you deliver software hasn't.

‍

Phase 3: Build new systems. Automate entire workflows.

Here's where we step back and say to ourselves: hey, if we were re-inventing software development from first principles, what would be involved?

8. Measurement.

Ok before we get too deep, it's important to have some actual concrete views of your shipping velocity and quality. After all, you can't improve what you can't measure, as they say.

That being said: don't overthink it. In my 20+ years of experience and in the many decades of software engineering that happened before that, never has anyone ever actually agreed on a foolproof way of measuring engineering throughput. So, keep it simple. Have something that's good enough, and that you can use as a proxy for engineering speed and stability (like DORA metrics), and keep an eye on that.

Honestly though, you should actually be able to tell based on vibes at the start too. You'll be like "holy crap, they did all that in one sprint?" many times. It'll be obvious where it's working. It's like product-market-fit or pornography: you'll know it when you see it. You're really targeting a multiple increase, not a percentage one.

9. Beyond coding: Agentify the rest of your SDLC!

So far, the part of your SDLC that you've been making faster with agents has likely mostly been the part that's historically taken the longest: coding! And why not, it's the part of the job that developers used to be spending the most of their time doing, when they weren't stuck in meetings. And it's also the part that agents are getting shockingly good at.

But it's like analyzing a system with Queuing Theory (or, if you prefer, the Theory of Constraints) in mind: if you make it faster/easier to process work at one step in the system, the bottleneck shifts either downstream (PRs piling up to code review) or even upstream (not enough spec'd / triaged to fill the system).  One of our own first bottlenecks was in fact that: we ran out of prioritized work to do.

So the solution: let's increase the throughput of our other steps in the system too! Build agents or skills that can work on more stages in the SDLC:

• Triage
• Prioritization
• Design / Spec'ing
• Code Review
• Validation / Integration
• Deploy

Each of these can be improved with AI involved. Not necessarily fully automated, but the pace at which a human can drive work through these stages can be increased with agentic help.

Each of these stages can also be elaborated on by an entire article - or product! - of its own. I won't get into detail on it in this article, but some serious engineering work can happen here.

10. Industrialize. Build a factory.

You've made some real progress getting to this part. You've figured out ways that agents can speed up many different steps of the SDLC. But you're probably still seeing big differences on how well different teams are picking up the best-of-breed skills and workflows. The future is already here, but it's just not evenly distributed yet.

You're still pre-industrialization: you've got various skilled artisans that are really good at what they do, and have mastered their tools.

It's time to go through the industrial revolution. Let's build a factory.

The goal: standardize and build factory lines to automate workflows and steps that are rote. Some people or teams will have figured out a set of agents that they put work through, and that work really well for them. Take these agents, productionize them, and string them together using shared workflows that others can use.

Don't stop there. Add guardrails to give agents more autonomy where you can. Start with types of work that are rote and well scoped, where human judgement isn't really needed.  (We've found CVE patching, bug fixes, error remediation, etc - these are easiest to attack first.)

Add guardrails above your agents, that look at (A) the type of work being done, and (B) how ready your systems are for agents to act on them autonomously. (Do they have all the right prerequisites to give you confidence agents can move without breaking things?) These guardrails should involve deterministic checks (again - above-the-agent, vs in-the-agent) and not rely on any agent's confidence or judgement.

Invert the creation and processing of work, so humans don't have to drive things between each step. Why do humans need to pick every bit of work off of a backlog and move it through the SDLC? Work should be able to be picked up - at every stage - automatically when it's properly defined and scoped. (And even properly defining and scoping work can be helped by agents.) Even "finding" work / triggering workflows can often be done automatically once you've got enough automation downstream.

This can save a LOT of time from your people. Where you can, try to reserve human interruptions / time for where they actually need to be involved: where their judgement matters. Especially when making product decisions, architectural decisions, risk decisions, etc; decisions involving taste, intuition, and judgement.

String this all together to build out autonomous workflows (incorporating the best-of-breed solutions) and let them run as autonomously as possible.  Again, it's easiest to start on the really well-scoped work: CVEs, errors, bug fixes, etc. Have these be triggered automatically where you can, vs having to be triaged and prioritized and vetted etc by humans too.

Then start dialing things up. Repeatedly target bottlenecks and remove them. Improve guardrails and autonomy. Target more complex types of work. Improve the factory. Have people work ON the factory, not just IN the factory.

Move away from processes where tasks are driven solely by people, and have to block waiting on that person or other people at every stage. Move towards a future where tasks are picked up and driven automatically through a system. Where everything is done in the open, with shared context - giving visibility to other engineers and leadership. Where bottlenecks are constantly targeted and reduced. And where every improvement to an agent or workflow is shared.

There's no concrete "end" to this phase. You're now in a state of Kaizen, continuously finding and implementing improvements.

Learning to love the factory

You're somewhere on the above journey today. Wherever you are on the map right now, there's a next push to make. (And if you're stuck on one of those plateaus, you've got a LOT of company - trust me!) To get out of tinkering mode, reset expectations and make agentic the default for everyone. And once the bottlenecks move, look past the coding and start building the system around it.

Even once you've built your first factory, you're not nearly done. The job turns into working ON the factory: find the next bottleneck, remove it, give the agents a bit more autonomy, and repeat.  And then build your next factory.

See you on the factory floor!

‍