DEV Community: Jono Herrington

AI Isn't a Crutch for Bad Developers ... It's the Unlock for Neurodivergent Ones

Jono Herrington — Sat, 18 Apr 2026 18:02:40 +0000

I was sitting at my desk at 10:47 PM on a Tuesday, Cursor open in front of me, when I finally understood what had been happening for months. My hands weren't moving. The cursor was blinking. And yet I was in flow ... the kind of deep focus I'd spent my entire career chasing and losing and chasing again. For the first time, my brain and the screen were moving at the same speed.

A major global study by the Tavistock Institute surveyed over 2,000 tech employees across companies like Colt, Nokia, Samsung, and Vodafone. Of the 2,176 respondents, 562 self-identified as neurodivergent ... roughly 1 in 4. The real finding was about the gap in disclosure: over half hadn't told their employers because they lacked a formal diagnosis or didn't see the value. Many developers haven't had language for what they've been experiencing. (Source)

The loudest voices in engineering keep framing AI as the great equalizer that will let mediocre developers ship junk code. They're missing what's actually happening.

AI isn't a crutch for bad developers.

It's the unlock for neurodivergent ones.

I've built a career on the assumption that the eight hours between "I know what to do" and "I've done it" was a tax I had to pay forever.

The Tax I Thought Was Permanent

I've been coding since I was thirteen. I have ADHD. I went undiagnosed until I was thirty-six.

Those twenty-three years were ... frustrating is too small a word. I never knew why getting pulled away from things made me so irritable. Why I couldn't get into the zone the same way other people seemed to. Why, once I finally found that zone, it felt like a physical injury when someone interrupted it.

I built a career on the assumption that the eight hours between "I know what to do" and "I've done it" was a tax I had to pay forever. That the friction was just ... me. That the forty-five minutes of warmup before I could write the line I'd been holding in my head all morning was a character flaw I needed to engineer around.

The hardest part of writing code with ADHD was never the thinking. It was the typing. The context switching. The rebuilding of state every time I came back to the terminal after lunch.

My brain moves like a conductor thinking about thirty things at once. The strings need to come in here, but also watch the percussion section, and is that soloist rushing, and what's happening with the dynamics in the back rows? When you're writing code ... one file, one function, one line at a time in a linear text editor ... that multithreaded mind becomes a liability. I would get stalled because I would just be continually thinking and rethinking and rethinking. Five ways to implement something before I even started typing.

That tax is gone.

When the Conductor Found an Orchestra

It was when I realized that the state of flow you can get with AI is almost a benefit of my focus, not a workaround for it. I can hyper-focus on certain things. The ability to get from zero to one and then continue to iterate allows your brain and the AI to move almost as fast as your brain moves for the first time in my entire life.

I've never thought AI was cheating. One of my top five CliftonStrengths is Competition. There's a saying in sports: if you aren't cheating, you aren't trying. The best developers find the cheat codes and the holes. That's what makes them great. They think through edge cases. They approach things differently than people who follow the rules.

AI doesn't replace my judgment. It doesn't replace my ability to see thirty things at once and hold the architecture in my head. It eats the overhead for breakfast. The transcription tax. The syntax lookup. The "how do I express this thought in code" friction that used to burn forty-five minutes every single session.

AI doesn't replace my judgment. It eats the overhead for breakfast.

The Team I Didn't Design For

I've watched the same thing happen to engineers on my team who learn differently, think differently, work differently.

We assume everyone thinks like us. Even when we intellectually know better ... our day-to-day frustrations betray us. We build processes for carbon copies. We put people in boxes, and if they don't fit, we tell them to conform to the box, not to expand the box.

The truth is that we all have different ways of learning. Some learn orally. Some learn better visually. Some learn better by sitting in a classroom talking about theory. Others learn better by getting into the mess and making mistakes.

AI doesn't fit into a perfect mold, and the unlocks are for everyone differently. How we approach AI is different, and that's actually the beauty of it.

One person on my team has a pilot's license. They think in checklists and systems. For them, plan mode is the unlock. Being able to spec every last thing out, have the AI ask clarifying questions, keep up with their brain wave ... that's the fit.

Another has a scholar background. Master's degree, deep researcher. They gravitate toward ask mode. Starting with questions, iterating on understanding before building. The AI keeps up with their need to explore.

A third just combos their way in and goes straight toward agent mode. No spec. Just velocity and iteration.

Iron against iron creates sparks. That's the type of sparks we need on our teams. But for years, only one of these thinkers got to operate at full speed. The task-list person got buried in planning paralysis. The scholar got stuck in research loops. The combo-coder got dinged for "moving too fast without thinking."

The neurotypical engineer who could just sit and grind for six hours straight ... that person set the pace. That person's workflow was "normal." Everyone else was a deviation that needed accommodation.

Now the ones who used to get edged out are shipping faster than that engineer ever did.

The ones who used to get edged out are shipping faster than that engineer ever did.

The Tax on Focus

A 2023 controlled experiment published in arXiv found developers using GitHub Copilot completed tasks 55.8% faster than those without AI assistance. The researchers didn't segment by neurotype, but the mechanism is clear. AI reduces activation cost ... the cognitive tax of starting. For people with ADHD, that tax is higher. (Source) The distractions of the modern-day world ... Slack, email, calendar notifications ... hit different when your executive function is already a limited resource.

The AI doesn't just make me faster. It makes the fragments of focus I still have more valuable. When I get twenty minutes between meetings, I don't spend nineteen of them rebuilding context. I spend one. Then I ship.

This is why the "AI is for bad developers" crowd misses what's actually happening.

They're so busy defending the keyboard that they're missing who just got let into the room.

They're not wrong that AI can paper over gaps. A junior engineer can ship senior-looking code without understanding it. A developer can generate features without ever sitting with the system long enough to develop judgment. Those are real risks.

But they're wrong about who the tool is unlocking. They're wrong about what "good developer" even means when the constraints change.

Different brains were always doing the work. They just had a worse tax rate.

The engineers who could sit and grind six hours straight weren't better. They were better suited to a toolset designed by people who could sit and grind six hours straight. The IDE, the terminal, the git workflow, the PR review process ... all of it optimized for a particular cognitive style. The rest of us were paying a productivity tax for the crime of thinking differently.

AI doesn't level the playing field by lowering the bar. It levels the playing field by removing a barrier that was never about skill in the first place.

What This Means for Leaders

