Two engineers on a team I know solved the same problem last quarter. Different weeks, different tickets, roughly the same answer. Neither knew the other had done it, and neither knew a third person had solved a near-identical version the quarter before that. Three private conversations with a model, three good outcomes, zero institutional memory.

Here is the uncomfortable part. Every one of those engineers got better at their job that quarter. The bank did not get better at anything. Both things are true at once, and the reason they are true at once is the whole story.

Individuals are getting smarter. The company is not.

The consensus reading of the productivity data is that AI adoption is failing, and that reading is half right in the way that matters least. The METR study found experienced developers using AI finished tasks 19% slower while believing they were 24% faster. Jellyfish looked at twenty million pull requests and found that while three in four engineers use AI tools, most organizations show no measurable delivery gain. The usual conclusion is that the tools do not work.

They work fine. What is not moving is the institution, and that is a different failure with a different cause. The individual absolutely is compounding: the engineer who used an agent well on Tuesday is better at using it on Wednesday, carries the instinct into the next task, builds private judgment about when to trust the output and when to throw it away. That learning is real. It just has nowhere to go. It lives in one person’s chat history and dies there, and the org around them learns nothing, so the same lesson gets rediscovered from scratch down the hall the following week.

Most companies solved the tooling problem. They have the licenses, the seats, the approved model endpoints. What they never solved is the visibility problem, and visibility is the thing that turns individual learning into institutional learning. I have circled this before from the outside: in The Bottleneck Was Never the Code the failure was buying a platform instead of a workflow, and in Same Question, Different Worlds five engineers returned five different builds from one instruction. This is the layer underneath both. The work got done. The knowing did not spread.

The apprenticeship loop broke, quietly

For most of human history, skilled work was learned by proximity. You sat near someone who was good, and you watched. You saw how they framed the problem before they touched it, what they noticed, what they ignored, where they slowed down and where they did not bother. The craft transferred in a thousand small observations that nobody wrote down, because nobody could. Michael Polanyi named the reason: we know more than we can tell. The most valuable part of expertise is the part the expert cannot articulate, so it can only be caught, not taught.

Agentic work severs that loop, and it does it silently. The senior engineer’s thinking now happens in a private window. The junior engineer never sees how the senior person scoped the task, what context they pasted in, what the first answer looked like, or the moment they pushed back and said no, that is wrong, do it this way. The correction that turned a mediocre agent run into a good one is the single most instructive thing that happened all day, and it is invisible to everyone except the person who made it. The apprenticeship did not get worse. It stopped existing, and no meeting was held to decide that.

Amazon is the tell. Reports from inside describe six to ten separately vibe-coded internal tools for the same problem, each built by someone who had no idea the others existed. That is not a tooling failure. That is an institution that has lost the ability to know what it already knows, and it is the predictable end state when every solution is born in a private conversation and never surfaces.

One product rule fixed it

Shopify built the most interesting answer I have seen, and the interesting part is not the numbers, even though the numbers are large.

Their internal coding agent, River, posted real volume: in one thirty-day stretch nearly six thousand employees used it across more than four thousand Slack channels, and in a single week it opened around eighteen hundred pull requests against the main monorepo, with roughly one in eight merged PRs now coming through it. Those figures are what everyone quoted. They are not the point.

The point is a single constraint. River cannot run in a direct message. Every conversation with it happens in a public channel, by product rule, not by policy poster. So any engineer can scroll back and watch exactly how a senior colleague scoped a task, what context they loaded, where the agent got stuck, and what they rejected and why. The apprenticeship loop that the private window severed, Shopify welded back together with one design decision that individuals probably find mildly annoying and the institution quietly compounds on. The mechanism is not culture. Culture is what you hope for. The constraint is what you ship.

Share the four things, not the answer

If you want the loop back, sharing the output is close to worthless. The finished PR teaches almost nothing, because the finished PR is the part the agent could have produced for anyone. Four things carry the actual learning, and they have to be shared together:

• The task. What was the person actually trying to get done, in their own words, before the tooling touched it.
• The context. What they told the model, what they pasted in, and, just as important, what they deliberately left out.
• The interaction. How they prompted, what the first answer looked like, and how they pushed back when it was wrong.
• The review. What they accepted, what they rejected, what they verified by hand, and what they rewrote, and why.

Share only the answer and the team learns nothing. Share all four and the team starts to build shared taste, which is the real bottleneck in AI adoption and the thing a prompt library can never capture. A prompt library stores the clean instruction and throws away the messy context, the revisions, and the “no, that violates our tone” moment where the judgment actually lived. The most valuable part of AI work is almost never the prompt. It is the habit around the prompt, and habits only transfer when someone can watch them.

The hardest version of this is the senior-people problem. The most senior person has the most valuable judgment and the least visible process. They use an agent to pressure-test a plan, rewrite a risk memo, compare three remediation options, and none of it is ever seen by the people who most need to learn how they think. Toby Lütke reportedly runs his own work in a public River channel and lets other engineers question his agent and critique his choices. That is not humility theater. It is the best teaching a senior person can do now, because the junior engineer no longer copies the prompt. They watch the judgment, they see a good operator push back, and they learn that using AI well is active supervision, not passive consumption.

The capture mechanism is already in your building

Here is the part that should land specifically for a bank, and it is the same shape as an argument I keep coming back to.

You already run infrastructure whose entire job is to make consequential decisions legible. Change records with a documented rationale. Architecture decision records. Incident postmortems that reconstruct what someone knew and when. Audit trails that exist so an examiner can reconstruct a judgment months later. You built all of it to satisfy regulators, and it is, structurally, exactly the capture mechanism the apprenticeship gap demands. You have the machinery for making private reasoning visible. You are just pointing it at the auditor and never at the engineer beside them.

I made a version of this case in The Documentation Dividend and again in The Bottleneck Was Never the Code: the artifacts you produce for compliance are also the artifacts that make you better, if you read them as specification instead of paperwork. The apprenticeship gap is the same inversion. The bank that already documents every material decision for the examiner is one product rule away from documenting how its best people actually work, for the people sitting next to them. The aircraft carrier does not turn fast, and its size is usually treated as the reason it cannot learn quickly. It is actually the reason it can, because the discipline of writing things down is already mandatory here. Most companies would have to build that habit. You would only have to redirect it.

Measure the right thing

The trap is measuring adoption. Seat utilization is up, tokens are up, and none of it tells you whether the institution learned anything. The metric that reflects reality is harder to capture and worth the trouble: how many reusable workflows did a team surface from its public channel last month, how many got picked up by another team, how many failures turned into a better review rule. The best signal of all is the one that sounds too soft to be a metric and is the only one that matters. We are making that mistake less often.

That is what an institution getting smarter actually looks like. Not more usage. Fewer repeated errors, because the correction one person made in a private window on Tuesday is now something the whole team can see.

Alex Hormozi has a line I keep near this problem: we do not rise to the standards we have when others are watching, we fall to the standards we have when no one is. The private AI window is the room where no one is watching, and right now it is where all the learning is happening and none of it is being kept. Peterson’s version of the same instinct is to take the whole responsibility on your own shoulders. The responsibility here is not to adopt more AI. Your people already did that. It is to build the one constraint that turns their private competence into something the institution gets to keep.

---

Your engineers are compounding. Make sure the institution is on the same curve, because right now it is watching its smartest people get smarter in a room it cannot see into, and calling the flat delivery numbers a tooling problem.

This is the employer-facing half of a thread I have mostly written from the family side, in When Your Team Starts Building and the skill-issue essays. The organization is still the variable, not the model.

Find me on X @orestesgarcia or LinkedIn /in/setsero.