DEV Community: Jono Herrington

Build the System, Not the Prompt

Jono Herrington — Tue, 07 Apr 2026 13:24:00 +0000

If I had to roll out AI again, I wouldn't change the tools. I'd change the approach. I'd start with one repeatable workflow, map every step, define what good output looks like, encode it once, and turn the whole thing into a pipeline. Then I'd improve the system instead of rewriting prompts. That framework didn't come from reading about AI adoption. It came from getting it wrong first and then building my way out across engineering, content creation, and personal workflows until the pattern became impossible to ignore.

The real unlock wasn't a single AI doing a task well. It was learning to orchestrate multiple agents through a shared system that produces consistent output. You can give AI the same prompt twice and get two different results. The only way to get reliability from something inherently variable is to surround it with structure ... defined inputs, clear standards, encoded context. The system is what makes the output trustworthy. The prompt never will.

The only way to get reliability from something inherently variable is to surround it with structure.

Here's how that works in practice.

Start With One Repeatable Workflow

Resist every instinct to go wide.

Most AI rollouts start by giving everyone access and seeing what happens. That approach produces twenty people prompting individually, all getting decent results, none of them building on each other. I read a thread last year where over 500 experienced engineers described what happened when their companies rolled out AI. The stories were remarkably similar. Leadership gave everyone access, maybe ran a training session, and then measured adoption by how many people were using the tools. Almost nobody described a system.

Pick one workflow instead. Not the most exciting one. Not the one with the biggest potential ROI on a slide deck. The most repeatable one. The task that happens the same way, with the same inputs, producing roughly the same shape of output, over and over again. For my engineering team, that was scaffolding a new service endpoint. Every engineer did it. Every engineer did it slightly differently. And every time AI helped with it, the slight differences multiplied.

One workflow gives you a contained environment where you can see what works, what breaks, and what the tool actually needs from you before you've spread the experiment across your entire surface area.

Map Every Step

The mapping is where most teams skip ahead, and it's where the real value hides.

Sit down and write out what a human actually does when they complete this workflow. Not the idealized version. Not the documented version from a wiki page nobody has updated since 2023. The real version. The one that includes the implicit decisions people make without thinking about them ... which logging pattern to use, how to handle the auth layer, whether to write the test first or after, what error messages should say.

When we mapped our endpoint scaffolding workflow, we found twelve distinct decisions that engineers were making individually every time. Twelve places where the output could diverge. Most of those decisions were invisible. Nobody had ever written them down because they felt obvious to the person making them. What's obvious to the engineer who's been on the team for three years is a guess for the engineer who started last month. And it's completely opaque to the AI.

The map doesn't have to be pretty. Ours was a markdown file with numbered steps and notes about where judgment calls happen. But having it at all changed the conversation from "how do we prompt this better" to "what decisions does this workflow actually require."

Define Good Output

This is the step most teams skip entirely, and it's the one that makes everything else work.

Before we let the tool generate a single line of code for our mapped workflow, we wrote down what a good result looks like. Not vaguely. Specifically. A good endpoint scaffold in our system uses this error handling pattern. It logs with this format. It follows this naming convention. It includes these specific tests. The auth layer integrates this way. State management follows this approach.

Most of that had been living in people's heads or "decided" in meetings that produced no artifacts. Writing it down was uncomfortable because it forced arguments we'd been deferring. Two engineers had different opinions about retry logic. A tech lead and an architect disagreed on how granular logging should be. The AI had been scaling both approaches simultaneously because nobody had picked a winner.

This is where the non-deterministic nature of AI makes systems essential. A deterministic tool gives you the same output every time. AI doesn't. If you haven't defined what good looks like in writing, every interaction is a coin flip between five technically valid approaches. Define it once and the system has something to aim at.

If you haven't defined what good looks like in writing, every interaction is a coin flip between five technically valid approaches.

Add Rules, Context, and Examples Once

Once you have the map and the definition of good, you encode it.

Instead of every person carrying the context in their head and typing it fresh each session, you write it down once in a form the tool can consume. For us, that meant markdown files in the repo. Rules for the architectural patterns. Examples of correct output. Context about our specific stack, our conventions, our decisions. All of it sitting alongside the code, where both humans and AI workflows could reference it.

The first time an engineer used the encoded workflow instead of prompting from scratch, the output matched our standards on the first pass. Not because the engineer was more skilled. Not because the prompt was more clever. Because the system already knew what good looked like.

The new hire who joined last week gets the same quality output as the tech lead who defined the patterns. The context travels with the system, not with the person.

Turn It Into a Pipeline

A workflow with mapped steps, defined outputs, and encoded context stops being a prompt and starts being a pipeline.

A prompt is a request. A pipeline is infrastructure. A prompt gets you one good result. A pipeline gets you a hundred consistent ones. And a pipeline can be improved. Update the system once and every future interaction runs through the better version.

When we found an edge case in our endpoint scaffolding pipeline, we didn't adjust one engineer's prompt. We updated the canonical pattern, and every engineer's next interaction benefited from the fix. When we realized our logging context was missing a specific format requirement, we added it once, and it propagated everywhere. The improvements compound because the system is shared.

I've since built pipelines well beyond engineering. My content creation runs through an editorial system with multiple AI agents handling drafting, editing, and grading in sequence. Financial workflows, personal automation, code review ... each one started the same way. One repeatable task. Map the steps. Define good. Encode it. Improve the system.

A prompt gets you one good result. A pipeline gets you a hundred consistent ones.

Improve the System, Not the Prompt

This is where most teams leave the real multiplier on the table.

The default behavior with AI is to optimize the prompt. The output wasn't quite right, so you rewrite the instructions. You add more context. You try a different framing. And maybe it works better this time. But that improvement lives in your head, in that one session, and it disappears the moment someone else sits down to do the same task.

The alternative is to improve the system. When something doesn't work, you don't rewrite the prompt. You update the encoded rules, the documented standards, the context files that every future interaction draws from. The fix propagates. It compounds. It gets better for everyone, every time, without anyone needing to remember what worked last Tuesday.

The team that has ten encoded pipelines and average prompting skills will outperform the team with zero pipelines and a Slack channel full of prompt tips. Every single time. Because one team is building infrastructure and the other is performing.

If you're leading an AI rollout right now, pick one workflow. The most boring, repeatable one you have. Map it. Define what good output looks like. Write it down. Encode it. And then do the same thing with the next workflow, and the next.

The compound return isn't in the prompt. It never was.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

AI Multiplies What You Already Have

Jono Herrington — Mon, 06 Apr 2026 13:16:24 +0000

A junior engineer on my team pulled me aside recently. Not to ask for help. To share a concern. He told me he wasn't always sure he understood everything the AI was outputting for him. He'd been reading it, checking it, shipping it. But he couldn't reliably tell if it was right. He was learning, he said, by reading what the AI wrote.

I sat with that for a minute.

He's more self-aware than most. What he described is the default mode for junior engineers right now across teams everywhere, not just mine. They get access to AI tools. The output looks like code. It compiles. The basic tests pass. So they call that learning.

It's not. Reading AI output is like copying the theorem off the board without working the proof. The notation is right. The understanding isn't there. And the gap between those two things is invisible until production breaks.

The Multiplier Goes to Those Who Need It Least

A study tracking AI credit usage across engineering teams found that seniors were using the tools four to five times more than junior engineers. The engineers gaining the most from the multiplier were the ones who least needed the help.

The first read is that juniors need to be pushed toward adoption. But I don't think that's what's happening. The story is that seniors know what to ask for. They can evaluate the output the moment it appears. They use AI for boilerplate, test generation, migrations ... the parts of the work where their judgment is already baked in and they're buying back time on execution.

A senior engineer with AI is a fighter pilot with autopilot. The autopilot does a lot. But everything it does is evaluated by someone who has logged the hours. Someone who knows what a wrong answer looks like before the instruments catch it.

Give that same tool to someone who skipped the fundamentals and you get something that looks identical from the outside. Code gets written. PRs get opened. Features ship. Then production breaks at 2am and the engineer is googling their own code like it's someone else's crime scene.

The senior engineer with AI is a fighter pilot with autopilot. The junior without fundamentals is pressing every button that lights up.

The Vibe Coder Is Already in Your Code Review

The vibe coding conversation has been loud enough that most engineering leaders have an opinion on it. Someone who ships code they can't explain, chasing vibes instead of understanding. Most teams feel confident they don't have this problem.

I'd look again.

What my junior engineer described is structurally identical to vibe coding, it just arrives wearing the uniform of a developer workflow. AI-assisted output that the engineer learned from by reading rather than building. Code that functions in local environments but carries invisible load-bearing assumptions nobody interrogated. Engineers who can't tell you with confidence whether the output is right, because they never developed the instinct that fires when something is quietly wrong.

The vibe coder built nothing and shipped. The junior engineer with AI is building through the AI and shipping. The result looks different in the PR. Under real production load, at 2am, the difference gets harder to find.

The tell is in the question they ask when something breaks. A senior engineer asks where the failure is and why. A junior engineer who built entirely through AI asks what the AI gave them and how to fix it.

One is debugging. The other is customer service.

I Was the Skeptic First

I want to be honest about something.