I keep watching leaders who think their job is policing AI usage. Tracking credits, enforcing policies, making sure people aren't "cheating." They're missing the same thing I had to learn about open floor plans destroying deep work. The same thing I had to recognize about "culture fit" being code for "thinks like me."

We've gotten better over the years. More aware of different learning styles, sensory processing, the invisible tax of environments that don't fit. But we still default to designing for the median and accommodating the edges.

AI is flipping that. The edges are finding tools that fit their minds for the first time. The median is discovering that their six-hour grind sessions aren't actually the only way to ship quality code.

Your job as a leader isn't to police who's using AI and how. It's to notice who's suddenly shipping faster, who's suddenly contributing more, who's suddenly engaged in ways they weren't before ... and ask what changed.

Sometimes the answer is a new tool. Sometimes the answer is that the tool finally fits the person.

Different brains were always doing the work. They just had a worse tax rate.

The tax is gone.

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

Everyone's Using AI. No One Agrees How.

Jono Herrington — Fri, 17 Apr 2026 18:18:22 +0000

I got a DM from a principal engineer last week. He's spending more than $2,000 a month on AI tokens. Not because he's lazy. Because he's figured something out. The tool isn't giving him 10x output. It's giving him exponential output. He's orchestrating agents, chaining workflows, building systems that compound.

I know a tech lead who turned his AI license back in. Said he doesn't want to use it. Wants to stay "pure."

I have an issue with that. Not because he's missing a productivity tool. Because he's missing the current.

This isn't about speed. It's about understanding how the work gets done now. If you're not using AI in 2026, you're not staying current. Full stop.

If you're not using AI in 2026, you're not staying current. Full stop.

No One Agrees How

These two are both senior leaders. Both technical. Both facing the same industry shift. And they're on opposite sides of the same decision.

That's the fragmentation. Nobody has figured it out yet. New parts of the tool come out every day. We're all learning together, and there is no AI expert. Just people who have spent more time with it and people who haven't.

Scale that up to a team. Six months in. Then you ask a different question. What does a good AI-assisted PR look like? And the room fractures.

Some engineers prompt everything and review nothing. Some use it for tests only, line by line, suspicious of anything else. Some copy-paste wholesale. Others cherry-pick like they're editing someone else's draft.

Six different answers. Six versions of "how we do AI." On the same team.

Six different answers. Six versions of "how we do AI." On the same team.

How We Did It Differently

When AI first rolled out, we locked everything down tight. GitHub Copilot. Microsoft Copilot. That was it. No Cursor, no Claude. We cut everything until we had policies in place, governance in place, and we weren't just giving our IP away to agents.

So I started writing markdown files with my questions and having Copilot review them. Worked around the system until I could prove value. Eventually automated quarterly planning and saved 280 hours.

But here's what I learned from that workaround. The tool wasn't the hard part. The hard part was that no one had defined what "good" looked like for AI-assisted work. We had access, but we didn't have standards. So everyone improvised.

Six months later, we had six different workflows. Six different levels of review. Six different definitions of when AI was appropriate and when it wasn't.

The dashboard showed adoption. Credit usage climbing. Active users rising.

What it didn't show was whether anyone could explain their approach to a new engineer. Whether the team was aligned on what success looked like. Whether we were building one coherent system or six parallel experiments that happened to share a codebase.

AI Multiplies Whatever Pattern Is Already There

The junior engineer doesn't know which pattern is blessed. They don't know what "good" looks like because no one wrote it down. So they pick the one that seems fastest, or the one their last mentor used, or the one the AI suggested first.

And the codebase fills with inconsistent patterns faster than any human could have produced them.

People like to say AI is non-deterministic. Same prompt, different outputs. Unpredictable.

I would argue humans are non-deterministic.

Ask an engineer the same question three times. Morning, afternoon, after a bad deploy. You'll get different answers depending on stress, sleep, what they ate, whether they just got out of a brutal stakeholder meeting.

We've always dealt with variability. The solution was never "stop working with humans." It was standards. Accountability. Clear definition of "good" that transcends individual mood.

Same solution for AI.

How We Did It Differently

My current team doesn't have six versions of "how we do AI."

We did the work first. Wrote down what good looks like. What good error handling looks like. How we structure state. When to abstract and when to duplicate. Standards you can articulate.

Then we built lint rules, architectural tests, AI workflows trained on those patterns.

The tool started from our standards. Not generic training data.

That's the difference. Six months in, we don't have six versions of "how we do AI." We have one version of "how we do engineering," and AI operates inside it.

We don't have six versions of "how we do AI." We have one version of "how we do engineering."

The Real Question

The question isn't whether your team is using AI.

It's whether they can explain their approach to someone who just joined yesterday. Whether there's a pattern. Whether the pattern is written down. Whether anyone with judgment has looked at it and said yes, this is what we want more of.

That's the work that happens before the tool. That's the work most teams skip.

Because it feels slower than just letting people figure it out. Because it doesn't show up on a dashboard. Because it requires someone to make a judgment call about what "good" looks like, and not everyone wants to be that person.

But six months from now, when you have six versions of "how we do AI" and a codebase no one fully understands, you'll wish you'd had the conversation before the tools made the mess bigger.

Your engineers are using AI. The question is whether they're using it well enough to teach someone else.

If the answer is no, the dashboard is lying to you.

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

AI Doesn't Fix Weak Engineering. It Just Speeds It Up.

Jono Herrington — Thu, 16 Apr 2026 13:50:47 +0000

"Weak engineers with AI still produce weak output. Just faster." That was the whole point. AI changes speed. Not judgment. If your team already struggled to make sound architectural decisions, the tool doesn't rescue them. It just helps them make more bad decisions faster. The same gaps. Compressed into a tighter window.

I was on the phone with a friend who runs a CMS platform. We were talking about AI adoption across his customer base when he cut through the hype in ten seconds.

"Sh*t in, sh*t out," he said. "AI doesn't solve the decades of issues that distributed teams present."

That was it. The conversation shifted. He'd been watching companies make the same bet ... ship work to lower-rate markets with the expectation that AI would cover the gap. The tool doesn't fix coordination problems. It doesn't fix unclear ownership. It doesn't fix architectural decisions that get revisited every three months because nobody ever aligned on the tradeoffs.

AI just produces output faster. Good or bad, it comes out faster.

Speed Without Foundation

My friend sees the pattern across his customer base. Companies that struggled with architectural decisions before AI haven't found a shortcut. They've found a way to compress the same gaps into a tighter window. The teams that were already shipping inconsistent patterns, unclear ownership boundaries, and technical debt that accumulates silently ... those teams are now doing all of that faster.

