A honeymoon recently pulled me away from work for a few days, and with that bit of distance I found myself dwelling on a question I rarely get to take out from under the daily grind.

I’ve written several posts about developers in the age of AI. But looking back on them from the quiet landscapes of New Zealand, I noticed something they had in common: every one of them was a worry about the individual developer. How do I avoid being anesthetized by AI, how do I hold on to my own skills, and so on.

But I had never really thought about what happens to the organization those individuals belong to, or how the leader running that organization has to change.

So this post looks into that gap. Why the belief that using AI well makes you a capable developer is closer to an illusion; what happens when that illusion spreads beyond a single person to the scale of an organization; and what a leader should be paying attention to in the face of it.

The More You Lean on AI, the Thinner Your Ability to Verify Its Output Gets

Over three recent posts, I’ve written about what stance developers should take in the AI era and what abilities they should aim for. Read together, they show how my thinking has shifted.

Here’s how each one framed the problem:

Post	Saw it as	Conclusion
Who Are You, the One Writing Code Right Now?	A matter of will	Stay alert and the tool stays a tool
Only When the Tide Goes Out Do You See Who’s Been Swimming Naked	A matter of position	Rise from author to decision-maker
Developers Who Stopped Growing	A matter of structure	Even while using AI, deliberately design a structure that loads the brain

All three point to the same place. The ability to handle AI well and the ability to verify its output are not the same thing, and the more you lean on the tool, the quieter the latter fades — painlessly, like being put under anesthesia. So that ability isn’t preserved by staying alert, nor by changing the seat you sit in; it can only be held through a deliberate structure.

But all three shared one frame. Each was a story about “how do I protect myself, one person,” and whatever the answer was, it was something I did alone. Yet from the seat where you hire people and set the team’s direction and the bar for what gets merged, this anesthesia doesn’t end with one person’s judgment dulling. When it’s not one person but the whole organization that gets anesthetized together, what is the person leading it supposed to do?

Before heading toward an answer, I should first pin down why this anesthesia can’t be stopped by individual will. It comes not from one person, but from the nature of the tool.

AI Is Not an Abstraction but a Proxy

Underneath the belief that using AI well makes you capable lies an equation: the ability to use AI well is itself a developer’s competence. You use it well, so you make more; you make more, so you’re more capable.

This equation has fairly solid historical backing. We called someone a capable developer for handling React’s declarative UI well without tracking exactly how the browser repaints, and a good developer for handling data well through an ORM without writing a single line of SQL. Handing low-level labor to tools one layer at a time while people focus higher up on design and assembly — that’s how the profession of development has evolved all along. So the claim that I can hand implementation to AI and just make judgments from above looks, at a glance, like the next chapter of that evolution.

This Abstraction Has No Ladder Down

The problem is that AI is quite different in kind from those earlier abstractions. The tools so far were deterministic. The principles were clear and the same input produced the same output, so when something went wrong there was always a ladder to climb down and trace why. You could live without looking below it day to day, but you could always descend and check the causality directly when you needed to. The point isn’t whether you ride that ladder every day, but whether you can climb down when you have to.

But generative AI is probabilistic. The same request yields different code each time, and there’s no ladder to climb down to why that code came out the way it did. Even the people who built the model can’t clearly explain why it produces a given output — and that says it all.

Let me clear up one misunderstanding. This doesn’t mean you can’t read the generated code itself. Code AI spits out is as readable as the SQL an ORM generates — more readable, even. “No ladder” doesn’t mean you can’t read the output; it means there’s no ladder down to why the code was written that way. Under a deterministic tool there was at least a rule of causality to follow down, but for what a probabilistic proxy hands you, there’s no path for a person to retrace. Whatever process happened inside the AI, it never once passed through a human head.

And there’s a more decisive difference. The earlier abstractions lifted us up a layer. In handing DOM manipulation to React, we took hold of a new, higher layer of causality: component design. But AI doesn’t lift us up a layer. It sits down in the very layer where we were standing. If an abstraction was climbing one rung up the ladder, AI is seating a proxy in your spot. So there’s no new causality to grasp above, and the causality you used to hold quietly slips away. That’s why I call AI not an abstraction but a proxy.

So the real substance of “using AI well” is less about mastering deterministic rules to control the result, and more about picking the best one out of the many probabilistic outputs AI pours out. (In other words, however well you build the harness, it’s basically a game of luck.)