My own chapter one with AI was resistance, not adoption. I wasn't the person who ran toward these tools immediately. I tested them skeptically. I failed with them. I had to build a real sense of when to trust the output and when to override it before I could use AI the way I use it now. That process ... the friction of it, the reps of being wrong and having to figure out why ... is what gave me the judgment I bring to every AI interaction today.

And it's not their fault. The system isn't asking them to take it. They're not being asked to be wrong and learn from it. They're being asked to ship. The tools arrive, the output appears, and the workflow moves forward whether or not the engineer could have written any of it themselves.

As a leader, it's my job to stay ahead of what the tools are creating, not just what they're enabling. And what they're creating right now is a generation of engineers learning by reading AI output and calling that the same thing as building.

My junior engineers are getting the tools without the journey. And the system isn't asking them to take it.

Does the Foundation Still Matter?

The counterargument I hear underneath all of this is whether it even matters anymore. The code ships. The product works. Maybe requiring engineers to understand what they're building is an older generation's concern dressed as wisdom.

I'd argue it matters more now, not less.

The FAA doesn't reduce manual flight hour requirements when autopilot improves. It maintains them, because what automation makes better at the margins is the same thing it makes more catastrophic when it fails. The pilot with the most manual hours is also the best at using autopilot, not because those hours create nostalgia for hand-flying, but because they build the pattern recognition that catches what autopilot misses.

Engineering is the same. AI makes gaps invisible. It papers over missing reps with correct-looking output. A senior engineer can see through the paper because they've been on the other side of that code, in production, under load, when the assumptions break. They know what the paper is hiding because they've written it.

A junior engineer who built primarily through AI doesn't have that. Not because they're less capable. Because they haven't had to be wrong in the right environments yet.

The Gap Is Already Running

My senior engineers are doing things right now that looked impossible eighteen months ago. I watch it and feel two things at once. Pride in what they're capable of producing. And a harder question I can't stop thinking about.

Their judgment ... the thing that makes them dangerous with the tool ... came from experiences that no longer happen the same way. Debugging at 11pm. Writing systems from scratch and watching them fail. Refactoring under pressure with nowhere to hide. Those aren't just memories. They're the reps that built the evaluation muscle they now bring to every AI output.

AI is doing those reps for the next generation of engineers.

The seniors' judgment came from debugging at 11pm and writing systems from scratch. AI is doing those reps for the next generation.

The juniors who flagged their own concerns to me are the ones I'm watching most carefully. Not because they're behind ... but because they already sense something is missing. That awareness is the beginning of the foundation. They're building it slower, but they're trying to build it.

The ones I worry about are the ones who don't notice the gap at all. Who ship with confidence because the output compiled and the tests passed and nothing has broken yet.

It will.

Multiplying zero is still zero. And the engineers watching their seniors use AI to do in an afternoon what used to take a week should be asking themselves a different question than how to use the tool.

They should be asking what their seniors built before the tool arrived.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

The Mandate Had No Return Address

Jono Herrington — Fri, 03 Apr 2026 15:27:22 +0000

The first time I opened Cursor, I used it for ten minutes and shut it down. It felt foreign. The suggestions arrived faster than I could evaluate them. The workflow I'd built over fifteen years wanted no part of it. I closed the laptop, told myself I'd come back when things were less busy, and didn't think much more about it.

I recognized the feeling later. Fear of change, dressed up as productivity skepticism. I'd seen it in junior engineers resisting new frameworks. I'd seen it in tech leads protecting workflows that had stopped scaling. I hadn't expected to see it in myself.

That moment stayed with me when I started thinking about how to introduce AI to my team at Converse. Because I knew something the people who send mandate emails don't know about themselves: the resistance engineers might feel isn't a character flaw or a performance issue. It's the same thing I felt the first time I sat down with a tool that asked me to change how I think.

A mandate doesn't make room for that.

What 500 Experienced Engineers Said

I spent time in a thread with over 500 experienced engineers describing what happened when their companies introduced AI. Senior engineers. Staff engineers. Tech leads. Engineering managers. People who've been writing code since childhood, who've built systems from scratch, who understand the difference between what a tool does and what a tool is actually worth.

The frustration in that thread wasn't about the tools. It was about how the tools showed up.

The pattern was consistent across almost every comment I read. Leadership sends an email. Something like: All teams will integrate AI tools by end of quarter. Approved vendors attached. Adoption metrics to follow. No conversation about which types of work actually benefit from AI and which don't. No pilot where a team tries it on real work and reports back what they found. No feedback loop where engineers can say "this helps here but hurts here." Just a mandate and a number to hit.

Different companies. Same story.

What happens next looks fine for months. Adoption metrics climb. Velocity holds, or even rises. The quarterly review slide looks clean. And then, quietly, something starts to degrade. Decisions that used to come from judgment start coming from autocomplete. The people who were exceptional at the hard parts start to feel like the hard parts don't matter anymore. Engineers who never fully built a system from scratch can't debug it when it breaks, because they never developed the mental model for how it works.

The failure curve is slow and invisible until it isn't. By the time it shows up in production, leadership has already moved on to the next initiative.

The failure curve is slow and invisible until it isn't. By the time it shows up in production, leadership has already moved on to the next initiative.

What the Dashboard Can't See

Here's what the mandate email misses. AI is exceptional at certain things. Boilerplate. Testing scaffolds. Exploring an unfamiliar API. Generating the scaffolding for something you already know how to build but don't want to type for three hours. That's real leverage ... real time returned to the things that require your full brain.

The picture changes on nuanced system design. Security critical paths. Code that needs to survive five years of edge cases from customers you haven't met yet. When you mandate usage without making those distinctions explicit, engineers stop making them too. The boilerplate and the critical path start to blur. And the engineer who was great at knowing the difference ... the tech lead who would have flagged it in review, the staff engineer who would have pushed back in planning ... stops being asked to make the call.

This is because adults do the exact same thing our kids do when you mandate something. They push back. Sometimes loudly, sometimes quietly. Put someone in a corner, tell them this is how they work now, measure whether they're complying ... and you haven't driven adoption. You've driven compliance. Compliance means engineers will use the tool on the tasks that get measured and quietly stop applying full judgment everywhere else.

The organizations in that thread weren't measuring the wrong things. They weren't measuring anything. Compliance dashboards don't capture where AI helps and where it doesn't. They only capture whether people opened the tool.

What I Did at Converse

When I introduced AI to my team, I didn't send an email. I gave the team two weeks of blocked time to explore without delivery pressure. Not meetings. Not deliverables. Just room to try things without a deadline breathing down their necks.

But before I gave my team anything, I had to give myself time with it. It took me about a month to come back to Cursor after that first session. My tech lead had been using it and kept pushing me to give it another shot. He was already deep in it ... building workflows, training agents, figuring out where it actually saved time and where it introduced noise. I eventually came back, and once I did, I stayed. Built my own workflows. Understood, from the inside, what it changed and what it didn't.

That experience shaped everything about how I framed the rollout. The frame wasn't "we need to adopt this." It was "let's go see what this thing can do."

My tech lead started a weekly call where engineers shared what worked, what didn't, and what surprised them. I wasn't even in all of those sessions. I didn't need to be. The point was that curiosity was driving it, not a dashboard. We had real conversations about where AI creates leverage and where it doesn't. I showed them how it had changed my own workflow ... not a demo, not a slide deck, but an actual walkthrough of something I was working on. What I tried. What surprised me. What I still don't trust it with.

I made space for them to bring discoveries back. I let it be visible when I was learning from what they found. We were all in learning mode together, because it was genuinely new to all of us and to the industry at large.

That feedback loop changed what we built next. It told us which workflows were ready for AI acceleration and which ones needed a human in the loop. It surfaced things no adoption metric would have caught, because it was built on a conversation, not a compliance check.

The Posture Is the Strategy

When you're measuring people, they optimize for the metric. When you're curious alongside them, they start optimizing for the thing itself.

When you're measuring people, they optimize for the metric. When you're curious alongside them, they start optimizing for the thing itself.

The difference between a team running on curiosity and one running on compliance is the leader's posture. The same tool produces completely different outcomes depending on who showed up to lead the rollout. One posture gets you adoption numbers. The other gets you engineers who understand the tool well enough to know when not to use it.

My team uses AI constantly now. They also love their work. Those two things aren't in conflict. But they would be if I'd sent the email and called it a strategy.

A mandate is a statement of intent. Intent with no return address tells engineers exactly what kind of feedback the organization wants.

None.

The Question Worth Sitting With

If something in this is snagging for you, the question to sit with is this ... how did your team adopt AI, and who decided how it would be used?

Not which tools they use. Not whether adoption is up quarter over quarter. Who decided ... and how did that decision arrive at the engineer who actually has to live with it every day?

If the answer is a Slack announcement or an all hands slide, you already know what kind of signal came back.

Ask three engineers on your team, individually, what they wish had been different about how AI tools were introduced. Don't defend the rollout. Just listen. Write down what you hear.

The gap between what your dashboard says and what your engineers know is exactly the size of the conversation you haven't had yet.

The gap between what your dashboard says and what your engineers know is exactly the size of the conversation you haven't had yet.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

When You Push for 3x