If your team already struggled to make sound architectural decisions, AI doesn't rescue them. It just helps them make more bad decisions faster.

I've seen this pattern enough times now to recognize it. Teams adopt the tooling, see initial velocity gains, and mistake speed for health. The metrics look good for a sprint or two. Then the accumulated weight of unchecked decisions starts showing up. Refactors that should have been caught in review. Patterns that diverged across the codebase. Technical debt that formed silently because everyone was moving too fast to notice.

The tool didn't create the problem. It revealed how little structure was there to begin with.

The Judgment Gap

What separates teams that thrive with AI from teams that struggle isn't the AI. It's judgment.

Teams with strong judgment can evaluate what the model produces. They know their patterns. They understand their tradeoffs. They can look at generated code and recognize when it fits and when it's a mismatch. AI becomes a force multiplier for people who already know what good looks like.

Teams without that judgment can't evaluate what they're getting. They're outsourcing decisions they never learned to make themselves. The result isn't better engineering. It's faster execution of uncertain choices.

Teams without judgment can't evaluate what they're getting. They're outsourcing decisions they never learned to make themselves.

This is the uncomfortable truth about AI tooling in engineering. It doesn't level the playing field. It steepens the curve. The gap between teams with strong technical judgment and teams without it gets wider, not narrower. The strong teams move faster and build better. The weak teams move faster and build more of what they already had.

The Oracles We Build

I was the oracle on a team once.

Decisions 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 actually proof that I'd built dependency, not capability. 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 I stepped back, the decisions didn't get easier. They just got slower and more uncertain.

That same pattern is what worries me about AI tooling in weak engineering cultures. When you stop making decisions yourself, you stop building the judgment that lets you evaluate decisions made by others. Including decisions made by models.

A senior engineer told me a story that still sits with me. He had spent years building systems, switched to mostly directing AI agents, then later hit a production memory issue and realized the instinct to debug was gone. Not degraded. Gone.

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

What Actually Matters

The teams that thrive with AI have done the work before the tool arrived. They don't need AI to tell them what good looks like. They already know.

They have clear standards. Not just lint rules and style guides ... real standards that describe how decisions get made, what tradeoffs matter, when to follow the pattern and when to break it. Standards that live in documentation and in practice. The same person can explain why something was built that way and why it shouldn't have been. That's the sign of a healthy standard.

They have review culture that interrogates before approving. Reviews that ask "why" before checking the boxes. That create space for pushback without making it personal. Where junior engineers can question senior decisions and senior engineers can admit when they missed something. The authority isn't in the title. It's in the reasoning.

The teams that thrive with AI have done the work before the tool arrived. They don't need AI to tell them what good looks like. They already know.

They have engineers who can defend decisions in their own words. Not quote a recommendation. Not cite a benchmark someone else ran. Construct the argument. Weigh the tradeoffs. Say "here's what I considered, here's what I chose, here's what I'm watching to know if I was wrong." That capability is what makes AI output useful instead of dangerous.

The Work Before The Tool

If you're leading a team that's adopting AI tooling, the question to ask isn't about usage rates or productivity metrics. It's about judgment.

Can your engineers evaluate what the model produces? Do they have the framework to recognize a good recommendation from a bad one? Can they explain why they're accepting or rejecting what AI suggests, or are they just accepting what looks plausible?

The work that matters happens before anyone opens the tool. It's the standards you set. The review culture you build. The time you spend teaching engineers to think instead of just execute. AI doesn't replace any of that. It requires it.

AI doesn't replace the work of building judgment. It requires it.

I had that moment myself with Cursor. Opened it, used it for ten minutes, shut it down. The suggestions arrived faster than I could evaluate them. Every keystroke generated a new option to consider, a new pattern to question, a new decision to make. It wasn't helping. It was flooding.

Later I recognized what that was. Not that AI was bad. That I needed to be clearer about what I was looking for before I could use it well. The teams that will thrive in this transition are the ones who recognize that same signal.

That's The Real Question

My friend on the phone wasn't worried about whether companies were using AI. He was worried about what they were expecting it to fix. Decades of coordination problems don't disappear because the tool got better.

AI doesn't fix weak engineering. It just speeds it up.

The question for every team is whether that's something you want. Whether your foundation can handle the acceleration. Whether your engineers can evaluate faster without losing the thread of what actually matters.

If they can, AI is a multiplier. If they can't, it's just faster output of the same problems you already had.

That's the conversation worth having. Not whether to use AI. Whether you're ready for what it will amplify.

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

AI Isn't 10x-ing Your Team. Your Execs' Imagination Is.

Jono Herrington — Wed, 15 Apr 2026 13:04:35 +0000

Your leadership thinks you'll code in 3 seconds. Read and understand it all. Push to production without breaking stride. And never forget anything. They've never watched a junior engineer prompt through complexity he should have wrestled with. Never seen a senior freeze when the AI suggestion doesn't match the pattern she knows is right. Never been in the room when the thing that "should just work" ... doesn't.

The cargo cult is real. AI-driven. 10x. The words arrive from people who don't touch the system. They sound like strategy. They function as pressure.

What's actually happening is simpler. Your engineers are learning two workflows now. The one with AI assistance. And the one where they have to understand what the AI produced well enough to evaluate it. That's not 10x. That's overhead.

The gap between promise and reality doesn't shrink when leadership repeats the promise louder. It just makes the reality harder to name.

What 500 Engineers Described

Around the same time I started noticing this pattern on my own team, I was reading a thread that had grown past five hundred responses from experienced engineers describing what happened at their companies after executive mandates for AI adoption. The volume alone was striking. What stayed with me was the texture of the frustration.

Nobody was complaining about the tools. The tools worked.

The frustration was more specific than that. Engineers described sprint planning sessions where leadership talked about AI-driven velocity while the team was debugging something AI-generated last week that nobody fully understood before it shipped. They described the cognitive load of learning two workflows ... the one where AI helps you move faster through problems you understand, and the one where you have to evaluate AI output for problems you're still figuring out.

The gap between what executives imagine and what engineers deliver ... that's the work. And it's not going away.

The engineers who felt this most acutely were often the best ones. The senior engineers who could spot when an AI suggestion didn't match the architectural pattern the team had agreed on. The ones who knew that "technically valid" and "consistent with our standards" are two different bars, and that AI hits the first reliably while missing the second constantly.

Companies were measuring the spread of the tool. Nobody had built a way to measure what was happening to the engineers using it. The dashboard said adoption was up. The engineers knew what they were actually shipping.