Who Holds Ownership of the Causality

Here the line between when using AI builds your ability and when it erodes it comes into view. The line is who holds ownership of the causality. Code we wrote ourselves leaves, in our heads, the causality of why we wrote it that way. Why this branch sits here, why we chose this data structure, which cases we gave up — all of it follows along naturally. But AI-written code has only the result; the causality leading to that result never passed through our heads.

Stacking up code with the causality missing is like signing, over and over, a contract written in a language you don’t know. There’s no problem at first, but the moment the clauses conflict, the signer has not a single line of defense. Reading and understanding is a completely different weapon, in an emergency, from holding the causality from the start. The more complex the system gets, the more a developer who has only stacked up signatures heads toward a state where they can’t touch a single line without AI.

Up to here, this is what the earlier posts covered. And as the April post showed, this anesthesia is a structural problem that individual will doesn’t easily stop. But suppose, generously, that one clear-headed person holds out by sheer will. The real problem is that this was never something that ends inside one person’s head.

AI Levels Plausibility, Not Skill

There’s a reason this anesthesia doesn’t stop at one person. Code with the causality missing happens to look perfectly fine on the surface. So that code piles up quietly inside the organization without anyone stopping it. And you don’t have to look far for the pattern — it lands on my desk every day.

As an interviewer these days, and as a reviewer poring over the PRs that come in daily, I see an enormous amount of AI-written code. And it makes me think AI is leveling developers’ skill into a kind of plausible uniformity.

Say you rate the surface-level completeness of code from 1 to 10. There used to be 1s and there used to be 10s. But lately the 1-to-4 range has all but vanished, and the floor feels leveled up to around a 5. What matters here is that what’s being leveled is not developers’ ability, but the surface level of the output.

In other words, what AI raised is not skill but the floor of “plausibility.” And this distinction matters because the problem doesn’t get solved by AI getting better. As models improve, the floor of plausibility just rises higher, and the more plausible the output looks, the harder it becomes to see that the causality inside is empty. So AI’s quality isn’t the variable this post is about. The better it gets, the more discreet the anesthesia becomes.

Code That Looks Fine from a Distance

In fact, looking closely at the PRs that come in daily, I occasionally spot ones whose quality is poor — and what they all have in common is that they look plausible from a distance.

The variable names are tidy and the structure looks reasonable, but dig in a little and you find duplicate functions carrying the same responsibility, blurry boundaries of responsibility, or piles of side-effect-laden code.

But there’s a faster tell than digging into the code: asking the person who wrote it. Surprisingly often, even for code they supposedly wrote themselves, a single “why did you do it this way here?” leaves them stuck, or rambling about something unrelated. The variable names and structure are tidy, but they can’t give the reason for the choice — and that’s the most honest evidence of code that looks fine on the surface with the causality missing. (As an interviewer, I run into this scene constantly.)

The real problem is that there just aren’t many people who can spot code with the causality missing. Whether in an interview or a review, pinpointing an empty causality takes a certain eye on the viewing side — and the ability to tell apart and produce well-structured code was rare even before the AI era. On top of that, in an age where code can be written in seconds, this ambiguous-quality code is piling up faster and faster.

Seen this way, those flimsy PRs coming in every day aren’t exceptions but signals. The reason they look flimsy to me is that I can still see the gap between ambiguity and good quality. What’s truly frightening is that when code of this quality starts being produced en masse inside an organization, and the developers who can read problems out of it keep dwindling, there’s still no clear way to control the situation.

I see this phenomenon as “the organization gradually being anesthetized by AI.”

The Anesthesia Spreads at the Scale of the Organization, Not the Individual

So if a leader wants to keep the organization from being anesthetized together, what should they look at first? The starting point is pulling apart two things we usually lump together.

What I want to propose is a distinction between productivity and cognitive ownership. Productivity is the amount of code and feature completeness produced per unit of time, and the better you use AI, the more explosively this number climbs.

Cognitive ownership is a different story. It’s the state of being able to trace and explain, from start to finish, why the code you’re handling had to be written the way it was. Not whose hands the code passed through, but in whose head its causality lives.

At the individual level, these two don’t move together. The more you delegate to AI, the higher productivity goes, but cognitive ownership of that code keeps thinning. And once you move this thinning to the scale of an organization, the picture gets far more brutal.