Jono Herrington — Thu, 02 Apr 2026 13:27:19 +0000

I was at a lunch table with my boss and most of my team, telling the story of how we'd doubled our velocity. I was proud of the number. I told it like it was a win. My team was sitting right there, listening to me describe what they'd done to make that number. They knew. I didn't yet.

That's the part I don't tell in the short version. Not just that velocity got gamed, but that I was the one carrying the number into rooms and setting it on the table like a trophy. Every time I did that, I taught my team something about what I was rewarding.

Death by a thousand paper cuts

Velocity doesn't collapse in one visible moment. There's no incident report. No postmortem. It erodes the way a codebase quietly deteriorates when nobody's watching the right signals.

Tickets start getting larger. Not more complex ... larger. A thing that should be a 2 becomes a 5. A 5 becomes an 8. The complexity hasn't changed. The estimate has. Engineers aren't doing this because they're lazy or dishonest. They're doing it because they are not dumb. They see patterns faster than most leaders give them credit for, and the pattern here was unmistakable.

They despise it too. Nobody wants to spend their career gaming a metric. But the incentive structure demanded it, and I built the incentive structure.

When I asked why velocity dipped in a way that had only one acceptable answer, the team learned exactly what I was rewarding. I wasn't asking a genuine question. I was expressing an expectation.

The team skipped tests. They took shortcuts. Debt compounded sprint by sprint, quietly, in the parts of the codebase that the velocity chart couldn't see. Leadership was happy. I was happy. My team was miserable, doing work they didn't believe in, and watching me celebrate it.

The metric was broken before I started pushing

Velocity was never designed to do what I was asking it to do.

Story points replaced hours estimates because humans are terrible at estimating hours. A task that feels like a three-hour job on a Tuesday morning after strong coffee can turn into a twelve-hour slog on a Friday when the system you're touching has dependencies nobody documented. Hours failed as a productivity measure under that variability.

So we moved to story points. Relative complexity. A 3 means "this is about as complex as the last thing we called a 3." It's a tool for team-level planning within a sprint, not a performance indicator for executive reporting.

The moment velocity gets shared upstairs, that distinction disappears. Leadership doesn't see a planning tool. They see a number that went up or didn't. And teams, watching a number get carried into executive meetings, stop thinking about relative complexity and start thinking about the number. Gaming is not a character flaw. It's a rational response to a broken measurement system.

Every time leadership tries to bring velocity into a planning conversation with me now, I push back. Velocity is the wrong number for that room. A 3-point ticket can take two hours on one day and thirty-two hours the next. Complexity and time are two different things. The number sounds precise. It isn't.

When a planning tool becomes a performance proxy, you haven't solved the measurement problem. You've just moved it.

The same pattern is running on AI right now

GitHub's research on AI-assisted development is the new velocity chart. Their 2022 study showed developers using Copilot completed a controlled coding task 55% faster than those without it. The number is real. Leaders are picking it up, carrying it into planning meetings, and setting it on the table like a trophy.

What the study measured was isolated task completion speed. Developers were given a well-defined problem in a contained environment and watched. What it could not measure was what happens after the code ships ... whether the output integrates cleanly into a real system, whether it creates dependencies the next engineer has to untangle, or whether the shortcuts AI enables are compounding into a maintenance problem that won't surface on any dashboard for another eighteen months.

The pattern is identical. A number that captures something real but incomplete gets elevated into a mandate. The teams receiving that mandate are not dumb. They see what's being rewarded. They optimize accordingly.

When you push for 3x productivity without defining what quality looks like alongside it, you get 3x of whatever path of least resistance produces. That might be 3x the output. It might be 3x the debt. The velocity chart won't distinguish between them. Neither will the AI coding metrics.

The quality thresholds have to come first, before the productivity push. Not as an afterthought, not as a hedge, but as the definition of what success looks like. What does "done" mean? What does "good" mean? What signals tell you that speed is compounding into something durable versus something that will have to be rebuilt in two years?

Those questions don't have glamorous answers. They don't generate the kind of headline GitHub's research does. But they're the difference between 3x productivity and 3x of something nobody wanted.

The dashboard won't tell you. The engineers know.

What I changed

I stopped using velocity as an external number. It lives inside the team, where it belongs, as a planning tool. It doesn't go upstairs.

What goes upstairs instead is outcome evidence. What shipped. What it does. What it unblocked. The kind of answer that requires someone to understand what the work was, not just whether the number went up.

That change made some conversations harder. Leadership wants a number they can track across quarters, and "here's what we built and why it matters" is not as clean as a chart with an arrow pointing right. But a chart with an arrow pointing right was how I ended up at a lunch table bragging about a number my team had learned to inflate while I called it a win.

The leaders pushing hardest for AI productivity gains right now are running the same pattern. The number is real. The study is real. What's missing is the conversation that happens before the mandate ... what does quality look like here, what are we measuring when we measure "done." Skipping it is how you end up with 3x of something you didn't want, and engineers who could see it coming the whole time.

The dashboard won't show you that part. Ask your engineers.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Your AI Rollout Didn't Create Inconsistency. It Revealed It.

Jono Herrington — Wed, 01 Apr 2026 13:24:41 +0000

The PRs were bigger. Review times were flat. And somewhere in week six of the rollout, I started noticing the same problem solved three different ways across three different services. Try/catch blocks blanketing everything in one service. A custom logging wrapper nobody else knew existed in another. Home-built retry logic in a third that duplicated what was sitting two directories over. All technically valid. All completely inconsistent. All generated, at least in part, by the same AI tools we had just given the team.

My first instinct was to fix the AI.

I started thinking about guardrails in Cursor. Tighter prompt guidelines. Review checkpoints before AI-generated code could make it into a PR. We had rolled the tools out without enough constraints, and the codebase was showing it. That felt like a clean diagnosis. The kind where the fix is scoped and technical and doesn't require any uncomfortable conversations.

Then I pulled up the git history.

The inconsistency predated our AI rollout by two years. The try/catch patterns were already diverging before we installed Copilot. The logging wrappers had been proliferating since the last re-org. The retry logic was home-built in multiple services because engineers had been solving the same problem independently, without knowing someone else had already solved it. The shared decision about error handling that we thought we had made in Q2 of the prior year existed in one person's memory and nowhere else.

The AI hadn't created any of this. It had just started moving faster than we had. And when a tool that generates code all day is working on a codebase that never agreed on anything, it scales inconsistency instead of coherence.

I called it a junk drawer with a CI/CD pipeline. The description was accurate. And so was the part I hadn't wanted to admit yet ... we had built the junk drawer ourselves, long before the AI arrived.

What the Industry Is Reporting

This is not a story unique to my team. Engineering teams adopting GitHub Copilot and Cursor without shared architectural standards are reporting the same pattern. More code per day. More inconsistency per sprint. The output is higher, the review burden is higher, and the codebase is drifting faster than it used to because the tool that's supposed to help is working from whatever looked plausible, not from what the team decided months ago in a meeting nobody documented.

The tool is not confused. It is not generating bad code. It is doing exactly what it was designed to do ... find the pattern that looks correct and produce the next token. If your codebase has five patterns for the same problem, the tool treats all five as valid. Because to it, they are. There is no judgment in the model about which approach was the canonical one your team agreed on, because you never made that agreement in a durable form.

AI generates technically valid solutions. It cannot generate coherence that was never there.

What AI adoption does is force the question your engineering culture has been deferring. Teams with strong shared standards see the tools accelerate consistent output. Teams running on informal alignment and tribal knowledge see the inconsistency they've been accumulating suddenly visible everywhere at once, at a pace no code review cadence can keep up with. The tool doesn't create the inconsistency. It reveals it at scale, all at once, in a way that's hard to attribute to any single PR or any single engineer.

The Misdiagnosis That Almost Cost Us Weeks

I spent nearly a week convinced we had an AI tooling problem. That felt like a reasonable read of the evidence at the time. More AI-generated code, more inconsistency in the output ... the logical conclusion was that the tool needed more constraints.

The problem with that diagnosis is that it would have let me off the hook too easily. If the issue was the AI config, the fix was technical. Adjust the settings, tighten the guardrails, maybe roll back some of the autonomy we had given the tool. Scoped, clean, no ownership required beyond the platform side of the org.

What the git history showed was a human alignment problem wearing an AI costume.

We had made decisions in meetings and lost them because we never wrote them down. We had solved problems multiple times across different services because context didn't travel the way we assumed it did. We had tribal knowledge that was actually siloed knowledge ... one team's understanding of the right approach that had never been formalized into something another team could find and follow. The AI had made all of it visible faster than any code review cadence would have caught it.

The fix had to happen at the human layer before we touched anything else.

What We Actually Did

We fixed it before opening a single AI config file.

The first move was documentation, but not documentation as a feel-good exercise. Documentation as decision-making. We went through the patterns that should be canonical and made the choices we had been deferring. Error handling. Logging. State management. Retry logic. For each one, we had the final argument, picked a winner, and wrote it down. Not in a Confluence page buried under three levels of navigation. In markdown files that lived in the repo alongside the code they governed, where engineers would actually encounter them.

That documentation became the source of truth. Not for the team's memory but for the tools.