When We Rolled Out AI Without Guardrails

I've lived inside this gap myself. Not as an executive repeating promises, but as a leader who gave the team powerful tools without enough structure to use them well.

We rolled out AI coding tools six months ago. No mandate, which was good. But also no guardrails, which was not. I told the team to explore. I told them to see what was possible. What I didn't do was give them a shared definition of what "good" looked like when AI was involved in the production of the code.

PRs got bigger. Review times stayed flat. And somewhere in week six, I started noticing the same architectural decision 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.

I called it a junk drawer with a CI/CD pipeline. The description was accurate. And so was the part I didn't want to admit yet ... I had helped create the conditions where AI could scale our inconsistency faster than our coherence.

When a tool that generates code all day is working on a codebase that never agreed on anything, it scales inconsistency instead of coherence.

My first instinct was to fix the AI. Tighter prompt guidelines. Review checkpoints before AI-generated code could make it into a PR. But pulling up the git history showed me the inconsistency predated our AI rollout by two years. The AI hadn't created any of this. It had just started moving faster than we had.

The fix had to happen at the human layer before we touched anything else. We stopped. Documented patterns. Wrote decision records. Built architectural tests that failed the build when someone drifted from the blessed path. Only then did we build AI guardrails on top of standards the humans had already agreed on.

The junk drawer cleaned up within weeks once the constraints were real. But that's not the lesson. The lesson is that it took six weeks of quiet chaos before anyone asked whether the system could still be understood.

What the Gap Actually Looks Like

The cargo cult language ... AI-driven, 10x, transformation ... it travels from people who don't touch the system to people who do. And it carries an implicit accusation: if you're not shipping 10x, you're not using the tool right.

But the engineers know. They're sitting in sprint planning hearing about AI-driven velocity while they're debugging something the AI-generated last week that nobody fully understood before it shipped. They're watching junior engineers prompt through complexity they should have wrestled with, shipping code that compiles but that they can't explain. They're seeing senior engineers freeze when the AI suggestion doesn't match the pattern they know is right, unsure whether to trust their own judgment or the tool's output.

Your team knows. They're sitting in sprint planning hearing about AI-driven velocity while they're debugging something the AI-generated last week.

The spark is leaving before the code breaks. First the engagement drops. People start pulling back. Then the quality of the thinking shifts ... problem-solving gets thinner, tradeoffs get accepted faster, the energy behind review comments changes. Engineers who used to wrestle with hard decisions start giving quicker, flatter responses.

The code still compiles. Tests still pass. Shipping continues. Nothing looks broken on the dashboard. But something has already shifted in the room.

What We Did Instead

When I introduced AI to my team at Converse, I didn't send a mandate. I gave them two weeks of blocked time to explore the tools without meetings or delivery pressure. No targets. No adoption metrics. Just space to figure out what worked and what didn't.

My tech lead started a weekly call where the team shared what worked, what didn't, and what surprised them. I wasn't in every session because the point wasn't control. The point was shared curiosity.

I walked the team through how AI changed my own workflow, including what I tried, what surprised me, and what I still don't trust it with. Leadership by visibility, not by slogan.

The team now uses AI heavily, and they still enjoy their work because adoption was driven by curiosity rather than compliance. High AI usage and healthy engineering culture are not in conflict when leadership gets the rollout right.

But that required me to stop repeating the executive promise and start acknowledging the reality. AI doesn't 10x your team. It multiplies what you already have. If your foundation is solid, AI accelerates good work. If your foundation is inconsistent, AI accelerates the drift.

The Questions That Actually Matter

The gap between promise and reality doesn't shrink when leadership repeats the promise louder. It just makes the reality harder to name. And the cost of not naming it is paid by the engineers who are learning two workflows while being measured as if they've already mastered one.

Ask your execs when they last reviewed a pull request. Ask when they last sat with an engineer who explained why the AI output wasn't quite right. Ask what 10x actually looks like in practice.

The gap between what they imagine and what you deliver ... that's the work. And it's not going away.

Your team knows. Ask them.

That's something.

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

AI Isn't Killing Your Hiring. Your Double Standard Is.

Jono Herrington — Mon, 13 Apr 2026 13:43:29 +0000

I was in a subreddit with a group of senior engineers this weekend, listening to them share stories from recent interviews. One of them described what had become a pattern. Two interviews, back to back. Both opened by asking if he knew how to utilize AI tools in his workflow. Both followed by handing him a whiteboard and watching him code unassisted. The same skills they expected him to use forty hours a week were suddenly forbidden for the next forty minutes. "It makes no sense," he said, "to force us to use these tools on the job, which actively erode our ability to code by hand, but simultaneously expect us to do technical assessments unassisted." Around the room, heads nodded. They had seen it too.

The comment wasn't angry. It was exhausted. That distinction matters.

You're asking engineers if they know how to use AI tools. You expect it. Everyone does now. Then you're testing them without those tools.

Two interviews. Both asked about AI fluency. Both handed candidates whiteboards and watched them code unassisted. The same skills you expect them to use forty hours a week ... suddenly forbidden for the next forty minutes.

You're testing whether they can perform in a mode that your own process makes optional.

Here's what those interviews are actually testing. Not problem-solving ability. Not judgment about when to reach for a tool. Not the skill those engineers will use to contribute to your team. You are testing whether they can perform in a mode that your own process makes optional.

The engineer sees it. He uses AI on the job because you require it. Then he sits in your interview pretending that requirement doesn't exist. Performing a skill you've systematically made unnecessary.

The Gap Between Workflow and Assessment

I keep returning to a thread that surfaced from over five hundred experienced engineers, many in senior and staff roles, describing what happens when organizations roll out AI tools through mandate rather than through changed systems. The stories were a catalog of friction points. Governance without standards. Access without enablement. Speed without comprehension.

The hiring problem belongs in that catalog. You added the accelerant without changing how you evaluate the work.

The forty-hour week and the forty-minute assessment have diverged so completely that the interview no longer predicts job performance.

A sorting algorithm written on a whiteboard tells you something about how a person thinks under artificial constraints. It tells you almost nothing about how they will perform when their actual job involves reviewing AI-generated service boundaries, debugging agent-orchestration failures, or deciding whether a generated refactor preserves the semantic intent of the original code. Those are the skills your team uses now. Those are the skills your interview is not designed to see.