There used to be at least two layers of ownership on a single line of code. The author who wrote it held the causality, and the reviewer held it once more. Even if the author left the company, a copy of the causality remained in the reviewer’s head. So the causality and context of the code were held distributed across several heads, not concentrated in one.

Generation Takes a Second, Verification Stays the Same

But in the AI era, these two layers thin out fast. The most fundamental reason is that the cost of generating code and the cost of verifying it are asymmetric. AI’s marginal cost of producing code converges to nearly zero. A single line of prompt, and dozens or hundreds of lines pour out. But the cost of properly verifying that code doesn’t drop at all. The longer the code and the deeper the context, the more time and focus verification takes, unchanged.

On top of this comes the organization’s pressure for speed. Team productivity tends to be measured by the number of merged PRs and deployment frequency, not by how well the team holds the code.

So the person spending an hour verifying code that came out in a second looks like the slowest person on the org’s metrics. Next to the thrill of producing fast, the labor of verifying slowly starts to feel like an irrational act. Critical acceptance isn’t something willpower alone can sustain; it’s the kind of thing that slowly collapses under the economic pressure of time and efficiency.

And So Even Review Gets Handed to AI

The smoothest exit this pressure finds is handing even the review over to AI. Lately I keep getting asked, “if AI does the review too, doesn’t the review bottleneck disappear?” — and the question itself is a signal that verification is already seen as a cost to clear away fast. In practice, when a PR comes in, an AI review bot leaves a summary and some comments on its own, and a person skims that summary and leaves a one-line “LGTM” — a scene that’s getting more and more familiar.

But the review AI leaves only looks like verification; it isn’t. It too is just one more plausible output with the causality missing — no trace of anyone taking responsibility for judging right from wrong. Handing review to AI doesn’t solve the verification bottleneck; it’s closer to skipping the step of verification entirely.

The moment both writing and review become AI, the causality of that PR lives in no one’s head on the team. The author never held it, and the approver just stamped it. The organization ends up running a system that no one possesses. People often believe the principle of “I operate the code I built” guards against this. But that principle guaranteed ownership back when building meant understanding — and the moment AI does the building, that link snaps. A state where I operate it but the causality of that code isn’t in me, something that would have been a contradiction before, simply becomes possible. The approver who can’t verify — the one stamping a contract they can’t read — becomes not a single deviation but the organization’s default state.

Industries That Passed Through This Anesthesia First

This isn’t even something developers are the first to face. Aviation passed through this anesthesia decades earlier. In her 1983 paper Ironies of Automation, Lisanne Bainbridge pointed out that as automation advances, only the hardest exceptions are left to the human — while the very skill to handle those exceptions atrophies because of the automation. One of the causes cited in the investigation of the 2009 Air France 447 crash was that the crew couldn’t manage the manual control demanded the instant the autopilot disengaged. It wasn’t one person but the whole cockpit that went powerless at once — and these were people who used automation better than anyone, day to day.

And it’s not just aviation. Think about what happened to the maps in our heads once we handed wayfinding over to GPS. London taxi drivers who pass the test of memorizing the entire city’s streets have a larger hippocampus — the region in charge of spatial memory — than ordinary people, according to one study. Conversely, a follow-up study found that the more habitually someone relied on GPS, the more steeply their hippocampus-dependent spatial memory declined over time. A brain that has felt its way along the roads grows; a brain that only followed directions shrinks. The difference between the one who holds the causality and the one who only receives the result shows up even in the volume of the brain.

Medicine knows the same trap. A study analyzing hundreds of thousands of digital mammography reads in the US reported that attaching computer-aided detection (CAD) to flag lesions improved reading accuracy on no metric at all — and that among radiologists who had worked both ways, sensitivity was actually lower when using CAD. As the eye grows accustomed to what the tool points out, the human comes to miss what the tool missed too. That’s exactly the price you pay when you hand verification to a tool.

On top of this comes the cruelty of the time lag. Suppose a flaw in code AI wrote blows up as an incident six months later. If the team’s ownership has dulled enough over those six months, then at the very moment the problem hits, the ability to handle it may be nowhere in the organization. The ability to deal with the flaw shrinks faster than the flaw grows.

Taste Grows Only Inside Breakdown