Once the canonical patterns were written, we built on top of them. Lint rules that enforced the decisions automatically. Architectural tests that would catch drift before it made it past CI. Then we built AI workflows trained on our documented standards, so the tool was generating from what we had decided rather than from whatever looked plausible in the broader training data.

You cannot train AI on standards you haven't written. You cannot enforce standards you haven't decided.

The sequence matters. You cannot train AI on standards you haven't written. You cannot enforce standards you haven't decided. And you cannot decide standards during a crisis by skipping the argument that produces actual alignment. We did all three steps in order, and it made the last step work in a way that jumping straight to guardrails never would have.

The codebase stabilized within weeks.

What the Junk Drawer Was Actually Telling Us

What I keep coming back to is how long it had been there before the AI made it undeniable.

We thought we had consistent engineering practices. We had consistent intentions. The engineers were strong. The individual code quality was fine. But the practices were mostly in our heads, unwritten and unverifiable, passed through conversations that didn't always reach everyone who needed them. The system looked coherent because nobody was moving fast enough to expose the gaps. A slow, carefully reviewed codebase can sustain informal alignment for years before the seams show.

The AI moved fast enough.

The AI rollout didn't break anything that was working. It found what had been quietly not working. The debt we had accumulated in unwritten decisions and informal context was always there. The moment we put a tool on the team that accelerates output by two or three times, that debt came due all at once. Every gap in our shared understanding surfaced simultaneously in the form of valid code that didn't belong together.

This is why the instinct to blame the tool is so easy and so wrong. The tool is honest. It works from what exists. If what exists is a junk drawer, the tool will generate from a junk drawer with remarkable efficiency. You cannot fix that by adjusting the tool's behavior. You can only fix it by becoming the kind of team that a good tool can work from.

For leaders looking at inconsistent AI output right now, the question worth sitting with is not how to constrain the tool. The question is what the output is telling you about the standards you thought you had.

The tool is honest. It works from what exists. If what exists is a junk drawer, the tool will generate from a junk drawer with remarkable efficiency.

AI doesn't create chaos in engineering teams. It inherits theirs.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Your Code Is Moving. Your Judgment Is Not.

Jono Herrington — Tue, 31 Mar 2026 13:11:04 +0000

The production memory issue didn't reveal itself as a speed problem at first. It arrived as a debugging session that should have taken thirty minutes and kept stretching. A senior engineer at the terminal, working through the layers the way he always had, waiting for the pattern recognition to fire. Six months earlier it would have been automatic. Now it arrived the way a word does when it's on the tip of your tongue and keeps almost forming.

He wasn't coasting. He was busy in ways that looked exactly like leadership. Sprint planning. Stakeholder management. The roadmap reviews that had to happen. The calendar was full of things that mattered. What he didn't see was that the calendar had quietly substituted for something else, and that substitution had a cost that doesn't show up until a moment like this one.

The instinct to debug wasn't gone. It was soft. And soft is the version that's hard to catch because the output keeps looking fine right up until it doesn't.

Six months of distance had done what six months always does.

The Number Worth Actually Thinking About

GitHub's research found that developers using Copilot complete tasks up to 55% faster. That statistic tends to land as good news, and in isolation it is. The tools work. Adoption makes sense. The productivity case is solid.

But 55% faster code means something downstream from the code itself. It means more decisions per day embedded in pull requests. More architectural choices shipping without a deliberate pause. More places in the system where someone with real context needs to evaluate whether what just merged connects to what's being built on three other continents, whether the pattern holds under load, whether the trade-off that seemed obvious in one service is going to be expensive when replicated across twelve of them.

The code is moving. The evaluation cycle is not keeping up.

This is the gap that doesn't have a metric yet: not whether the code ships faster, but whether the judgment keeping pace with it is sharp enough to catch what's compressing. A 55% velocity increase doesn't arrive with a corresponding increase in review depth. It arrives with the same humans, the same available hours, the same leader who may or may not have been staying close to the work.

The code is moving. The evaluation cycle is not keeping up.

Leaders who were already drifting from technical proximity before AI arrived are now falling behind at a pace that drift used to take years to build. The calendar didn't change. The speed of what's underneath it did.

That's the thing about a full calendar. It doesn't feel like drift. Every meeting has a purpose. Every conversation moves something forward. From the outside, and usually from the inside too, it looks exactly like the work.

I've Been on the Wrong Side of This

I've retreated from technical proximity more than once. Not as a decision but through the way months accumulate when you're leading an engineering organization across three time zones and three continents. The drift doesn't announce itself. It settles in through small things that each feel reasonable on the day they happen.

The 1:1s that gradually become status reports because somewhere along the way you started asking about progress instead of approach. The technical explanation you follow at about sixty percent and tell yourself is close enough. The sprint that looks good on Friday and leaves you realizing, two weeks later, that you don't actually know how the hard problems got solved.

The signal I trust most is this: when did something in the codebase last surprise me? Not concern me. Not require action. Just genuinely catch me off guard in a way that meant I was close enough to see something I hadn't expected.

When I can't answer that question cleanly, I know I've drifted.

The trouble with drift is that everything around it keeps looking fine. PRs get merged. Features ship. The sprint board fills and empties in the right rhythm. You can mistake all of that motion for proximity to the actual work. And for a while, the gap between where your judgment actually is and where you think it is stays narrow enough that nothing reveals it.

AI closes that window. Code moving 55% faster means the gap between your actual evaluation capacity and what needs evaluating grows faster too. Drift that used to be invisible for a year is now surfacing in months.

What I'm Actually Looking for in a Pull Request

I still read pull requests every week. Not to catch syntax. My engineers are better at that than I am on most days, and AI is catching more of it than any reviewer has the hours to chase.

I read them because a PR is a decision record, and decision records are what I'm actually managing. Not lines of code. Not ticket counts. The thinking that went into the approach. The trade-offs the engineer saw. The choices that got made quietly inside a feature and will shape what's possible six months from now when someone needs to extend it.

Leading across three continents means the clearest signal I have about whether the judgment on my team is sound is not the sprint review or the roadmap deck. It's the PRs. That's where I can see whether the decisions being made in one geography connect to the architecture decisions being made in another. Whether the error handling patterns we agreed on are actually holding under delivery pressure. Whether an engineer is solving the problem in front of them in a way that creates a bigger problem two decisions from now.

When an engineer is using AI well, the PRs show it. The reasoning is tighter. Edge cases get considered. The approach names its trade-offs and sometimes names the ones it decided against. When an engineer has shifted into mostly directing and reviewing output without doing the underlying thinking, the PRs show that too. The decisions are there, but the reasoning behind them is thin. The code compiles and passes review and ships. And you can't tell whether the engineer understands why the approach works, or whether they'd make the same judgment call correctly in a different context without the assist.

The second version isn't always slower. It's often faster. The problem is what it's building toward.

That's still the best signal I have about whether the judgment is sound. You can't see it if you've stopped reading.

That's still the best signal I have about whether the judgment is sound.

The Multiplier Goes Both Ways

You'll hear that AI raises the floor. Even weaker engineers ship more. The baseline rises. The ceiling matters less. This is the optimistic read, and it's not wrong.

It's also not the whole story.

AI is compressing the margin for judgment debt. Yes, the floor rose. But so did the speed at which poor judgment compounds. A leader who isn't close to the work doesn't miss things at the rate they used to. They miss things at the speed the code is moving, which is meaningfully faster than it was two years ago.

The better frame is that AI is a multiplier, and multipliers don't choose sides. Whatever state your technical judgment is in when AI arrives in your team's workflow ... sharp because it's been fed by proximity, by reading the PRs, by staying close enough to the system to actually see what's happening ... that's what gets multiplied. Whatever state the drift has left it in ... soft at the edges, slow to pattern-match, confident in its own competence without the proximity to back it up ... that also gets multiplied.

The engineers using AI as a tool for thinking faster are compounding their judgment at a rate that would have been impossible without it. They're genuinely ahead in ways the velocity dashboard is not built to capture. The leaders and engineers using it to avoid the thinking are accumulating judgment debt at a speed that also would have been impossible without it.

The gap between those two groups is widening faster than most organizations can see.

The Part That Doesn't Come Back

The senior engineer from that production incident figured it out. He got back in the code. Rebuilt the proximity. Let the codebase surprise him again through deliberate reps over time. The instinct came back, slowly, because technical instincts are recoverable when you're willing to do the work.

What doesn't come back is the time the code was moving without anyone close enough to catch what it was doing.

The skill atrophy problem is a real one, and it compounds in ways most teams aren't tracking. But atrophy is individual. The evaluation gap is structural. It's what happens when the speed of production outpaces the capacity of the people responsible for evaluating it, and nobody notices because the code keeps shipping and the sprint keeps moving and the calendar stays full of things that look exactly like leadership from the outside.

AI is a force multiplier. What it's multiplying is whatever judgment your leaders still have.

AI is a force multiplier. What it's multiplying is whatever judgment your leaders still have.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

The Atrophy Problem

Jono Herrington — Mon, 30 Mar 2026 14:44:19 +0000