The forty-hour week and the forty-minute assessment have diverged so completely that the interview no longer predicts job performance. It predicts something else entirely. Whether the candidate can tolerate theater. Whether they are willing to perform a skill you have quietly deprecated. Whether they have kept their manual coding sharp despite your own tooling making that maintenance unnecessary.

What the Double Standard Signals

Candidates read signals. They always have. The difference now is that the signal is contradictory and impossible to miss.

When you ask about AI fluency in screening, you signal that the tool matters. When you forbid the tool in assessment, you signal that you don't actually trust it. When you hire people who pass the whiteboard test, you signal that manual coding is the real standard. When you mandate AI usage on the job, you signal that manual coding is no longer sufficient.

The candidate sits in these contradictions and sees exactly what you're doing. Your organization has not thought through what it values. You are hiring for 2026 workflows with 2019 assessments. And you either don't see the mismatch or don't care enough to fix it.

The candidate isn't failing your process. Your process is failing the candidate.

Some companies have tried to bridge the gap by adding "AI pair programming" rounds where candidates work with the tool present. This is better than nothing, but it often reveals a different problem. The interviewers haven't actually defined what good AI-assisted work looks like. They know what bad manual code looks like. They don't know what good judgment looks like when evaluating generated output. So the round becomes another theater exercise. Can the candidate look comfortable using the tool? Can they talk through their process without saying anything that sounds alarming?

The evaluation criteria remain vague because the organization hasn't done the harder work. Defining standards for AI-assisted engineering is harder than defining standards for manual coding. It requires admitting that the definition of "good code" is in flux. It requires acknowledging that your senior engineers might not know either, not yet, not with confidence.

The Question Worth Asking

What would a repaired interview process look like? Not the complete answer. Just the first honest question.

Ask yourself which skills your team actually uses.

Be specific. When your engineers ship a feature this week, what percentage of the code was generated versus written? When they review a pull request, what are they actually evaluating? Syntax? Semantic intent? Architectural fit? The quality of the AI prompt that produced the change? How do they know whether a generated refactor is safe?

If you can't answer these questions clearly, your interview process is not broken by accident. It is broken because you have not yet defined what good performance means in the new workflow.

You don't need better interview questions. You need clearer standards for the work itself.

The engineer in that room knew something his interviewers didn't. He knew that the test he was taking had become a ritual without a purpose. He knew that the skills being evaluated were not the skills that would determine his success on the team. He knew, and he performed anyway, because that is what candidates do. They perform.

The question is whether the organizations doing the hiring know it too. Whether they have looked at their process and seen the drift. Whether they are willing to name the contradiction and build something more honest in its place.

The engineers aren't confused. They have been watching the gap widen between what companies say they value and what companies actually test. They have felt the absurdity of preparing for interviews by practicing skills their prospective employers have made obsolete.

They are waiting to see which organizations notice first.

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

The Spark Is Leaving Before the Code Breaks

Jono Herrington — Sun, 12 Apr 2026 13:06:21 +0000

The spark is leaving before the code breaks.

I had a conversation with an engineer last week who works at a culture analytics platform. The kind of company that powers engagement surveys, pulse checks, and culture diagnostics for organizations worldwide. I've been asking people across the industry the same question: From your seat, what impact is AI having on you and your team right now — the good, the bad, and the ugly?

His response stuck with me.

"There's uncertainty on how to best make the most of it. I've seen engineers lose the spark in the eyes in their craft having to just plan and review the output. In other areas, I've seen great results with people being able to make better decisions through knowing different options that's available to them from the planning phase. The sheer pace of AI is wearing down engineers though."

I told him that "losing the spark" line felt real. I was hearing it everywhere.

He told me it hasn't happened to his own team. Not yet. But he's observing it in others. First the engagement drops. Then that trickles into how they approach problems. Then into how they review. A mixture of losing their fidelity in approaching problems and reviewing.

The code still compiles. Tests still pass. Shipping continues.

The breakage hasn't happened yet.

I've seen engineers lose the spark in the eyes in their craft having to just plan and review the output.

What Makes This Different

This engineer isn't just watching his own team. He's got a vantage point that spans organizations, industries, geographies. He sees patterns in aggregate that most of us only glimpse in our own narrow slice.

When he says he's watching engineers lose the spark across the industry, he's not speculating. He's seeing the data. He's hearing it in the open-ended responses from thousands of survey participants. He's watching engagement scores drift while productivity metrics stay flat or climb. He knows what disengagement looks like before it becomes turnover. He can spot the pattern because his entire platform is built on measuring exactly this.

And what he's seeing is a decay pattern that starts with engagement and leaks into everything else.

The Progression He Described

First the engagement drops. The spark goes away. Not from overwork or bad management or unreasonable deadlines. From the sheer pace of a tool that generates faster than humans can properly evaluate. From planning and reviewing output instead of building. From supervising something that feels increasingly alien to the craft they fell in love with.

Then that trickles to how they work and see work. The fidelity in approaching problems starts to thin. Engineers who used to sit with hard problems until they understood them now reach for the prompt window at the first sign of friction. The muscle for wrestling with ambiguity atrophies because the tool offers immediate relief.

Then the reviewing gets thinner. Less questioning. More approval of code they didn't write and solutions they didn't think through. The standards drop not because anyone decided to lower them, but because the energy to maintain them drains away when you're not actually building anymore.

The code still compiles. Tests still pass. Shipping continues.

First the engagement drops. Then that trickles into how they approach problems. Then into how they review.

What Your Dashboard Won't Show

Your AI adoption metrics are showing you velocity. They're showing you active users and code review throughput and deployment frequency. They're not showing you who's still shipping but stopped caring. They're not capturing the engineers who are in the room but already gone.

The engineer gave me the kicker at the end of our conversation: "We accept what we tolerate."

I sat with that for a minute.

We've built an entire framework for AI adoption that tolerates disengagement as long as output stays high. We celebrate velocity gains without asking whether the humans generating that velocity still find meaning in the work. We track adoption metrics without tracking what adoption is doing to the relationship between engineers and their craft.

When I told him I was hearing the "losing the spark" narrative everywhere, he didn't seem surprised. He's watching it happen across the industry in real-time. The sheer pace of AI is wearing people down. The tool moves faster than the culture can adapt. Engineers are trying to keep up with a generated output they can't fully evaluate while maintaining the judgment that used to come from building things themselves.

The Harder Question

I don't have a clean answer for whether we need to accept this. Culture analytics platforms exist because companies want to measure engagement and catch drift before it becomes attrition. But measuring drift isn't the same as preventing it. You can have perfect visibility into declining engagement and still not know what to do about it.