What makes anesthesia uniquely frightening is that it arrives not as pain but wearing the face of comfort. So it’s worth looking once more at exactly what that comfort numbs. These days you hear it said of developers in the AI era that “what matters now is taste.” Hand implementation to AI, the saying goes, and a person only needs the eye to recognize what’s good. Half of that is right. In the work of picking the best one out of the pile of probabilistic outputs, that eye is becoming an ever more decisive variable. What I called cognitive ownership earlier is, in the end, just another name for this eye.

The question is where that taste comes from. People who talk about a taste economy mostly treat the eye as an innate sense, or as something cultivated by looking at lots of good output. But the eye that tells good code apart doesn’t come from reading lots of good code. It’s the result of something we wrote breaking, of stopping at the break and feeling out by hand why it broke, and of not writing it that way the next time — etched into the body across countless rounds.

There’s a famous example Heidegger gave, of hammering. A hammer that fits your hand recedes from awareness while it works smoothly — you forget it’s even a hammer — and only when the head comes loose and the nail spins does it surface before you as an object. We come face to face with a tool’s essence, and the causality beneath it, paradoxically when it breaks. That story holds for code too. The moments when the compile broke and you were stuck for ages not knowing why — those were the very forge where a sense of good and bad was hammered out.

So taste isn’t passed on as propositions. Memorizing a hundred rules like “reduce side effects” won’t give you the eye to recognize good design. That eye is closer to a kind of knowing tamed by getting burned firsthand across countless individual cases, not a list of rules.

What Aristotle set apart from book-learned knowledge and called “practical wisdom” is exactly this kind of thing. It grows only in a place where repeated practice has settled into habit. So a taste that has never once gone through implementation is a bit like claiming to know the destination of a road you’ve never walked. It may not be a contradiction in terms, but it’s at least a taste that doesn’t even know what it doesn’t know.

And right here is AI’s quiet trap. AI doesn’t remove the breakdown; it removes the experience of going through the breakdown. It fills in the spots where you’d get stuck on its own, and sutures the broken places before you even get to look at them.

It wears the face of convenience, but every moment smoothly filled in is, in fact, one forge — where taste could have grown — quietly closing. The real trap of anesthesia isn’t that it erases pain. It’s that along with the pain, it erases what could only grow through that pain. So there’s always one thing missing from the phrase “taste economy”: in a world where everyone holds the eye and no one gets broken at the bottom, where exactly is that eye supposed to grow anew?

Hiring Where the Apprenticeship Has Been Cut

From a leader’s standpoint, the place this anesthesia works most awkwardly is the hiring and development of new talent.

The forge from the previous section is what we’ve long called apprenticeship. A senior with good judgment doesn’t fall out of the sky one day; it’s a junior who fumbled writing a comma-inserting regex from a blank page and chased causality through the night to catch an incident who, in time, comes to stand in that seat. The time spent paying the price of verification was the very substance of apprenticeship.

When AI Lets You Skip the Apprenticeship

The problem is that AI lets you skip this whole path of apprenticeship. For a developer who’s had AI beside them since their first day, skipping verification isn’t a compromise made at some point; it’s the default given from the start. And judging by output alone, even a junior who skipped the apprenticeship produces plausible code fast enough with AI attached. As I said earlier, what AI levels is plausibility, not skill — so in terms of visible productivity, the difference barely shows.

Here the leader faces a nasty temptation. If the output is similar anyway, why bother eating the inefficiency of letting a junior feel their way along the bottom? Attaching AI to produce results fast is far more favorable to the quarterly metrics.

But once that choice stacks up over a quarter, then two, the very supply of people who can tell code apart dries up. The death of implementation ownership doesn’t show right away, then returns a generation later as the depletion of judgment ownership — and by then there may not even be anyone left to notice the depletion.

What makes this depletion fatal is that what ultimately determines a developer’s worth is the judgment of what’s right and what’s worth building. And that judgment, as we saw in the previous section, grows only in a place where you’ve felt out the bottom of implementation yourself.

Here a counterargument is possible. Even if you hand implementation entirely to AI, if a human stays deeply involved in the design decisions, won’t judgment grow on top of that? It’s a fair point — and in fact that’s the core of the prescription I’ll get to later.

Only, that involvement doesn’t happen on its own. With a plausible result one button-press away, deliberately stopping to ask yourself “why this design in particular?” runs straight against the economic pressure we saw earlier. So co-design — handing off the implementation but keeping the causality of the decisions in human hands — isn’t the default that happens if you leave things alone, but an exception you have to consciously design in. The moment delegation without involvement, delegation that hands off even the decisions, hardens into the default, the soil where judgment’s causality could grow is gone.