There's a moment that happens quietly, not during a crisis or a late night deploy, but in the middle of an ordinary 1:1. Your engineer is walking through something technical, explaining an approach, and somewhere in the second minute you realize you've been nodding without actually following. Not because you stopped caring. Because the thread between your brain and the work has grown thin in ways you haven't been tracking.

I've had that moment. More than once. Not as a conscious choice to disengage but through the accumulation of small decisions about where to put attention over a stretch of weeks. The calendar fills up with reviews, cross team coordination, and strategic conversations. The individual time in the code gets shorter, then rarer. And the drift doesn't announce itself. It just settles in.

That moment used to belong to engineering managers who had spent too long in spreadsheets and leadership offsites. The senior engineer who drifted into pure process. The VP who still introduced himself as technical but hadn't opened a PR in two years. The drift was slow, mostly invisible, and if you asked them directly, they'd tell you they were still close to the work.

Now there's a new accelerant.

The Pattern Showing Up in Engineering Threads

A few weeks ago I spent time reading through a thread of engineers reflecting on what AI directed development had done to their instincts. Not what it had done to their velocity or their output quality. Their instincts.

One engineer put it precisely. He had switched to mostly directing AI agents, reviewing generated output, and approving pull requests. Then a memory issue showed up in production. Real debugging work. The kind that requires you to hold a mental model of what the system is doing across several layers at once. The instinct that tells you where to look first wasn't there. Not gone completely, but slow. Like coming back from a long vacation and trying to find things in your own kitchen.

He was a senior engineer. He had built systems before. The skill hadn't disappeared in a week. It had eroded quietly because the daily reps that maintained it had stopped.

Reading through the rest of the thread, the same pattern kept surfacing with different details. Engineers who could still read code, could still approve PRs, could still talk fluently about architecture. But the deeper instincts ... the ones that come from having written enough code to recognize when something smells wrong before you can articulate why ... those were getting soft. And the people who had it the worst were the engineers who had been most productive by every surface measure.

The muscle memory for how long things actually take, why certain patterns break under load, what a subtle bug smells like before you can see it ... that erodes when you stop writing.

This used to be a senior leadership problem. You move into strategy, you stop coding, your instincts slowly drift. Everyone understood that trade-off. Now the same dynamic is compressing into a much shorter timeline because AI assisted workflows can remove the hard thinking from a day's work without removing the appearance of productivity.

Two Ways to Use a Tool

There are two fundamentally different relationships with AI tools, and they produce opposite outcomes.

Using AI to move faster through problems you understand sharpens you. You bring the judgment, the tool accelerates the execution, and the feedback loop stays intact. You're still doing the thinking. You're still debugging, still making architectural decisions, still feeling the resistance of the problem. The tool handles the parts that were always mechanical. The judgment is still yours.

Using AI to skip problems you don't want to think through does the opposite. The output still arrives. The velocity numbers still look fine. But the thinking that produced judgment in the first place is being quietly outsourced, and judgment doesn't maintain itself in storage.

The version most engineers tell themselves is that they've moved up the value chain. They're doing higher order thinking now. Directing rather than implementing. That framing can be true. The question is whether the directing is backed by the judgment that only comes from having done the implementing long enough to internalize what the hard parts actually are.

The tricky part is that both approaches look identical from the outside. PRs get merged either way. Features ship either way. The decay happens below the line of what any dashboard is measuring.

The relationship you have with AI tools determines whether they make you better or make you dependent.

What Atrophy Actually Looks Like

I started tracking the signals in myself years ago, long before AI was part of this conversation. The 1:1s that had slowly become status reports because I was asking "what's going on" instead of "walk me through the approach." Nodding through a technical explanation I was only partially following. Going three weeks without being genuinely surprised by something in the codebase.

None of those signals announce themselves loudly. They're a slight dulling. The gap between where you think your instincts are and where they actually are.

For engineers in mostly AI directed workflows, the same signals appear earlier and faster. The days that feel productive because the output is high but the actual thinking has been thin. The growing hesitation before jumping into a debugging session without an assist. The way complex problems start to feel unfamiliar not because they're harder but because the pattern recognition that used to make them tractable is getting rusty.

The industry hasn't built a metric for this yet. Which means most people won't notice until they can't ignore it.

Staying Close

I still read pull requests. Not to approve syntax, and not to micromanage the decisions engineers are making. I read them to understand how the team thinks. Where connections are getting made across the codebase, where they're not, whether the patterns we aligned on are holding under real delivery pressure.

Staying that close to the system means that when something matters, the instinct is there.

A bug came in a few months ago that was creating a bad customer experience. Instead of routing it through the normal support path, I checked the logs. Found a data issue. Had the customer's experience fixed in thirty minutes. That wasn't remarkable engineering. It was just what's possible when you haven't let the thread between your brain and the system go slack.

That's the thing about technical instincts. They don't disappear all at once. They degrade gradually through disuse, and they come back gradually through deliberate reps. The engineers who will navigate the AI era best are not the ones who resist the tools. They're the ones who stay intentional about which parts of the thinking they keep.

For an engineer, that might mean taking on at least one problem per sprint that requires real debugging without an AI assist. Not as a purity exercise but as maintenance. For a leader, it means staying close enough to the work that the gap between what you think you know and what's actually happening stays narrow. Reading the PRs. Getting into the logs. Letting yourself be surprised by the codebase sometimes.

The tools should be doing the mechanical work faster. They should not be doing the thinking that produces judgment.

The tools should be doing the mechanical work faster. They should not be doing the thinking that produces judgment.

The Question Worth Asking Right Now

If the AI stopped working tomorrow, could you still do the job you were hired for?

Not a version of it. The actual job. Could you debug a production issue without an assistant? Could you architect a system with just your own reasoning? Could you review a PR and have a real opinion about the approach, not just whether the tests pass?

For engineers, this question is already uncomfortable in some orgs. For leaders who have been directing AI workflows from a distance, it may be more uncomfortable still. For either, the discomfort is the signal.

Not that you're failing. Not that you need to abandon the tools. Just that the drift has been happening and you haven't been watching for it.

AI is writing code now. What it can't write is the years of being wrong about systems and learning from it, the instinct built from having felt the weight of bad architectural decisions, the judgment that only exists because someone did the hard thinking long enough to make it automatic.

That part is still yours. The question is whether you're keeping it.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Engineering Is a Team Sport. Your Incentives Aren't.

Jono Herrington — Sun, 29 Mar 2026 17:35:53 +0000

I have a game tape dashboard. It tracks constraints and throughput across my engineering team ... PR cycle times, review patterns, where work slows down and where it moves. I built it because I believe engineering is a team sport, and team sports need game film. You can't coach what you can't see.

A few years into leading my current team, I opened that dashboard and saw something I couldn't ignore. Pull requests with over a thousand lines of code were taking, on average, five minutes longer to review than PRs with two hundred and fifty to five hundred lines. Five minutes. For four times the code.

The math told the story before anyone had to say a word out loud. PRs were sitting for days. When reviews did happen, they were almost always handled by the same one or two people. Everyone else had their own features to ship.

The math told the story before anyone had to say a word out loud.

The System I Inherited

I hadn't built this team from scratch. I walked into an incentive structure that had been in place long enough to become invisible ... one of those systems that nobody designed on purpose and nobody questions because it's just always been there.

Engineers were measured by ticket throughput. How many you closed. How fast you moved from one to the next. Whoever did the most tickets won. That was the implicit scoreboard, even if nobody said it in a meeting or wrote it in a doc.

It's a seductive way to measure a team when you're under delivery pressure. Tickets closed feels like progress. Velocity trending upward feels like health. And for a while, it is. But a system designed to maximize individual throughput produces exactly one thing when applied to work at the team level like code review ... engineers who are very good at protecting their time from other people's problems.

When someone else's PR sits in the queue, that's not your problem. Your problem is the ticket in front of you. The one after that. The sprint goal attached to your name. Someone else being blocked is unfortunate, but it doesn't change your scoreboard. So you keep moving.

Earlier in my career I was the manager who pulled up a velocity chart in planning and pushed for the number to go higher. The team complied. Velocity climbed. Leadership was happy. And quietly, underneath all of it, the codebase was accumulating debt that didn't show up until something broke. I set the expectation and got exactly what I asked for.

Incentives work. Just not always in the direction you intended.

Why Every Process Fix Misses

The standard playbook for slow PR reviews follows a familiar script. Break your work into smaller PRs. Create better review templates. Set up a rotation schedule so the same two people aren't carrying the load. Add SLAs with automated reminders. Some of these things have limited value. None of them address the actual problem.

If your performance is still measured by what you ship individually, a review rotation schedule just means it's your turn to pull time away from shipping. The calendar entry exists. The incentive hasn't moved. So the review gets done ... technically. But it gets done the way you'd expect. Skim. Approve. Move on. The queue clears and the same pattern comes back within a quarter.

When you treat an incentive problem as a process problem, you get process-shaped results. The symptom quiets down. The cause stays exactly where it was.

What Actually Changed

My first instinct when I saw that dashboard data was to reach for a new metric. Measure review participation alongside ticket throughput. Track who was reviewing, how often, how quickly. Put the numbers somewhere visible.

