Everyone Has a License. That's Not AI Adoption.

"We've got the whole team on Claude now."

I hear a version of that on almost every call, usually with a little relief behind it. The mandate came down from the board, the seats got bought, the box got checked. Then I ask what actually runs differently than it did in January, and the room goes quiet.

That quiet is the reason we ran this series. Most mid-sized companies report little or unclear ROI on their AI spend, and the failure almost never traces back to the model. It traces back to the fact that nobody changed how the work gets done.

Session 4 of AI for Operators was our finale, and it was about closing that gap. Not more Claude tricks. The rollout.

We ran this on our own team before we sold it to anyone

Nick noticed the same thing inside Gnar that we now see at clients: our engineers were all over the map. Some were running agents in loops. Some were still pasting code into a chat window and hoping. Same tools, wildly different results, no shared floor.

So we built a four-week curriculum and ran our own team through it. Assessment going in, assessment coming out, so we could see movement instead of guessing at it.

The numbers after: 43% more tickets shipped per sprint, and 93% more story points.

The second number is the one that matters. If both had moved together, all we'd have proven is that people type faster. They didn't move together. Points nearly doubled while ticket count went up less than half as much, which means the team started picking up bigger, gnarlier work it used to route around. That's a different thing than speed. That's capability.

We shipped almost none of the curriculum out the door unchanged, and we didn't offer it to a single client until we had our own before-and-after in hand.

The ladder your engineers are standing on

The five tiers we teach aren't an industry standard, exactly, but you'll find some version of them anywhere people are serious about this work.

• T1, engineering fundamentals. No agent involved. Can this person read a spec, a diff, and a test and tell you whether the code is any good? This is the floor, and it's a floor for a reason. Somebody has to be able to catch the model when it's confidently wrong.
• T2, prompt engineering. Prompting a coding agent in the moment, running the loop, reading the output with real skepticism. Most teams that "use AI" live here.
• T3, context engineering. The project carries persistent context now. A CLAUDE.md file, durable plans checked into the repo, maybe a connector or two wired up. The work stops starting from zero every morning.
• T4, harness engineering. Recurring work gets packaged as reusable skills, guarded by settings and hooks, delegated to scoped agents. The process is the asset, not the prompt.
• T5, loop engineering. Teams of agents, dynamic workflows, evaluation harnesses scoring the output, cost tracked across the fleet. This is the frontier as of today, and today will move.

Engineers generally enter at T1. Coming out of the four weeks, we mostly see people at T4 and T5.

Three questions, no code required

So what do you do with that ladder if you can't read a line of your own codebase? Nick gives leaders three questions. Ask them this week.

Do your AI tools carry persistent context about the project, or does everyone start from scratch each session? A yes puts you at T3.

Does the team share reusable AI workflows, or does each person prompt their own way? That's T4.

Are there automated checks on AI-generated changes? Guardrails, quality measured on output? T5.

Three questions, three tiers, about four minutes of your day. You'll know more about your AI maturity than any vendor assessment will tell you.

The most important file in the codebase has no code in it

We spent a chunk of the session inside a real CLAUDE.md, anonymized from an actual client project. It sits at the root of the repository, it's plain markdown, and Claude Code reads it at the start of every session. Every engineer who opens that project gets the same context. Think of it as the project's constitution.

What's in it isn't technical in the way you'd expect.

There's a commands section that tells the AI to run the full type check, lint, and test suite before anything gets committed, so it catches and fixes its own failures before a human ever looks. There's an architecture section holding the business rules that usually live in exactly one engineer's head. One line in the file we looked at: cross-branch subscribes are rejected. One branch can never see another branch's messages. When that engineer takes a vacation or takes another job, the rule stays.

Then there's the rules section, which is my favorite part, because you can feel the frustration that produced it.

Modify, don't recreate. Create the smallest possible diff. Never change the look and feel of untouched UI.

Somebody on that team got tired of watching AI enthusiastically rebuild things that already worked. So they turned the annoyance into a rule, and now it's enforced on every single change. Further down, a delivery workflow with mandatory approval gates: for big features, the AI has to stop and get a human signature at each phase. The business decided that. The team wrote it down. Now it isn't optional.

The code review section is where it gets a little wild. This team doesn't have Claude review a pull request. It dispatches three reviewers in parallel, each with one specialty, correctness, tests, and security, and requires every finding to be verified against the actual code before it's reported. Anything unconfirmable gets discarded.

That's orchestration. Three AI agents working a pull request like a review panel, implemented as a paragraph of plain English in a text file that you, a non-technical operator, could read start to finish and understand.

For a fifteen-year-old system whose authors are long gone, you don't even have to write that file yourself. Point Claude Code at the codebase and it will produce the documentation nobody ever wrote.

Why the tier you're on decides your modernization budget

Which brings me to the least glamorous, highest-payoff thing in the session.

If you're sitting on an aging ERP or CRM or some internal tool the original team abandoned years ago, three uses of Claude Code will save you real money. Reading the legacy system and documenting it. Drafting the data migration scripts, which is where these budgets usually detonate. And writing tests that pin down how the old thing actually behaves, so that when you refactor, the failures tell you exactly where you broke parity.

That last one converts a leap of faith into a checklist. Work that took weeks can take days.

But that math only holds if your team can operate at T3 or T4. A T2 team pointed at a legacy modernization will overrun the budget, under-document, and push more bugs to production, because ad hoc prompting produces real gains that arrive inconsistently. Same tool, same codebase, wildly different outcome. The variable is the team.

Three patterns, and where each one dies

Almost every adoption story we've watched fits one of three shapes.

Leader-led spread. One executive builds a personal weekly workflow, shows a colleague, and it travels by demonstration instead of mandate. It usually stalls at personal use. The early signal it's working: a process that used to live in one person's head now runs the same way when somebody else runs it.

Engineering team uplift. In-house team using AI ad hoc, gains that don't compound. This is the one that stalls at buying licenses and declaring victory. AI is the tool. The practice is what lets you use it.

Modernization with uplift. A CIO on an aging platform, replacing it and raising the team at the same time. It stalls when the whole thing gets handed to a vendor and the institutional knowledge walks out the door with the implementation partner when the project ends.

None of these start with buying a platform. Every one of them starts with a person or an artifact.

Start here, this week

Four sessions ago we started with a five-part prompting framework. Then we moved the framework into a persistent project so a lazy prompt inherits it. Then we built actual software and packaged a process as a skill. Session 4 was the part where it stops being about what Claude can do and starts being about what your company does with it.

Somebody in the Q&A asked whether they should wait for the technology to mature. No. The models keep getting better, but the practice of using them has barely changed in two years. Context, skills, guardrails: those are stable, and they compound. Build them now and every model release lands on a foundation instead of on nothing.

So, two things this week.

Find out where you actually stand. Our AI assessment takes about ten minutes and it's free, and you'll get a readout of where your organization sits and where the opening is.

Then pick one process you run every week that takes too long, and turn it into a workflow or a skill. One. You will not transform the company in a week. You'll make one thing better, and you'll learn more from doing that than from another quarter of evaluating vendors.

My inbox is open at mike@gnar.dog, and we're still doing free one-hour consultations for anyone who came through the series. Grab time with us here.

The license was the easy part. You already bought it.