A seat where you have to choose between short-term productivity and the long-term supply of capability — that’s the leader’s seat. And this choice isn’t one an individual developer can solve by will; it’s the kind that’s only solved when an organization decides to deliberately bear the cost.

This Isn’t a Problem to Settle by Grumbling About Fundamentals

I don’t want to end this by chalking it up to a lament that individuals lack fundamentals. That’s not much different from the old lament aimed at the generation that didn’t learn assembly — and I’m a beneficiary of that very lament. Every time a tool climbed a layer, the baseline shifted, and good developers kept emerging above the shifted baseline all the same.

But as I noted, this time is different. The earlier abstractions only hid the causality; they didn’t erase it, so you could always climb back down the ladder and check it directly when you needed to.

On top of a probabilistic proxy like AI, though, that ladder doesn’t lay itself down on its own. The path to climb to the bottom and touch the causality directly simply doesn’t appear if you leave things alone. So this isn’t a question of who’s lazier or less talented. Whether capability grows or not is, increasingly, decided not by an individual’s will but by the structure they’re placed in. And the one in a position to decide whether to lay that ladder — the one AI carried off — back into the team, even artificially, is the leader.

The Prescription Has to Be Team Structure, Not Individual Resolve

The problem is that protecting ownership doesn’t run on resolve alone. As we saw, what makes people skip verification isn’t will but economic pressure — so the prescription, too, has to be built as a structure of action you can’t easily slip out of, not just a state of mind. And at the organizational scale, the one who can build that structure is the leader, not the individual developer.

The Inefficiency of Ownership Is an Insurance Premium

Before building the structure, though, there’s something to admit honestly. Protecting ownership is plainly inefficient. You’re having a person hold onto code that would take a second to generate, so on short-term metrics it almost always looks like a loss. An appeal of “it’s the right thing, so bear with it” won’t let that inefficiency hold out for long against economic pressure.

That’s why this cost has to be justified in the language of accounting, not morality. The inefficiency you spend on ownership isn’t a loss but an insurance premium.

Recall the time lag from earlier. A flaw AI planted doesn’t hand you the bill now; it comes back months later as an incident, all at once — and at the very moment when the ability to handle it has drained most from the organization. The cost of a single incident easily exceeds the sum of all the verification time you saved.

The speed of a quickly merged PR shows up clearly on the quarterly metrics, but the way that saved time swells into incident costs several times over later shows up on no metric at all. The leader’s job is to write that invisible bill into the ledger in advance. If you don’t account for the inefficiency of ownership as a premium to be paid rather than a luxury, the structures below will be the first line items cut in the race for speed.

Here someone might push back: the market runs on speed in the end, so if an organization that ships fast — anesthetized or not — wins, isn’t ownership an idle luxury? It’s a fair point, but a counterargument that leaves out two things.

First, that “winning” is mostly a victory on the quarterly metrics. The incident cost we saw earlier is just piling up behind, unrecorded on those metrics; it only looks like winning until the bill arrives.

Second, speed is a moat only while models are scarce. The moment everyone holds the same AI, generation speed levels out, and the remaining difference shifts to the power to tell the output apart and verify it. So ownership isn’t a nostalgia that resists the market, but the very ability the market will start pricing once speed becomes common. Slowing the anesthesia isn’t giving up efficiency; it’s closer to remaining one of the few who can still tell good from bad in a world where everyone got fast.

On top of all that, what I’m holding onto is less a list of rules to adopt right now than a few directions. Even the same direction will take quite different shapes from team to team.

A Human Holds the Final Responsibility for Verification

As we saw, handing review wholesale to AI isn’t a convenience but closer to an organization collectively setting down its cognitive ownership. So the first direction is to move the responsibility for verification off individual will and onto team structure — while tying the end of that responsibility firmly to a human. Under the pressure of an 11 p.m. crunch, the first thing to collapse is individual resolve, so you have to nail friction that makes verification impossible to skip into the procedure at every point.

For example, you nail it into the review rules that code whose causality can’t be explained doesn’t get merged, and have a person write “why it was written this way” in their own words in the PR description. Having a reviewer or leader occasionally pick a PR at random and ask out loud, “why did you leave this branch this way?” — building in that artificial pressure — is one way too. It also helps to shift the meaning of a one-line “LGTM” from a pass-stamp to a declaration of “I can explain this code.”