The problem is that metrics can be bluffed. Give people a number to hit and they will find the path of least resistance. If review participation becomes a tracked metric, you'll get reviews. You won't necessarily get reviews that actually catch anything. You'll get the five-minute rubber stamp dressed up as engagement, and your dashboard will look healthy while quality stays exactly where it was.

So instead of a new metric, we built a behavior.

When an engineer opens a PR, they drop it in a dedicated channel. The team sees it. Not as an item on a rotation list or an obligation attached to a schedule, but as a ball in play. The way I described it to the team was recovering a fumble in football. Somebody put something valuable on the field. The whole team swarms.

What made it work wasn't the channel. It was what the channel represented ... a shift from "your work is yours until it merges" to "the work belongs to all of us until it ships." Reviewing a teammate's PR wasn't taking time away from your sprint anymore. It was part of your sprint. Getting someone unblocked counted the same as closing your own ticket, because the thing we were actually measuring was how fast the team moved work through the system.

The senior engineers who had been too busy to review suddenly had time. Because now someone else being blocked was their problem too.

We went from review cycles that ran three days to same day.

We went from review cycles that ran three days to same day.

The Number That Actually Matters

I come back to the game tape dashboard here. The metric I actually care about is team throughput, not individual velocity. How fast does work move from opened to merged to deployed, across the whole team, over a rolling period of time.

Individual velocity can look healthy while team throughput quietly collapses. One engineer closing six tickets while four of their teammates' PRs sit unreviewed is not a win. It's a transfer. You moved the constraint from one column to another and called it productivity.

The fastest teams I've built had one thing in common. Helping a teammate ship counted as shipping. Not rhetorically. Not in the values doc. In actual performance conversations, in how growth was talked about, in what got recognized out loud.

That's where the behavior change lives. Not in the channel, not in the dashboard, not in any rotation schedule. In what your engineers believe will happen in their next performance conversation if they spend an afternoon doing thorough, careful reviews instead of closing their own tickets.

If the honest answer is "nothing good" ... you already know what to fix.

It's not the process.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

AI Is Shipping Your Blind Spots

Jono Herrington — Sat, 28 Mar 2026 15:43:30 +0000

I shipped a spec that missed three edge cases a QA engineer would have caught in five minutes.

Not buried edge cases. Not obscure branching logic deep in a data model. Surface stuff. The kind of thing that lives at the front of the test plan, the first page of the test run, so obvious in hindsight that explaining it in a retrospective is the most embarrassing part. There was no incident. No postmortem. Just a dev cycle quietly bleeding out through holes that should never have made it past the spec.

The QA team's test cases weren't ready yet. That happens in spec-driven development ... teams don't always move in lockstep, and some functions are still prepping when others are already building. I know this. I've been managing that coordination for years across teams on three continents. But knowing the gap existed didn't stop me from walking straight into it. The happy path was solid. The spec covered the main flow perfectly. It just never got the perspective of someone whose entire job is to find what the happy path misses.

I talk about engineering as a team sport. I wrote that spec alone.

The Problem Nobody Is Naming

AI is exceptional at amplifying output. It is considerably less exceptional at amplifying perspective.

When you write a prompt, you bring your mental model, your assumptions, your frame. The model responds inside that frame. It does not volunteer the QA engineer's instinct that a happy path spec almost always breaks on state management. It does not bring the DevOps engineer's quiet read on what happens to this flow under load at 2am. It gives you a thorough, considered answer to the question you asked.

The question you asked was incomplete.

The feedback loop is the problem. And moving faster with a broken feedback loop is just moving faster toward the wrong thing. If you are using AI to accelerate delivery without fixing the loop, you are not shipping product. You are shipping your assumptions.

AI doesn't have blind spots. You do. And it will ship yours at scale if you let it.

The AI productivity conversation tends to live at the tool layer. Are we using the right model? Are we structuring prompts well? Are we reviewing output carefully? Those questions matter. But they all assume the bottleneck is technical. Most of the time, the bottleneck isn't technical.

What I Built Instead

After that spec, I stopped treating AI as a solo collaborator. The QA timing gap wasn't going away. But I had no system for bringing the QA perspective into the spec when QA wasn't in the room yet. I built a system of personas.

A business analyst. A technical writer. A product owner. A QA engineer. A DevOps engineer. Not generic role labels ... personas built from years of being in rooms where things went sideways. Each one carrying a specific lens, a specific vocabulary, a specific set of questions that function inside a given layer of the work.

When I work through a spec now, I run it through each persona before it ever touches a dev. The QA engineer asks about the edge cases. The DevOps engineer asks about the failure modes. The product owner asks whether the spec actually solves the user's problem or the problem I described. The business analyst asks what we're assuming about the customer that we haven't verified.

Each angle surfaces something the previous one missed.

Each persona carries the failure experience of someone who has watched that layer break. You cannot build that from one discipline. A specialist knows what strong looks like in one layer. They don't know what the person two layers above or below them is watching for. The system works because it does not stay in one lane.

Expertise is real. Depth still matters. But depth in one function is not a substitute for a system that crosses functions.

The Loop That Actually Matters

Everyone is focused on making their prompts better. Structuring outputs, iterating on instructions, getting sharper at the technical mechanics of working with models. That is not wrong. It is also not the leverage point.

The feedback loops that make AI powerful aren't technical loops. They're leadership loops.

Knowing where your judgment needs to be in the loop and where you can let the model move without you. Knowing how to look at a piece of output and give precise feedback that actually improves the next iteration ... not just "this isn't right" but "this missed the failure mode that happens when the user doesn't complete step two."

That kind of feedback requires a mental model that spans the whole system. You cannot shape AI output well if you only understand one layer of what you're building.

The engineers I've seen struggle most with AI are not the ones who lack technical skill. They're the ones who have never had to advocate for the whole system. They have spent their careers going deep in one place, and now they are prompting from that one place ... and getting output that is technically complete and strategically incomplete.

Staying close enough to the codebase to have an informed view has always mattered. But the ability to hold multiple functional perspectives at once matters more now than it ever did. Because AI will faithfully execute whatever perspective you bring.

The quality of your perspective is the constraint.

Prompting Is a Delegation Skill

Every prompt is a delegation decision. You're deciding what problem to hand off, how to frame it, what constraints to provide, and what you're going to do with the output. The brief determines the outcome.

Poor delegation produces rework. Strong delegation produces leverage.

The persona system makes that mandatory. Before you hand work off, you check the frame. You ask what the QA engineer would see, what the business is actually trying to accomplish, what breaks under pressure. Then you brief.

AI lets you do this at speed. The catch is you have to already have the range to model those perspectives. If you don't have the range, the speed works against you.

The Blind Spots Are Ours

Blaming AI for your blind spots is like blaming the mirror for what you look like.

The model isn't hiding your gaps. It's reflecting your frame back at you with precision. When the output misses something important, the miss was almost always present in the input. In the assumption you didn't surface. In the edge case you didn't think to specify. In the angle you left out of the room.

The spec I shipped missed three edge cases because I wrote it alone, from one perspective, with one set of mental models. The QA team wasn't in the room. AI was. AI helped me write that spec faithfully. It did exactly what I asked. The tool wasn't the problem.

The solution was to build a system that forces multiple perspectives into every consequential piece of output before it ships. To do with AI what strong teams do with humans ... bring more than one angle to the table, on purpose, every time.

That's a leadership problem. Not a technology problem. And it's one that grows in proportion to how much AI you're putting into the loop.

Every prompt you write is one perspective. The question isn't whether AI can do the work. It's whether you have the range to catch what it misses.

The blind spots aren't AI's fault. They're yours.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Velocity Is Up. Ask Why Your Team Is So Quiet.

Jono Herrington — Fri, 27 Mar 2026 14:31:40 +0000

The engineer has been at the company three years. Senior. Knows the system well. Knew it, anyway. The codebase has been moving fast since the AI tools arrived. New services, new patterns, new surface area every sprint. The features are shipping. The metrics look clean. Someone in a leadership meeting said the word "10x" and nobody pushed back because the PRs are right there on the board, merged and closed. I was in those rooms. I said the right things about momentum.

Then something breaks. And the engineer sits down to debug it.

Six months ago, they would have known exactly where to look. Not because they're exceptional. Because they wrote the relevant code. They had the context in their hands. The muscle memory was there. You build that over years of writing, breaking, fixing, and writing again inside the same system. It lives in you before you think to use it.

Now the code was generated. The patterns aren't theirs. The structure is mostly right. And the engineer is staring at something they technically own that they don't understand at the line level. So they do what you do in that situation. They reach for AI to help them debug it.

AI writes. Human reviews. Human can't debug. Human asks AI. AI writes more.

That loop is what nobody named when the mandate came down.

The Shift Nobody Announced

The throughput is real. I'm not disputing the board.

What the board doesn't show is what the work actually became.

Before AI, a senior engineer's edge wasn't just technical skill. It was orientation. Knowing where to go. When something broke and drug them out of bed, they didn't reason from first principles every time. They had a map built from years of writing the same system. That map was the actual asset. The thing that made them genuinely senior.

AI adoption at speed is quietly erasing it.

AI is generating new surface area faster than anyone can internalize it. The senior engineer reviewing a PR today may have never touched that module. Because AI wrote it. Because the sprint was moving and there was no reason to slow down to build context when the model could generate the function in forty seconds.