The harder question is what we're willing to tolerate. If we only celebrate speed and output, we shouldn't be surprised when engineers optimize for those things at the expense of meaning. If we only track adoption metrics, we shouldn't be shocked when adoption happens in ways that hollow out the craft. If we tolerate thin reviews and superficial engagement because the code compiles, we are accepting a drift we will eventually have to pay for.

The engineer hasn't seen it on his own team yet. But he's watching it happen to others. The ones who are still showing up but already gone. The ones whose code still works but whose spark has already left.

We accept what we tolerate.

The code will break eventually. It always does. The question is whether the people who need to fix it will still have the engagement to care, or whether we'll be left with velocity metrics that kept climbing while the humans who generated them checked out long before the system needed their judgment.

Your dashboard won't capture that. Only the humans can tell you what's actually happening. And only if you create space for them to say it without defending the rollout.

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

The System Went Down

Jono Herrington — Sat, 11 Apr 2026 13:03:35 +0000

The system went down. One leader opened Slack. The other opened the logs. Same title. Same years of experience. Same team size. The difference was proximity to the system they were responsible for.

I try to avoid writing code from scratch now.

I need to sit with that sentence for a moment because it still doesn't feel true, even though I've been living inside it for months. There was a time when I would stay up endless nights losing myself in the thinking of writing code. Not shipping. Not hitting deadlines. Just the pure absorption of building something from nothing, watching it take shape, debugging until the logic finally yielded. It was something I loved.

That's not where my attention goes anymore. All of it has shifted to optimizing AI or reviewing AI or shipping AI. I've trained a completely new muscle. And when I go back to the old one ... when I actually sit down to write code from scratch without tooling assistance ... I feel it immediately. The retrieval cost has gone up. Syntax I used to have at my fingertips. Patterns I implemented dozens of times. The knowledge is still there, but the fluency is gone. Like a language you used to dream in that now requires translation.

I try to avoid writing code from scratch now. I need to sit with that sentence for a moment because it still doesn't feel true, even though I've been living inside it for months.

The Question I Don't Have an Answer For

The question I keep circling back to is whether this is okay. Maybe it is. Maybe we're evolving. Maybe the world is changing at a pace that demands our worldviews change with it, and all the cultural scaffolding we've built around what engineering is ... and what it was ... is simply updating to match the new reality. The skills that got you riding a horse aren't the skills you need to fly a plane. That metaphor feels close but not quite right. Planes still require understanding aerodynamics. You can't fly on vibes alone.

The Retreat Doesn't Announce Itself

There was a period a few years ago where I realized my one-on-ones had turned into status reports. I was nodding through technical explanations without fully following the thread. Not because my team was poor communicators. Because I had drifted. The retreat from technical work doesn't announce itself. It happens in the margins of a calendar that keeps filling with meetings you believe are essential. You tell yourself you're staying close to the work because you're reviewing architecture documents and attending sprint planning. But architecture documents are not systems. Planning is not debugging. You can be present in every technical conversation and absent from the craft that makes the conversation meaningful.

The Bug That Wasn't the Point

A bug came in last month. Production issue affecting customer checkouts. The kind of ticket that normally routes to production support, enters a queue, gets triaged by someone three time zones away, and eventually resolves in a few days with a patch that addresses the symptom without anyone understanding the cause. I've seen that movie. I've written that script.

This time I dove in. Checked the logs. Found a data issue in how we were handling inventory holds during high-traffic events. Fixed the customer experience in thirty minutes.

The fix wasn't the point. I mean, the fix mattered to the customers who could complete their purchases, but the thirty minutes wasn't the win. The win was that I now understand a failure mode in our system I wouldn't have known about otherwise. A race condition between two services I thought were properly decoupled. A timing assumption that held up under normal load but collapsed when traffic spiked. Next time my team proposes an architecture change that touches that area, I'll ask the right question. Not because I read about it in a status report. Because I saw it break.

The Instinct That Was Gone

A senior engineer I know spent years building real production systems. The kind of systems that handle actual money and actual users and actual consequences when they fail. He was good. Deeply technical, respected by his peers, the person you wanted in the room when something was on fire. Then he switched to mostly directing AI agents. Reviewing, approving, orchestrating. The workflow looked productive. PRs were moving. Features were shipping. The metrics looked fine.

A few months later a production memory issue surfaced and he reached for the debug instinct that used to be automatic. It was gone. Not rusty. Not needing a moment to warm up. Gone. He described it like watching someone try to speak a language they'd been fluent in as a child, knowing the shape of the words but unable to summon the actual sounds.

Skills decay when you stop exercising them. Judgment decays faster.

Skills decay when you stop exercising them. Judgment decays faster.

What the Dashboard Won't Capture

The question I'm actually wrestling with isn't whether AI is making engineers worse. It's whether the role is changing in a way that makes certain skills optional until suddenly they're not. You can drive velocity and ship features and hit milestones while the foundation erodes underneath. You can look productive for a surprisingly long time before the gap becomes visible.

Your dashboard won't capture it. You can track AI credit usage and PR throughput and deployment frequency and watch all those numbers climb while the thing that actually matters hollows out. The engineers who spend their days prompting and reviewing without ever sitting with a hard problem until it yields. The leaders who can discuss system architecture in a conference room but flinch when asked to actually trace a failure through the logs. The drift is survivable in a normal engineering environment. It's survivable for a long time. Until the moment you need the instinct and it's not there.

The Signals I Watch For

I watch for specific signals now. When my one-on-ones start feeling like status reports instead of conversations. When I catch myself nodding along to a technical explanation I don't actually understand. When I realize it's been weeks since something in the codebase surprised me. When I try to avoid writing code from scratch because I know how it will feel. Those aren't neutral observations. They're warnings.

When I try to avoid writing code from scratch because I know how it will feel. Those aren't neutral observations. They're warnings.

The leader who opened Slack when the system went down wasn't wrong to coordinate the response. Someone has to. But coordination is different from comprehension. You can manage an incident without understanding the system that's failing. You can lead a team of engineers without remembering what it feels like to ship code that breaks in production and fix it before anyone notices. You can hold the title and occupy the chair and collect the salary without maintaining the proximity that makes the title meaningful.

I still read pull requests. Not to approve syntax ... my team doesn't need me checking their semicolons ... but to understand how they solve problems. To see whether their decisions connect across teams and regions. To stay close enough to the system that I can feel it when it surprises me. That's not micromanagement. That's maintaining the thread.

Rebuilding What You Once Had