This direction has a clear limit, though. Reading and explaining after the fact is a weaker weapon than holding the causality from the start, and an AI that spits out plausible code in a second writes a plausible “why” in a second too. So if you stop at writing it down, you just get AI’s excuse layered one more time on top of AI’s code. The real purpose of this direction isn’t so much to grow ownership as to stop the worst case — code that can’t even be explained flowing straight through — and to create the moment the forgery gets caught: the moment when an explanation that read smoothly on paper stalls in the face of a follow-up question. Text can be forged, but that stall is hard to fake, and the eye that catches it is the leader’s discernment I’ll come to later.

Humans Hold the Design, and We Teach How to Hand It to AI

If verification is a net cast after the fact, design is grasping the causality beforehand. Even if you hand implementation to AI, the design decisions of what to build and why stay in human hands first. I said earlier that co-design is an exception that won’t happen if left alone — this direction is exactly the attempt to raise that exception up into the default.

Concretely, it’s a flow where a person first lays out the design, hands it over translated precisely into a spec down to the constraints and edge cases, and verifies what comes back against that same design. And this work of holding the design and handing it to AI precisely shouldn’t be left to individual instinct; it has to be treated as a capability the team researches and teaches together. Not the skill of writing good prompts, but the skill of getting the design in your head out into the open without leaving anything behind.

Choose the Strongholds You Won’t Give Up

Maintaining ownership across every area is impossible. So rather than trying to hold it all, it’s more realistic to deliberately set a few strongholds you’ll never let go of. That stronghold might be the core domain at the team’s center, or the area a human ultimately has to touch directly when an incident hits, or the area carrying the heaviest responsibility to explain to the outside.

In those chosen strongholds, at least, you value understanding slowly over producing fast. A team with strongholds and a team without differ in their very power to verify unfamiliar territory — because a sense of what good code is starts, in the end, from having seen the bottom somewhere.

Turn the Inefficiency into a Learning Path

The inefficiency of growing ownership is hard for an individual chased by quarterly metrics to choose on their own. So this is an experience that only comes about when the organization decides to bear it as a cost.

It looks like picking one small area and having someone climb to the bottom without AI, or — when their own code breaks — letting them feel out the causality themselves instead of being spoon-fed the answer, or deliberately putting a junior on the core domain you set earlier and giving up speed there alone.

Ritualizing a regular “tool-less time” with AI switched off is another way. Like deliberately loading the muscle, it’s about occasionally pushing a problem all the way through with hands and head alone. Only someone who knows in their body what ownership is can choose whether to protect it, and such a person is grown by team design, not individual will.

Measure Ownership, Not Just Speed

If everything so far was about process and people, the last is about metrics. The root of the problem this post traced was, in the end, that organizations measure only speed, which makes verification look irrational. If so, the most fundamental prescription is to change what gets measured. Next to merged-PR count and deployment frequency, you place a gauge showing how well the team holds its own code.

The share of code no one can explain, or how often explanations stall under random spot checks, could be such gauges. The time it takes to resolve an incident is also a signal — because an organization missing ownership takes longer to feel out the cause when a problem actually hits. But this number swings with the difficulty of each incident, so rather than nailing the absolute value as a KPI, it’s better to read the trend, and in the postmortem to ask, separately, whether the slow resolution was because the problem was genuinely hard or because no one held the causality of that code. If the latter keeps repeating, that itself is a signal the organization is being anesthetized.

There’s a caveat, of course. The moment any metric gets nailed down as a target for evaluation, people start chasing the number itself instead of the real goal the metric pointed at (Goodhart’s law). Put “explainability rate” up as a KPI and you get plausible explanations mass-produced to hit the number instead of real understanding — the same forgery we saw earlier, repeating on top of the metric. As the speed metric was, the ownership metric is no exception. So this is safer kept not as a KPI to optimize but as a gauge you glance at now and then to see whether the organization is dulling.

In that sense, deciding that in hiring and evaluation you’ll look at “can they explain the causality of what they produced” over “how fast can they produce with AI” is one move that works more powerfully than any gauge.

I should say in advance: the outward shape of these prescriptions resembles the ones I brought up in the April post while talking about individual growth. What changed is the subject. Back then it was the technique of one person protecting their own capability; now it’s the design of an organization keeping the supply of that capability from drying up. Even the same motion — preventing your own muscle loss alone versus managing the whole team’s muscle mass — carries a different weight.

