What we used to be protecting
For the entire history of the industry, the codebase was the asset. We built whole organizations around producing it, paid seniors to protect it, structured teams to maintain it, designed performance reviews to measure how much of it each person produced.
It isn’t anymore.
Code is cheap to produce now. Anyone with an agent can generate plausible code at any volume. The constraint is no longer how much code gets written; it’s whether the code that gets written fits the system, fits the team, and serves the business. That’s judgment. And judgment lives in people.
The asset moved. From the artifact to the people who can shape the artifact correctly. From the typing to the thinking. Most of our org structures haven’t moved with it – we still measure throughput, still optimize for headcount efficiency, still treat juniors as a cost center. The category error is firing the people who carry the new asset to protect more of an artifact that no longer is one.
This article is a short list of structural moves that follow from accepting the shift. None of them are glamorous. All of them are concrete. Together they’re the org’s commitment to the craft – made out loud, then kept on the calendar.
Seniors need training too
To make aggressive movement toward reintegrating juniors, the whole organization has to change – and that includes the seniors. Juniors are being asked to move up in abstraction, as article 3 argued. Seniors have to move up too. They need to learn how to write the same correct, beautiful code they always have, but with a more efficient stack. They need to learn how to fold the new tools into the old ones. They need to learn to augment their reviews, their mentorship, and their own daily practice with tools that didn’t exist three years ago.
Most seniors picked up these tools the same way their juniors did – without explicit training, learning by stumbling, developing habits without examining them. Seniors are not immune to the disease. They’ve been making smaller versions of the same mistakes their juniors are making, with more leverage and more subtle consequences. The org’s first commitment is to train seniors too – and first, because seniors set the patterns juniors learn from and run the review queue that decides what ships.
Senior training is lighter than junior training. Three specific moves, mostly trainable in workshops rather than curricula.
Reviewing differently. Line-by-line review has been replaced by review at the architectural level – the IoC, error, and concurrency questions, asked with the depth seniority allows. It is a fundamentally different kind of feedback than what they used to give, and it takes a few hours of practice on real PRs to make the shift.
Rejecting with compassion. The senior who closes a PR with “this is hot garbage” demoralizes the junior and teaches nothing. The senior who closes the same PR with “good effort. I’m throwing this whole thing away because doing so will cost us both less effort. Here’s what I see…” – followed by two or three concrete red-green indicators – accomplishes the same outcome and teaches in the process. That second sentence is itself a trainable skill. An afternoon of role-playing rejection comments, with the team’s actual conventions as the indicators, gets a senior there.
Extracting lessons into process. This is the senior’s most leveraged work in the new conditions. When a mistake or a good move shows up twice in the team – when juniors keep producing the same misshapen pattern, when the agent keeps losing track of the same convention, when a PR happens to do something exactly right – the senior’s job is to extract the lesson into a process change that propagates the pattern or prevents the antipattern. Patterns get encoded in prompt scaffolds, skills, commands, PR templates, documented conventions the agent can read. Antipatterns get caught in linters, hooks, and review checklists that close the door before the failure ships. The senior who does this work crystallizes their judgment into infrastructure – accessible to every junior on the team, durable across personnel changes. Mentoring helps the junior in front of the senior. Extracting helps every junior on the team, forever.
This is the work that should fill a real fraction of every senior’s week. Most orgs are not making space for it. That’s the next set of moves.
🎯 Join Groxio's Newsletter
Weekly lessons on Elixir, system design, and AI-assisted development — plus stories from our training and mentoring sessions.
We respect your privacy. No spam, unsubscribe anytime.
What the org owes the work
Five structural moves. None are glamorous. All are conditions for the practices above to take.
Protect senior craft. Seniors who spend every day in the review queue stop being seniors. Their coding skills atrophy. Their architectural muscles soften. Block recurring deep-work time on every senior’s calendar – a day a week is defensible – and don’t let review queue depth eat it. Monday move: look at your seniors’ calendars. If there’s no protected block, add one tomorrow.
Make mentorship measured, scheduled work. Mentorship is currently invisible labor – it doesn’t show up on tickets, doesn’t move velocity, doesn’t get rewarded at review time. Fix this bureaucratically. Mentorship hours go on the calendar as recurring work, count in capacity planning, appear in performance reviews. Monday move: name a metric – hours per week per senior spent on mentorship. The act of measuring it changes the conversation about whether it’s real work.
Stop measuring the wrong things. Velocity and throughput are signals from the old asset model. They’re now actively misleading – a team that doubles velocity by accepting more AI-generated code is destroying value, not creating it. Better signals: PR size, time-to-merge for small versus large PRs, lines of code deleted, mentorship hours per senior, junior judgment growth. None are perfect. All are better than throughput. Monday move: add one of these to your dashboard. Watch it for a quarter. Then add another.
Build in breathing room. This is the move most engineering orgs will instinctively reject and the one that makes everything else possible. The agents made typing capacity abundant; what’s scarce now is thinking capacity – deep concentration, quiet mornings, unstructured pairing. None of that fits in a fully-packed calendar. The economic case is straightforward: the asset you’re trying to grow does not grow on a fully-packed calendar. Monday move: cut next sprint’s commitment by ten percent. The work that shows up in that ten percent is the work the org needs.
Retain the juniors. The juniors you keep through the next two years become the seniors of 2030. The ones you let go become someone else’s pipeline. The dividend compounds in the people you keep. The org that figures this out first will have an internal pipeline a decade from now while competitors are paying premium rates for senior contractors with no institutional memory. Monday move: pick one junior on your team. Have a real conversation about their growth path. Don’t make them ask twice.
What we pay with the dividend
We started this series with a pact: some of the time AI is giving us belongs to the future of the craft. Most of the industry hasn’t kept it. The dividend has been spent on producing more of the old asset – cheaper code, faster, with fewer of the people who used to know how to keep code good.
This article has been about what the dividend should be paying for instead. Senior training. Senior craft, protected. Mentorship, measured. Better signals than throughput. Breathing room on the calendar. The juniors who will be your seniors in a decade.
Code is cheap. Judgment is not. The org that recognizes the shift first wins the next ten years. The org that doesn’t will run a lean operation that ages badly, with no internal pipeline and no institutional memory, and no way to recover when the next platform shift arrives. There will be a next one. There always is.
A small picture before I let you go. Eight months from now, on a team that made these commitments, a junior – call her Priya, you have someone like her – has been with you for most of a year. She’s shipping less code than she did in her first month, and shipping it on purpose. She closes her own PRs sometimes when she looks at them with fresh eyes and recognizes they don’t fit. The senior reviewing her work has time to mentor her, because the org made that time real on the calendar. Priya’s manager is tracking her judgment growth, not her commit count, because the dashboard finally measures the right thing.
She’s going to be the senior architect of this team in 2032. Your competitors fired her. You kept her, trained her, protected her growth, and made the place around her serious about the craft.
That’s what we pay with the dividend. The juniors aren’t the problem. The codebase isn’t the asset. The future is the people you grow with intent.
We don’t know if there’s enough time. The tools are still moving. The economics could turn. The window for getting this right could be longer than we hope or shorter than we fear, and nobody writing about this – including me – knows which. What I do know is that the bet is the same regardless of how the timing breaks. Train the seniors. Train the juniors. Protect the calendar. Measure the right things. Keep the people who are going to carry the craft forward, in case the future needs them.
It’s the only move that works in any of the futures we named. It’s also the move you can start tomorrow.
That has to be enough.
🛠 Train the People Who Will Carry the Craft Forward
This post is from Bruce Tate's series on what the AI coding crisis is doing to engineering teams — and what it would take to train through it instead of around it. Groxio runs private training and ongoing advisory for engineering teams using AI with Elixir, Phoenix, OTP, LiveView, Ecto, Ash, and Postgres. We start with a diagnostic conversation about where your review queue, your seniors, and your codebase actually are.
— Bruce