The engineer who lost his debug instinct after months of AI orchestration is trying to rebuild it now. He's blocking time to work through hard problems without tooling assistance. Sitting with errors until he understands them instead of prompting his way around them. It's uncomfortable work. Rebuilding something you once had is harder than maintaining it would have been. The body remembers the shape of the skill but not the feel of it. Muscle memory without muscles.

Staying technical as a leader isn't about proving you can still code. It's about maintaining the judgment that comes from having been in the system when it broke. From knowing what a failure mode looks like before it becomes an incident. From asking the right question in an architecture review not because you read a case study about it but because you saw it fail last month and traced it through the logs yourself.

The system will go down again. It always does. The question is whether you'll understand what you're looking at when you open the logs, or whether you'll be coordinating a response to a failure you can no longer comprehend.

Maybe we're evolving. Maybe the airplane doesn't need the same skills as the horse. But someone in the cockpit still needs to understand why the plane stays in the air. Someone still needs to know what to do when it doesn't.

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

When AI Makes You Forget How to Code

Jono Herrington — Fri, 10 Apr 2026 13:16:40 +0000

The junior engineer sat across from me in a conference room that smelled like stale coffee and stress. He had just shipped a feature that was working in production. Tests passing. Metrics green. The kind of delivery that should have felt like a win. Instead, he looked exhausted and a little bit lost.

"I can't explain how it works," he said.

Not because he hadn't tried. Not because he was incapable. He had stared at the function for twenty minutes before our meeting, tracing the logic, trying to reconstruct the reasoning that had produced it. The code compiled. The tests passed. But when he tried to walk through it line by line, the understanding wasn't there. The logic felt borrowed. Alien. Like reading someone else's handwriting and realizing you don't recognize your own name.

The code was his. He had written it. But he hadn't written it.

The Friction Is Gone

Here's what he told me happened. He hit a problem he didn't fully understand, so he described it to an AI assistant. The AI generated plausible-looking code. It compiled. Tests passed. He shipped it. The whole cycle took a fraction of the time it would have taken him to wrestle with the problem himself, to get stuck, to unstick himself, to actually understand what he was building.

The friction that used to force understanding was gone.

I heard someone say it plain in a conversation that stuck with me: weak devs plus AI equals weak output ... faster. The junior engineers feeling this most acutely aren't struggling because AI is too hard. They're struggling because AI made it too easy to skip the work that builds judgment.

The friction that used to force understanding was gone.

What Gets Lost When Speed Wins

This isn't a story about one engineer having a bad week. Once I knew to look for it, I started noticing the pattern everywhere. PRs getting bigger. Review comments getting thinner. The energy behind the work shifting, and not in a direction that leads to better engineering.

I watched a thread of over 500 experienced engineers describe what happened when AI tools rolled out without thoughtful guardrails. The stories were remarkably consistent. PRs ballooned as AI generated more code than humans could reasonably review. Codebases filled with inconsistent patterns, each engineer prompting their way to a slightly different solution for the same problem. Service boundaries blurred. Error handling became a patchwork. The codebase started feeling less like an intentional system and more like a junk drawer with a CI/CD pipeline.

One engineer described it with a line I haven't been able to shake. The first sign wasn't that the team missed a date. It wasn't that quality cratered overnight. It started earlier and quieter than that. Engagement dropped first. People started pulling back. Then the quality of the thinking started to shift. Problem-solving got thinner. Engineers who used to wrestle hard with tradeoffs started giving quicker, flatter responses.

By the time performance looked off in the metrics, the team had already been drifting for a while. The breakdown started in trust and attention long before it showed up in delivery.

I Didn't See It At First

I have to admit something I didn't see clearly when we first gave the team access to these tools. I thought the risk was that engineers wouldn't use AI enough. That they would resist change and stick to old patterns out of fear or habit. I spent energy on encouragement and permission when I should have been paying attention to what happened when the tools became invisible.

The junior engineer in my conference room wasn't resisting AI. He was using it constantly. That was the problem. He had become fluent in describing problems to a machine but less fluent in solving them himself. The judgment that comes from wrestling with hard problems was atrophying because he wasn't being forced to wrestle anymore.

He had become fluent in describing problems to a machine but less fluent in solving them himself.

I saw it in myself too if I'm honest. There were moments where I prompted my way through something I should have understood more deeply, where I accepted working output without accepting the understanding that should have come with it. The convenience was seductive. The cost was invisible until it wasn't.

The Exponential Nature of the Problem

A leader gave me the cleanest explanation I've heard of what's actually happening. AI isn't a multiplier. It's an exponent.

A multiplier makes people think the tool adds a fixed amount of value. An exponent is different. It magnifies whatever is already there. If a team has clear standards, strong review habits, shared judgment, and disciplined engineering patterns, AI makes those things more powerful. If a team is loose, inconsistent, and already carrying weak habits, AI doesn't smooth that out. It amplifies the instability.

That's why two teams can buy the same tools under the same pressure and end up in completely different places. The tool didn't create the difference. The foundation did.

I watched this play out in real time. Teams that had strong standards before AI arrived were producing more code at the same quality bar. Teams that were already inconsistent became inconsistent faster. The junk drawer codebases became junk drawer codebases with more volume. The engineers who were already struggling didn't get rescued by the tool. They got buried by it.

AI isn't a multiplier. It's an exponent.

What the Dashboard Can't See

Your AI adoption dashboard is probably showing you participation metrics right now. How many engineers have access. How many prompts are being sent. Usage rates and feature adoption and all the numbers that make leadership feel like the rollout is succeeding.

Here's what those numbers can't tell you: whether your engineers understand the code they're shipping. Whether the judgment that used to be built through friction is still being built at all. Whether your team's accumulated wisdom is growing or eroding while everyone moves faster.

The junior engineer who couldn't explain his own function wasn't an outlier. He was a canary. The kind of signal that shows up in behavior and conversation long before it shows up in velocity charts or defect rates.

The Question That Matters

Ask your engineers what they wish had been different about how the tools were introduced. Don't defend the rollout. Just listen.

What they tell you is what your dashboard can't see. The moments where they accepted generated code without understanding it. The times they shipped something that worked but couldn't explain why. The creeping sense that they were getting faster at the wrong things.

Some of them will tell you they noticed the drift in themselves and pulled back, forced themselves to slow down and understand. Others will admit they haven't found the discipline yet. They're still riding the speed wave, hoping the understanding will come later, knowing somewhere underneath that it probably won't.