The Approver Who Can’t Verify Might, in the End, Be Me

So far this post has widened its subject one notch at a time, from the individual to the organization. But follow that subject one notch further, and at the end a single person remains again. The leader who’s been told to build the structure — me. And right there, the most chilling picture in this post comes into view.

In my second post, I wrote that no matter how far AI advances, the human role of stamping the final approval won’t disappear. Because when something goes wrong with the code, someone is needed to take responsibility — and that judgment still holds. But overlay this post’s anesthesia onto it, and while the responsibility structure keeps the stamping seat in place, the anesthesia erases — selectively — only the ability to stamp. In the end, only approvers with feeble verification ability are left.

And thinking about who that approver would be doesn’t sit easy. The person holding the stamp in an organization is usually the one carrying the greatest responsibility, and the one carrying the greatest responsibility is usually the one furthest from the code — the leader.

A leader drifting away from the code isn’t, in itself, a problem AI created. The sense for telling code apart rusting as you focus only on managing is something that’s always happened. What changed is the support that propped up that rust.

As I said, a leader used to drift from the code while an author and a reviewer holding the causality lay underneath in two layers. Even if the leader rusted personally, the ownership distributed across the organization propped it up. But the moment writing is AI and review is AI, that prop is pulled out entirely. The leader’s rust no longer stays a personal problem; it becomes the default of an organization with nothing left to prop it up.

In other words, the person best positioned for the anesthesia to reach first and deepest may be the very one carrying the final responsibility for approval. The fact that someone like me — who barely writes code at the company — is the one holding the final approval stamp is exactly what turns chilling at this point. Because for an approver left with the seat but not the ability, responsibility becomes not a shield but a bill.

What a Leader Has to Protect Is Discernment

So the structures I described earlier are, before they’re a prescription for the team, also a prescription for the leader themselves. But what the leader has to do here isn’t verify every line of code directly. That’s neither possible, nor — demanding full verification from a leader already far from the code — would it yield anything but one more plausible stamp.

What a leader needs isn’t full verification but discernment. The sense to tell whether the causality the team wrote down is real or a plausible wrapping. That sense isn’t maintained by staring at metrics from a desk, so it only stays unrusted if you climb down to the bottom of the core domain yourself now and then. A leader going down to the bottom isn’t to take sole responsibility for that code, but to keep from losing the eye that notices the team’s explanations rotting. A leader who forces a standard on the team that they themselves can’t even tell apart only lays one more layer of authority on top of an anesthetized organization.

Closing

It’s been a long way around, but the illusion I wanted to break in this post is a single one: the belief that the ability to handle AI well is itself the road to becoming a capable developer. Handling ability and cognitive ownership aren’t the same axis; they’re closer to a relationship where one quietly gets shaved down while the other rises. And that shaving doesn’t end inside one person’s head — it spreads, emptying out the organization’s head wholesale.

So the question I posed in earlier posts has to move over a notch too. As an individual, it was enough to ask, “Can I still verify what I put out, and if I lose that ability, will I even notice I’ve lost it?” But from a leader’s seat the question changes: “Can our team verify what we put out? When that ability dries up across the organization, will I — the one holding the stamp — notice? And the ladder for the next generation to ever hold that ability, am I leaving it in place?”

Of course, none of this stops the anesthetic from circulating. Maybe there’s no such thing as an organization that stays un-anesthetized to the end. If so, what a leader can control isn’t whether the anesthesia happens but the speed at which it spreads — and keeping your team an organization that can tell good from bad a little longer than others becomes the one graspable goal. It doesn’t guarantee immunity, but it buys a reprieve.

Honestly, I don’t have a clean answer for what an organization should do beyond the critical point. But not building, with my own hands, a system that rolls along drunk on the anesthetic of efficiency while no one even knows what they don’t know — that’s about as far as the minimum resistance I, as a leader, can manage right now goes.

So today, again, I review the code AI wrote, ask the team for explanations, and now and then climb down to the bottom myself. Not because I know the answer, but because I hope the sense that it’s frightening to put out code you couldn’t verify stays, for me and for our team, the very last thing to go.

And with that, I’ll bring this post to a close.

What Leaders Should Really Worry About Isn't Productivity

댓글