The result is a codebase that is nominally owned by the team and practically understood by no one.

That's not on the engineers. That's what happens when you optimize for output faster than the team can absorb it.

The Cycle

An engineer receives an AI-generated function to review. They evaluate it. Structure, logic, edge cases. They approve it. Time was saved. Velocity moved.

Three weeks later something breaks in that function. The engineer who approved it opens the file. The code isn't wrong, exactly. But it's not theirs. They don't have the mental model for why it's structured the way it is. The instinct they would have had if they'd written it ... the one that says "this will fail under this condition" ... isn't there. Because instinct comes from authorship. You can't review your way into it.

So they reach for AI. Ask it to help trace the bug. AI generates a hypothesis. The engineer evaluates it. Maybe it's right. Maybe it isn't. Either way, another layer of generated content sits in the stack that nobody fully owns. The loop deepens.

I'm not just describing what I've watched happen on teams. This is something I've felt. When I go into a codebase to debug something I reviewed but didn't write, the instinct I used to carry isn't there. I reach for AI. The cycle continues. The more I've thought about it, the more I understand it's not a skill gap. It's a context gap. And context doesn't transfer through review.

For many senior engineers, the contrast is sharp and getting sharper. Junior engineers are building their baseline in this environment. The new way of working is just the way working works. For the people who built their careers on knowing exactly where to go, that loss is unmistakable. They feel it every time they open a file they technically approved but don't recognize at depth. They feel it in every debugging session where the first instinct is no longer instinct at all.

They just don't have permission to name it.

Instinct comes from authorship. You can't review your way into it.

What Leadership Sees

Leadership sees the board. PRs merged. Features shipped. Velocity at a number that would have seemed ambitious eighteen months ago. Someone says "AI is working." Everyone nods.

The team is quiet.

Not the quiet of focus. Not the quiet of flow state. The quiet of people navigating something unfamiliar, on the fly, without a compass, and without permission to say it's hard.

Engineers are producing output. They're also making up the methodology as they go, session by session, because nobody told them how to review AI-generated code at the pace they're being asked to review it. There's no playbook for the verification load. There's no training for the judgment work that replaced the writing work. There's a mandate and a dashboard and a stand-up.

The engineers are building the plane while flying it. Leadership is measuring how fast the plane is going.

I've heard the same story from enough people in enough orgs to know this is not an edge case. It's the pattern.

Why Mandates Make It Worse

An AI mandate doesn't just add a tool. It adds the pressure of compulsion to the fog of unfamiliarity.

Engineers who are already figuring out how to do this are now figuring it out under an org-level instruction to move faster. The pressure is real. The permission to name what it costs is gone. You don't raise your hand in an all-hands and say "I used to know this codebase and now I don't" when the company just announced AI is a strategic priority.

The senior engineers feel it most. The ones who built their careers on knowing the codebase. On being the person people came to when something broke. On having that orientation so internalized it felt like instinct. They're the quietest ones in the room. Not because things are fine. Because what they're experiencing doesn't fit the narrative, and they're not going to be the person who slows down the momentum.

That silence is not adaptation. It's people absorbing a loss they were never given language for, while being told the change is unambiguously good.

When the engineers who used to push back in planning stop asking why ... when the people who questioned the framing of a problem start accepting it and jumping straight to solution ... that's not focus. That's depletion showing up as compliance. The same signal I described in the cognitive load piece. The pattern doesn't stop at the individual day. It moves into the team's relationship with its own codebase.

That silence is not adaptation. It's people absorbing a loss they were never given language for, while being told the change is unambiguously good.

What This Requires From You

I'm not arguing against the tooling. I use it. The gains are real.

What I'm arguing for is understanding what your team is actually inside of.

Your senior engineers are not struggling because they can't adapt. They're struggling because something was taken from them that nobody acknowledged. The muscle memory. The orientation. The knowledge of exactly where to go when something breaks at an hour when you'd rather be anywhere else. That was years of accumulated context. AI adoption at speed is outrunning the ability to rebuild it. And mandates don't leave room to say so.

Before you read another velocity dashboard, ask your team one question. Not about output. About navigation.

When something breaks, do you know where to look? Are you going there because you know it, or because you're using AI to find your way back in?

If the answer is the second one, you are not watching a team that's adapting smoothly. You are watching a team in the middle of a transition they haven't been given room to name.

Meet them there. Not with a policy update. Not with a new process. With a conversation. What has actually changed for you? What do you own that you didn't write? What do you not know anymore that you used to? What does debugging feel like now compared to a year ago?

Those answers won't show up in the sprint summary. They will show up in who's still on your team in twelve months, and what shape they're in when they are.

Those answers won't show up in the sprint summary. They will show up in who's still on your team in twelve months.

The Quiet Is the Data

The throughput is real. The sustainability is not something you can see on the board.

The work didn't shrink. It shifted. From creation to judgment. From authorship to evaluation. From knowing exactly where to go to reaching for a tool that didn't write the code you're trying to understand. It is a different category of work, running at a different pace, on a team whose muscle memory was built for something else.

Your team went quiet after AI arrived. That quiet is not a sign things are going well. It's a sign your team is carrying something they don't have permission to put down.

Stop celebrating velocity. Start asking your team what they actually know anymore.

That question is harder than reading the dashboard. It's the only one worth asking before you find out the hard way.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Your Best Engineers Are Tired

Jono Herrington — Thu, 26 Mar 2026 15:42:22 +0000

What looks like productivity acceleration is quietly erasing the recovery time built into every engineering day.

I started noticing it in my engineers first. In one-on-ones. In how the same conversations sounded different toward the end of a sprint. I heard it enough times across enough people that I started looking for it deliberately. Then I noticed it in myself. I'm not coding more than half my hours. My work is reviewing, deciding, evaluating ... across systems, teams, timelines. And I was still running out of steam by Wednesday. We went from running a marathon to sprinting a marathon. Same course. Same distance. But you can't sprint a marathon and finish the same.

Recovery Time Was Hidden in the Friction

Before AI, engineering had something built into it that nobody named. Recovery time.

Not blocked time. Not wasted time. Recovery time.

The build step that took four minutes. You'd flip to a browser tab, refill your coffee, let your brain sit in neutral for a moment. Not thinking about architecture. Not evaluating anything. Just waiting.

Writing boilerplate by hand was tedious. But tedious was the point. Low stakes. Low cognitive demand. Your hands typed while your mind coasted. There was no decision in it. Just the satisfying click of producing something familiar.

Refactoring a module you knew felt almost meditative. You knew the code. You knew what needed to move. The work had grooves. Your attention could settle into something easy while the harder thinking finished processing in the background.

None of this felt like rest. Even to the engineers themselves.

But it was rest. The throttle built into every engineering day.

Those pockets of low demand weren't friction to optimize away. They were the throttle that kept a sustainable pace sustainable.

What AI Actually Replaced

AI didn't just speed up those tasks. It replaced them. Not with the same tasks done faster ... with entirely different tasks.

The build runs in 45 seconds now. Those four minutes are gone. And they've been replaced with four minutes of reviewing what the model generated.

The boilerplate writes itself. The time you saved is filled with evaluating whether it fits your architecture, follows your conventions, doesn't introduce patterns that will calcify into problems eighteen months from now.

Every minute that used to be low stakes is now high stakes. Does this output pass the test. Does it pass the test and make sense. Does it make sense and not create downstream debt.

Every minute is an evaluation.

There's no coasting anymore. There's no meditative refactoring. There's no four minute reset. There's a stream of decisions, each one flowing directly into the next with no gap in between.

Engineers spent years training one cognitive muscle. The traditional approach to programming built a specific rhythm into the work ... heavy judgment, then recovery. Heavy judgment, then recovery. The boring tasks were the low-intensity reps between hard sets.

Then came the mandate. Overnight, it demanded a completely different muscle. The training cycle that built the first one had no equivalent for the second. The new game started at full intensity immediately.

The Mental Model Most Leaders Are Running

If you lead engineers, you're carrying this belief ... AI saves time, so engineers should have more capacity.

It's a reasonable belief. It just doesn't map to what's happening.

AI compresses effort so engineers hit cognitive walls earlier.

Compression is different from reduction. If a sprint used to contain forty hours of varied cognitive demand, AI compresses the low demand portions to nothing. The engineer doesn't end up doing less. They end up doing all of it, in less time, with no recovery built in.

The output looks the same for a while. Maybe it looks better. The metrics move. The velocity numbers read well. I've written about what those numbers actually measure and what happens when leaders mistake them for health. The pattern is consistent ... things look fine until they suddenly don't.

AI compresses effort so engineers hit cognitive walls earlier.

What It Looks Like in Practice

Cognitive overload doesn't announce itself. It doesn't look like someone staring at a blank screen. It looks like things getting approved that shouldn't. Pull requests that should have been flagged, that weren't. Architectural shortcuts that nobody questioned in review, even though three people in that room would have caught the same thing six months ago.

The quality of decisions drops before the quantity of output drops.

By the time the output is visibly degraded, the problem has been compounding for weeks.