What you hear will tell you whether your AI adoption is actually succeeding or just moving faster toward a future where fewer people on your team actually know how the system works.

The code compiles. The tests pass. The dashboard shows green.

But somewhere in your organization right now, a junior engineer is realizing he can't explain his own code. He's exhausted and a little bit lost. And he's waiting to see if anyone notices.




---

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. [Subscribe for free](https://www.jonoherrington.com/newsletter).

Hope Is Not a Flight Plan

Jono Herrington — Thu, 09 Apr 2026 13:46:02 +0000

He said it almost as an aside, somewhere around the twenty-minute mark of our call. He was running a team of several dozen engineers, and we had been talking through where his AI rollout stood. Then the real thing surfaced. "If I'm being honest," he said, "all I've done is buy the licenses." And then he paused. I asked him what his next step was. He didn't answer right away. That pause held everything at once ... the announcement he'd already sent, the budget he'd already committed, the expectation he'd already set in motion, and the gap between all of that and what was actually happening on his team.

The licenses were live. Nobody knew how to fly.

The Procurement Assumption

This isn't one CTO. I've watched the pattern repeat across engineering organizations at every scale over the last two years. The sequence is almost always the same. Leadership sees where AI is going, someone in procurement gets involved, licenses are negotiated and purchased, an announcement goes out. And then the organization waits for adoption to follow, as though signing the contract was the work.

Hope takes over where planning should be.

I tracked a thread last year that surfaced more than five hundred engineers describing what happened inside their organizations when leaders treated procurement as adoption. The details varied. The shape didn't. Tools sat unused. Teams felt no clear permission to experiment, no structure for learning, no signal that leadership had done the work themselves. After a few months of low usage numbers, the mandate arrived. Use this. Show us adoption metrics. The tool that might have become a genuine productivity multiplier became a compliance exercise instead. Nobody built anything real with it, and by the time leadership noticed, the window for genuine capability building had mostly closed.

The announcement is not the flight plan. The license is not the training.

I Was Not Immune to This

I want to tell you about my own entry into AI tools, because it is relevant here.

I opened Cursor for the first time, spent about ten minutes with it, and shut it down. The story I told myself was that it didn't fit my workflow. I was moving too fast for this. The integration felt foreign. I convinced myself I was being pragmatic, that I had evaluated it and found it lacking.

I hadn't evaluated anything. I was scared of something I didn't understand yet, and I dressed that up as productivity skepticism because "this doesn't fit my workflow" is easier to say than "this is unfamiliar and I don't know what I'm doing with it."

Fear is very good at finding professional clothing.

About a month later, my tech lead kept pulling me back. He had been building real workflows with Cursor, training agents, shipping things faster. He wasn't preaching about it. He was just a step ahead of me, and he kept saying "try it again" ... not as a directive but as an invitation from someone I trusted. I came back. I stayed with it long enough for it to feel natural. I built workflows. I built pipeline tools. The relationship changed completely.

What changed wasn't the tool. What changed was that I had someone who had been through the discomfort ahead of me, and a reason to stay past the part where it felt awkward.

That experience shaped how I brought AI to my team. I didn't want anyone shutting the tab after ten minutes because nobody gave them a reason to stay.

What a Flight Plan Actually Looks Like

When I introduced AI tooling at Converse, I didn't start with an announcement. I started with time.

I gave the team two weeks of blocked calendar. No delivery pressure, no meetings stacked on top of it, no expectation that they would come out the other end with something to demo for leadership. The ask was simple: explore the tools, build something small, break something, bring the surprise back. That was it.

My tech lead started a weekly call where engineers shared what worked, what failed, and what caught them off guard. I wasn't in every session on purpose. My presence in every session would have changed what people were willing to say out loud, because teams perform for leaders even when the leaders are trying to create safety. The point was shared curiosity, not managed performance. Engineers talked to each other about what they were actually experiencing, and they learned at the pace that actually sticks.

Then I walked my team through my own workflow. Not a polished demo. The real thing ... what I was using AI for, what I was still doing without it, where I had gotten it wrong, what I still didn't trust it with. Not as proof that I had figured it out. As proof that figuring it out was normal and ongoing, and that the leader being in the middle of the learning alongside the team was what the learning was supposed to look like.

A flight plan is time, structure, and a leader who visibly went first.

What Happens When You Skip It

We did not always get this right, and I want to be clear about that.

When we first rolled out AI coding tools without enough structure underneath the rollout, things degraded quietly. PRs got bigger. Review times stayed flat. The codebase filled with inconsistencies that had not been there before. Error handling varied file to file. State management looked different across services. We had built a junk drawer with a CI/CD pipeline.

The problem was not the tool. The problem was that AI is very good at scaling whatever you give it, and what we gave it was a team that had not yet aligned on what good looked like. The tool did not create the inconsistency. It amplified what was already underneath the surface.

We had to go back and do the work we had skipped. We documented patterns and decision records. We got the humans aligned on standards before we tried to encode those standards into guardrails. We built lint rules, architectural tests, and AI workflows trained on our patterns instead of generic training data. Teams that build the system before they automate it move faster later because they are not cleaning up a junk drawer six months in. The codebase stabilized within weeks. Not because the tool got better. Because the foundation it was building on finally made sense.

What the Leaders Who Got It Right Did Differently

The common thread I've seen in leaders who actually moved their teams through this, not just past the announcement phase but into genuine capability, is that they went first.

They didn't wait for their teams to build fluency and then check in on the metrics. They used the tools themselves, visibly, and they talked about it. They named what surprised them. They created protected time for exploration before the expectation to perform arrived. And when the early experiments were clumsy or the initial numbers were low, they treated that as the work being done, not the work being missed.

The leaders who didn't get there sent the announcement, watched the dashboard, and escalated when the numbers didn't move. That escalation turned the tool from an invitation into an obligation. Teams that feel obligated to perform adoption will show you the metrics without showing you the change. The numbers go up. The capability doesn't follow. The mandate has no return address because nobody ever owned what came after it.

The jet with keys and no trained pilots doesn't sit on the tarmac forever. Eventually someone is asked to fly it because the budget has been spent and the announcement has already gone out. That is when the real cost shows up.

Back to That Pause

The CTO asked me, after the silence stretched out, what I thought he should do. I told him to go use the tools himself for two weeks before he asked anyone else to. Not because he needed to become an expert first. But because his team would know whether he had or hadn't, and that knowledge would shape everything about how seriously they took what came next.

He said he had been meaning to.

Meaning to is not a flight plan either.

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

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.