One signal worth watching ... when your best engineers stop asking why in planning. When the people who used to push back on the framing of a problem start accepting the framing and jumping straight to solution. That's not a focus improvement. That's cognitive depletion showing up as compliance.

The engineers who are best at their jobs are also the most likely to push through the wall without telling anyone. Not because they're hiding it. Because their mental model for feeling off is "I need to work harder to get back on top of things." They're trying to solve their way out of the problem that is the problem.

The Question Worth Asking

Look at your team's calendar for tomorrow. Not the meetings ... look at the time engineers spend building.

Ask one question about that time. Where are the moments when nobody is asking them to evaluate anything?

Where is the work that doesn't require judgment to complete? Where is something low stakes, familiar, with grooves?

If you can find it ... protect it. Don't fill it with more AI generated output to review. Don't schedule a ceremony into it. Let it be what it is.

If you can't find it ... you're not looking at a capacity problem. You're looking at a depletion problem. And it will surface on your team before it surfaces in your metrics.

What This Actually Requires

This isn't an argument against AI tooling. The tooling is useful.

Nobody is built for sustained high stakes evaluation all day. There is a ceiling, and it isn't a software limitation. What AI changes is how fast you reach it.

Remove the throttle without acknowledging what the throttle was doing ... and the pace becomes the problem.

Give engineers work that costs less to evaluate. Protect the moments when judgment isn't required. Design the pause into the day now that the workflow stopped doing it automatically.

Some of that is task design. Some of it is how you structure rituals and reviews. Some of it is recognizing that when an engineer asks for a day to work on something slower, they are not being resistant to change. They are self-regulating. Let them.

Your job as a leader is not to maximize the utilization of your engineers' cognitive capacity. It's to sustain it.

Your job as a leader is not to maximize the utilization of your engineers' cognitive capacity. It's to sustain it. If you can't find the recovery time in your team's day, you're not running a productive engineering org. You're running a depletion schedule.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

AI Didn't Break Your Culture. It Exposed It.

Jono Herrington — Wed, 25 Mar 2026 19:07:20 +0000

An engineer pushes back on a decision. The response: "ChatGPT recommended something else." The tell isn't the recommendation. It's that they reached for an oracle instead of an argument. You're not watching an AI problem. You're watching a culture problem that predates the model by years.

I've been the oracle.

The Oracle Was Always There

Before ChatGPT, it was Stack Overflow. Before Stack Overflow, it was the one senior engineer who had been around longest. Teams find oracles when they don't have frameworks. They fill the decision vacuum with whatever authority is nearest.

ChatGPT is just the most accessible oracle ever built. It's confident, available at 2am, and it never makes you feel stupid for asking. Of course engineers reach for it.

The question is what they're replacing with it.

If your team has no shared framework for architectural decisions, no clear authority structure, no agreed-on method for weighing tradeoffs ... "ChatGPT recommended something else" is just the latest version of "Google says" or "I read a blog post" or the last tech talk someone attended. The source changes. The abdication of thinking stays the same.

That's the culture problem. And it was there long before the first API call.

One flavor of team gets hit hardest. The team that's technically accomplished but has never had to articulate its reasoning under pressure. The team where the senior engineers make the calls and everyone else executes. The team where architecture reviews are about performance, not inquiry. Those teams look fine until the oracle arrives and the emperor's new clothes problem becomes impossible to ignore.

A lot of engineering culture runs on borrowed credibility. Conference talks from FAANG engineers with entirely different constraints. Benchmarks run on workloads nothing like yours. Technical opinions absorbed as gospel without anyone stress-testing the assumptions. Teams learn to cite sources instead of building judgment. ChatGPT is the endpoint of that trajectory ... a perfectly confident authority on everything, available for anything, with zero friction and no accountability for being wrong.

When a culture already runs on borrowed credibility, an always-available oracle doesn't change behavior. It accelerates it.

What Culture Actually Does

I've been the oracle. Decisions on my team ran through me. The projects that worked were the ones I was close to. I read that as signal that I was adding value. It was a sign that I'd built a dependency, not a team. The engineers weren't deferring to me because my judgment was better. They were deferring because I had never built a culture where their judgment was tested.

When ChatGPT arrived, teams like the one I used to run had an obvious replacement oracle. Different interface. Same problem underneath.

Culture is not your team values on a Confluence page. It's not the engineering principles doc nobody reads after onboarding. It's not the Slack channel with memes and the occasional win.

Culture is what happens when nobody's watching. The shared understanding of how decisions get made, how tradeoffs get reasoned through, how an engineer pushes back on a bad idea without making it personal. The invisible scaffolding that holds the architecture together when you're not in the meeting.

Principals' dashboards looked great. Velocity up. Output up. Ask about unplanned work and the room went quiet. Nobody had a number. The dashboards measured what was easy to measure, not what was actually happening inside the codebase.

What was happening in teams where AI tooling ran without guardrails was exactly what you'd expect from a team without shared standards. Multiple HTTP client implementations pulling in different directions. Conflicting error-handling patterns across the same surface. Inconsistent approaches to the same category of problem, sometimes within the same file. Not because engineers were careless. Because there was no shared framework for what "right" looked like, and AI filled that vacuum at ten times the speed of any individual contributor.

The teams that thrived had done the work before AI arrived. Standards weren't a reaction to the new tools. Code patterns documented. Architecture decisions written down with the "why" included, not just the outcome. When you hand those teams an AI coding assistant, it becomes a force multiplier. The output fits the system.

When you hand that same tool to a team with no shared framework, you get a junk drawer with a CI/CD pipeline.

What AI Actually Exposed

AI didn't break your culture. It exposed teams that never built one.

Most leaders will tell you they have a culture. They'll point to the Notion doc. The architecture review calendar. The two-week sprint cadence. That's structure. Structure and culture are not the same thing.

Real culture is whether your engineers can defend a decision in their own words. Not quote what a tool recommended. Not point to a benchmark someone else ran. Construct the argument. Weigh the tradeoffs. Say "here's what I considered, here's what I chose, and here's what I'm watching to know if I was wrong."

If your engineers can do that, AI is a force multiplier.

If they can't, you have a problem that predates the model.

The culture that produces "ChatGPT said so" as a decision argument is the same culture that produces decisions by committee, approval chains that substitute for judgment, and teams that stopped asking "why" because it was never welcomed in the room. AI just gave that culture a name and a quotable moment.

AI didn't create teams that can't think. It created a faster, more accessible oracle that made the problem visible.

Teach Them to Think

Architecture Decision Records written for the engineer who wasn't in the room when the decision was made. Not bullet points justifying the choice after the fact ... actual reasoning. Here's what we considered. Here's what we ruled out and why. Here's what we're watching to know if we got it wrong. That's the document that builds judgment over time. ADRs written that way become the baseline for how engineers on your team actually make decisions, long before any AI model enters the picture. One ADR on session management saved us from a full migration that turned out to be unnecessary.

Code standards documented as reasoning, not rules. Here's the choice, here's what it costs, here's when you should challenge it. The same standards that let an engineer recognize a bad architectural recommendation from an AI are the ones that let them recognize a bad recommendation from a colleague, or from themselves at 11pm under deadline pressure. You don't build two separate frameworks for human decisions and AI decisions. You build one. You make it cheap to be wrong and expensive to hide it.

Review culture that interrogates "why" before it approves "what." The mid-level engineer who asks "why are we building this?" in a planning meeting is worth more to the team than the senior who executes quietly and ships fast. That question is the signal you hire for. The engineer who asks why is the one building judgment instead of pattern matching. That is what you need when the pattern matcher in the room is an AI model that's confident about everything and accountable for nothing.

Give them room to be wrong. Give them problems worth reasoning through. Give them the feedback loops to know when their judgment is off. Those are the engineers who lead teams within 18 months.

The same standards that let engineers recognize a bad AI recommendation are the ones that let them recognize a bad recommendation from a colleague, or from themselves at 11pm under pressure.

That's on Us

If your engineers can't defend a decision in their own words, the problem isn't the tool they're reaching for. You never built a culture where their judgment was trusted, tested, or developed.

That's a leadership failure.

The fix starts with you. Not with the AI policy document. Not with the acceptable-use guidelines. With you.

With whether you ask "why" or just "when." With whether your reviews create space for engineers to be wrong and learn, or create pressure to be right fast. With whether you've removed yourself as a dependency on good decisions being made, or whether your team still needs you in the room to trust itself.

A team that defers to ChatGPT over its own judgment is a team that's been trained to defer to authority. Before the model arrived, that authority was you. I know it was me.

AI is going to keep getting better. The oracles will keep getting more confident, more accessible, more persuasive. The teams that win won't be the ones with the best AI policies.

They'll be the ones who built the culture where engineers can defend a decision in their own words before the oracle arrived. And the ones willing to reckon, right now, with what the oracle is exposing.

The next time an engineer says "ChatGPT recommended something else" in a review ... don't reach for the policy doc. Ask them to walk you through what they're weighing. What are the tradeoffs? What are they watching?

That's the conversation that builds culture. One exchange at a time, in the room where decisions actually happen.

Getting there isn't a tooling problem. It never was.

That's on us. All of us.

I write daily about engineering leadership at jonoherrington.com.