Everyone agrees AI makes senior engineers more valuable. Almost nobody asks where the next generation of seniors is supposed to come from. The work AI automated away was never waste, it was the apprenticeship, and the hiring data says the bottom rung is already gone.
There's a story the industry loves telling right now: AI makes senior engineers more valuable. The people with judgment, the ones who can smell a bad design from the doorway, are the winners of this shift. It's a comforting story. It's even true.
It just has a hole in the middle big enough to drive a hiring freeze through. Seniors are not a renewable resource. Nobody arrives with fifteen years of scar tissue preinstalled. Every senior you've ever worked with started as a junior who got handed unglamorous work and spent years doing it. And AI has quietly eaten the exact work those years were made of.
This isn't a piece about whether AI writes good code. It writes plenty. It's about what happens to the supply of people who can tell.
Where Seniors Actually Come From
Ask a senior engineer what made them senior and you won't hear "a certification." You'll hear about systems they broke, incidents they sat through, codebases they had to read for weeks before anything made sense. Judgment isn't downloaded. It's accumulated through thousands of small collisions with real systems, most of them unglamorous, many of them boring at the time.
That's the part the "seniors win" narrative skips. It treats senior supply like weather, something that's just out there, replenishing itself. It isn't. It's manufactured. Slowly, expensively, by teams that gave someone a bottom rung to stand on and tolerated the wobble.
Your hiring plan probably assumes that when you need seniors in 2030, you'll hire them from the market. Fine. But the market is just other companies' former juniors. Someone, somewhere, has to be running the apprenticeship, or there's nothing to hire.
The Grunt Work Was the Curriculum
Think about what a junior developer's week actually looked like before AI tooling got good:
- Boilerplate - scaffolding CRUD endpoints and form validation taught the shape of the framework, where things live, what the conventions are and why they exist.
- Small bug fixes - the ticket nobody wanted taught you to read stack traces, then logs, then, crucially, other people's code. Not the code you'd write. The code that's actually there.
- Glue code - wiring service A to queue B taught how systems really connect: timeouts, retries, the config value that only matters in production.
- Tracing someone else's code - the "figure out why this happens" tasks built the mental model of the system that every future architecture decision would lean on.
- PR nitpicks - forty comments on your first pull request stung, and they were also the fastest taste-transfer mechanism the industry ever had.
Nobody defended this work. We called it toil, grunt work, the stuff you paid your dues on. So when AI showed up and started doing all of it in seconds, we celebrated. Finally, juniors can skip the boring parts and do the real engineering.
Except the boring parts were the training. An apprentice electrician spends years pulling cable and mounting boxes. Not because the master can't do it faster, but because that's how you learn how buildings actually work before anyone lets you near a panel that can kill you. Hand the cable-pulling to a robot and you still get wired buildings. You just stop getting electricians.
That's what the automation did. It didn't trim waste. It deleted the curriculum and kept the exam.
And it leaves today's juniors in a strange trap: with AI, they can produce more output than any junior in history, while collecting fewer reps than any junior in history. Output was never the point of junior work. The learning was the product; the tickets were just the delivery mechanism.
The Numbers Are Already In
This would be a hand-wavy think piece if the data weren't already showing it. It is, and from several independent directions.
SignalFire's State of Tech Talent report found that new graduates now make up just 7% of hires at Big Tech companies, with new grad hiring down more than 50% from pre-pandemic 2019 levels. The report also surfaced the quiet part said out loud: 37% of managers said they'd rather use AI than hire a Gen Z employee.
A Stanford team led by Erik Brynjolfsson analyzed payroll data from ADP, covering millions of workers, and found that early-career workers aged 22 to 25 in the most AI-exposed occupations saw a 16% relative decline in employment since late 2022. Software engineering is one of the flagship examples. Meanwhile, workers 30 and over in those same occupations grew 6 to 12% through May 2025. Same jobs, opposite directions, split cleanly by age. A recession doesn't check your birth year. AI adoption apparently does.
The downstream effect is visible in graduate outcomes too: New York Fed data puts recent computer science grads at 6.1% unemployment, against a 4.8% average for recent graduates overall. The major an entire generation was told to pick now underperforms the average.
And the sentiment behind those numbers is not subtle. In survey data covered by Stack Overflow, 70% of hiring managers said they believe AI can do an intern's job, and 57% said they trust AI's output more than a recent grad's work.
The bottom rung isn't loosening. It's already off the ladder.
Rational for One, Starving for All
Here's the uncomfortable part: nobody in this story is making a mistake.
Run the math for a single team, this quarter. A junior hire costs a full salary plus a meaningful slice of a senior's week for a year or more before they're net positive, and then they might leave for a 30% raise somewhere else. An AI coding tool costs less than the team's coffee budget and is productive this afternoon. If you're the engineering manager with one open req and a delivery deadline, skipping the junior is the correct decision. Any CFO would sign off on it. Most do.
The problem is that everyone runs the same spreadsheet. Each company individually decides to hire seniors "from the market" instead of growing them, and the market is nothing but the output of other companies' junior programs. Skipping juniors is free-riding on someone else's apprenticeship. It works beautifully right up until it's universal.
This is a commons problem, and the senior pool of 2031 is the commons. No single company owns it, no single company is punished for depleting it this quarter, and no line item on anyone's P&L represents it.
The lag is what makes it dangerous. The juniors not hired in 2025 are the mid-level engineers who won't exist in 2028 and the seniors who won't exist in 2031. And a missing cohort can't be backfilled later, because the thing you'd be hiring is years of accumulated judgment. You can raise a salary band in one budget cycle. You can't raise experience.
"Maybe AI Just Becomes the Senior"
The honest counterargument deserves a fair hearing, because it's not stupid. It goes like this: models are improving fast, so by the time the senior gap arrives, AI will be doing the senior work too. Worrying about the junior pipeline is like worrying about horse-stable capacity in 1910 while Ford ramps up the assembly line.
Take it seriously, and it still breaks on one stubborn fact: someone has to put their name on the merge.
When an AI-generated migration takes down production at 2 a.m., "the model did it" is not an incident report anyone accepts. Not your customers, not your auditors, not the regulator if you're in fintech or healthcare. Accountability is load-bearing in software organizations, and it can't be delegated to a system that can't be fired, deposed, or promoted. Some human reviews the output, approves it, and answers for it.
And review is not a checkbox. Reviewing well means knowing which diffs are risky and which are routine, what the blast radius of a schema change is, when the tests are green because the code is right versus green because they don't test the failure mode. That's judgment. It's precisely the thing the apprenticeship used to produce, in exactly the people we've stopped training.
So the "AI becomes the senior" future eats its own premise: the more code AI writes, the more the human job becomes review, and the industry is currently betting on that skill while dismantling the only machine known to produce it.
The Stanford data has a wrinkle that backs this up: employment held or grew in roles where AI augments people, and workers who used AI to learn and validate their work fared better than those who delegated whole tasks to it. The market is already sorting people, not by whether they use AI, but by whether they use it in a way that builds judgment or replaces it.
Keeping the Apprenticeship Alive
You can't fix industry-wide hiring incentives from your desk. What you can control is whether learning still happens inside the work you and your team already have.
If you're early in your career:
- Struggle first, prompt second. Give every problem a genuine attempt before you ask the model. The struggle is not an inefficiency to optimize away; it's the mechanism that writes the lesson into your head. AI is a phenomenal tutor when it explains something you already fought with, and a lesson-shredder when it answers before you've formed the question.
- Read every AI diff like a reviewer, because you are one. As far as git blame and your team are concerned, you wrote that code. If you can't explain a line in the diff, you're not done. Make understanding the deliverable, not the merge.
- Do some things the slow way, on purpose. Trace the framework call by hand once. Write the migration yourself before asking for one. You're not being a purist, you're doing reps, the same way athletes still lift weights even though forklifts exist.
- Get good at review early. Review is where the job is heading. Volunteer for it, study how the best reviewer on your team comments, and learn to articulate why something is risky. That skill compounds faster than raw output ever will.
If you lead a team:
- Hire one junior, with an actual plan. Not as charity, and not as a body for ticket throughput. A plan: rotations through subsystems, a named mentor with time carved out, attendance at incident reviews. One deliberately-grown junior beats zero on principle and beats three unsupported ones in practice.
- Assign understanding, not just output. Have them present how the payment flow works end to end. Put them on the on-call shadow rotation. Ask them to write the postmortem draft. None of this ships features, and all of it manufactures the thing you'll be desperate to hire in five years.
- Keep the instructive tickets human. Not the soul-crushing ones. Automate those with a clear conscience. But the gnarly little bug in the legacy module that forces someone to actually read the system? That ticket is tuition. Don't spend it on the model.
- Review AI usage together. Look at prompts and diffs in pairs, the way you'd pair on code. How a junior uses the model is their process now; if it's invisible, so are their gaps.
None of this shows up in this quarter's velocity. That's the point. The apprenticeship never showed up in velocity either, which is exactly why it was so easy to automate away without anyone noticing what it was.
The industry didn't decide to stop producing seniors. It automated the thing that produced them, one perfectly rational quarter at a time. The teams that have enough seniors in five years will be the ones that never stopped making them.
P.S. Thanks for taking the time to read this article! The ideas and opinions expressed here are my own. English is not my first language, so I use AI to help correct grammar and make my writing clearer and easier to read. If anything still sounds a little awkward, I appreciate your understanding!
Originally published at nazarboyko.com.
Enjoyed this one? Let's stay in touch - I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋
Top comments (160)
I've caught myself accepting AI suggestions that looked perfect, only to realize later I couldn't explain why they worked. That was a wake-up call. Now I use AI more like a reviewer than an author. It saves time, but I still force myself to understand every significant change before merging it. Otherwise, you're just borrowing confidence from the model. So, I don't think AI is replacing junior developers. It's replacing the mistakes juniors used to learn from. The hard part now is being intentional about creating those learning opportunities instead of letting AI smooth everything over.
Thanks for putting this into words.
Yes aggree, The ordering matters more than people expect. Using it as a reviewer instead of an author is the sneaky-good part. You have to form your own opinion before you ask, and that's where most of the learning actually happens. Skipping that step feels fast right up until something breaks at 2 am (usually at the weekend, for whatever reason) and you're reading your own code for the first time.
Haha, why is it always at 2 AM on a weekend? 🤣 Thanks! I completely agree. That's exactly when you realize whether you actually understood the code or just approved it because AI sounded confident.
😂 No one knows why....
Because bugs have a strict "weekends after midnight" work schedule. 😂
They wait until everyone's asleep. It's in their contract. 😅
That's when bugs feel safe enough to come out and socialize. 🤣🤣🤣
😂 it's a universal law of software. Nobody knows why
There is a recent study stating AI users are much more confident in their (borrowed) mistakes. It aligns well with your observation. thenextweb.com/news/ai-advice-supp...
The way I see it, the dynamics needs to flip. Juniors all use AI, but they produce slop. But AI is still exceptionally good at reviewing clean code and picking out small issues. So rather have Seniors generate the AI code, because they're experienced enough to correct it and produce cleaner code at a more rapid pace. Then have the juniors review it. That way they learn from GOOD code and learn how to spot the difference. AI does the 99% that's easy when it writes code, that 1% is where your experience trumps AI and if you're a junior, you dont have that 1%.
There's a version of this I'd really like to try: show juniors the AI output the senior threw away, not the one that shipped. The gap between those two drafts is where the experience actually lives, and it's completely invisible when you only ever see the polished result.
That's the flaw with Git. It's not built for the new era. We need to include AI context and developer flow. Know what was rejected, replaced, etc. So the AI and the juniors can learn from it. But seriously, the only way forward is to fully commit on training the next generation to be expert level code auditors, not programmers like we know them. I spent most of my career writing code manually, then I spent the past year and a bit learning how to orchestrate and I learned that knowing how to write code is useless. Auditing code is the real value driver today. So to train juniors, you dont teach them coding fundamentals, you train them on 'slop detection', their job will be to audit AI produced code. So teach them right from wrong, by showing them production 'ready' code from a senior and show them what doesnt meet the cut.
I mostly agree, but I'd be careful with "auditors, not programmers." You can't reliably audit code if you don't understand how to build it. Strong fundamentals are still what make good reviewers.
Yes, but what you store in your 'context' is what matters doing the job. If I turn your AI off, you dont have to be able to build a module yourself, from scratch. That's unnecessary, but if I show you bad code, you should be able to spot why. Agent orchestration is the millionaires skillset today.
I think we're closer in opinion than it sounds. AI changes how we build, but I still believe understanding how to build things is what lets you tell the difference between code that's merely working and code that's actually good.
True, but it's the difference between being able to spot a Ham + Cheese sandwich, vs knowing how to make a Ham + Cheese sandwich. If you goal is to build it, knowing how to make it is necessary, but if you're 'auditing' a sandwich, having seen enough of them to tell the difference is good enough, because the mistakes you'd make, is the same as someone who knows how to make it. Eg. surface level, you can spot an olive, but so can the guy whose just seen it. Under the surface, you cant see the slice of tomato, unless you open the sandwich up, at which point knowing how it's made makes no difference, because due diligence spotted something that isnt supposed to be there. The nuance is that your builders understanding is deeper than those who just experience it, but that understanding is useless if you dont have the time to do a proper job.
That's a fair analogy. I just think software is harder to audit than a sandwich. A lot of the important mistakes only become obvious if you understand why the code is structured the way it is, not just what it looks like. That is why I still see building as the foundation for good auditing.
Jumping in late here, but I think the sandwich version misses one thing. The
worst bugs are usually not something you can see in the code, they are
something that is missing from it. No error handling on that call, a retry
that fires twice under load, a lock nobody took. Pattern matching finds the
olive, but nobody notices an ingredient that was never added unless they
have made the thing before and been burned by leaving it out. That is the
part I think still needs building experience.
True, but the concept sticks, you sit with a ton of code, but to discover a bug, you need to take your time and pick through it, which matters more than knowing more. Time is a precious commodity which is also a team's most valuable resource
yeah I think that's exactly the key point. Finding what's missing is usually much harder than finding what's wrong, and that's where experience from actually building systems really pays off.
And regarding the worst 'bugs' like lack of error handling, etc. Is imo a tooling issue, not a user issue. Take Qoder for instance (my new fav IDE), has 3 tiers of security verification steps that are forced for the AI to adhere to. Alternatively, something like V.A.L.I.D. automatically implements Error handling, unit tests, MCP wiring, even UI fuzzy testing. If you use a hammer to chisel ice, you're half-way there, you need to have a chisel and a hammer to do it cleanly. That's AI vs AI + framework.
Fair, time is the real constraint. Though I would say experience is mostly what tells you where to look first, so it buys you time rather than competing with it. Good thread though, enjoyed this one.
True, but that juniors would also learn from running into support tickets, or learn straight from reviewing senior dev code, so the pattern of proper error handling is embedded in their brains from day 1. Code without error handling, isnt complete code. If it's not complete, you dont commit. Take my little hobby project, Dwarven Stronghold, 500+ modules of rust sofar, with over 2000 unit tests to make sure it doesnt break and full error handling to make sure if something breaks, I know where, without the entire game crashing. (it's essentially a modernized version of dwarf fortress)
But whose time is more valuable? If I tell you audit your work while your AI writes it, or I tell you audit this 2000+ LOC code written by someone else's AI, scenario is it's 2PM, you have 3 hours, what's the more productive use of your time as a senior dev, who runs at twice to three times the hourly rate of a junior?
@unitbuilds gitlab and github are exactly built for documenting this kind of information, unless you always squash-merge and delete all pull requests.
Interesting flip. The one thing I'd watch is that reviewing good code teaches you to recognize it, not to produce it, like you can spot clean and still have no idea how to get there from a mess. Might be worth pairing it: junior reviews the senior's version, then has to untangle something ugly themselves the next day. but yes good point! really good!
that's the whole point. Do you think in 5 years, when those juniors are seniors, that they'll ever actually write code? It's become the same as assembly, who still writes it? Only a very niche group of experts, everyone else just uses higher-level programming languages. We are training Juniors for the future, not the past. If a senior dev today does 90% of their work with AI, why do we expect that to change when the juniors graduate? It's an industry shift that you can either embrace and accept, or you can end up falling behind. Having 1 senior write 99% accurate code and juniors reviewing it, produces clean code at a higher production rate than if the juniors produce slop that the senior needs to audit and fix. We also work on the assumption that seniors have the time they used to have, to train the juniors on the code they corrected, reality is they dont, because they have to deal with much higher volumes of slop to run through. So you overwork your seniors reviewing slop, not training the juniors properly, or you can train the juniors better and let the seniors flex their skills? Imo, that's what the industry should do in order to progressively grow, rather than hit a sudden brainrot when those juniors need to take over...
Fair, and the point about senior time is the one I don't have a good answer to. Auditing slop all day is a real way to burn people out.
Where I'd push on the assembly comparison: compilers stopped needing supervision because they're deterministic. Same input, same output, and you can safely stop reading. AI isn't that yet, so somebody in the room still has to be able to tell when it's confidently wrong. My only worry is that this particular sense seems to come from having built the thing yourself at some point. If there's another way to grow it, your model works and I'd be happy to be wrong.
I've built everything from production ERP systems to frameworks, written programming languages, model harnesses, security gating systems, MCPs, even an entire agentic IDE and OS. What I've learned, is that how you use the tools at your disposal is the difference between good and bad use of time. Eg. V.A.L.I.D. I wrote a deterministic framework to replace CSLA, using Roslyn, F# and C#, everything breakable is handled entirely by Roslyn, all you need to do, is fill in the UI markup (so it looks how you want it to) and the backend DTOs marked with ValidObject and the restraints (so the values you want are actually used). Everything else is generated by Roslyn, an 82% written code reduction, validated on a 500k LOC autonomous accounting suite. That's what a senior developer who lived through the era of writing automations from scratch produces with AI. Whereas someone who didnt, would just use AI as a blanket speed booster. Except that speed comes at API price... Building tools that generate clean, perfect code, that's what AI is good for, but it takes a senior dev to spot the difference between it runs right and it actually works right. That's something far out of scope for junior. That's why smart use of AI is sink or swim. Are you willing to invest in infrastructure that saves you time and tokens? Cuz with the skills file, I can confidently trust an AI to write up a DTO, set constraints and write the basic markup. Because all the stuff that could break is generated. So if you can trust yourself to write a framework, you can trust that framework in production and if you can trust it in production, it's as good as basic vs assembly, trust the framework and you can trust the output consistently.
Makes sense, and putting the breakable parts behind something deterministic is the right instinct. I think we mostly agree anyway, you still need someone who can spot the difference between code that runs and code that's actually correct, and that's the person I keep wondering about. Good chat,thanks for digging into it!
Anytime, but that's exactly why the senior should use AI at their pace and be the first line of filtering and the juniors and their AI the 2nd level.
Yeah, layering it that way at least keeps juniors reading good code every day, which is more than most teams manage right now.Thanks for the back and forth, this was a good one.
I think you're probably right, although the situation is more nuanced than it first appears.
A few points are worth highlighting:
In the end, there isn't a single villain here. Everyone contributes to the problem in different ways: companies chasing short-term productivity, developers looking for shortcuts instead of fundamentals, and organizations unwilling to invest in training and long-term growth.
Agreed on there being no single villain. The retention part is the one I would underline, since a company that trains someone and then loses them the month they get good has a rational reason not to train anyone. That one is fixed with pay, not with good intentions.
That's the incentive trap.
Companies don't want to invest because people leave. People leave because companies often don't invest enough in either compensation or career progression.
AI may amplify the problem, but it didn't create it. The economic incentives have been pushing in this direction for years.
Fair, and the loop is older than the tools. What changed is that companies used to need juniors for throughput, so they hired despite the churn. That reason is gone now, so nothing pushes back on the trap anymore.
That's probably the key point. The cycle itself is not new — we've seen similar situations before, just under different forms.
When the pressure is high, companies recognize the importance of investing in people, knowledge transfer, and building future talent. But once the pressure fades, short-term optimization usually takes over again.
The difference today is that companies used to need juniors for additional throughput, so they accepted the cost of training despite the risk of losing them later. With AI reducing that immediate need, the economic incentive to maintain the pipeline becomes much weaker.
The risk is that we optimize away the entry point without realizing that juniors are not just cheaper resources — they are the future pool of experienced developers, architects, and technical leaders.
Agreed, and what makes it hard to see is that the current seniors are still holding the line. Nothing looks broken while they are around, so the shortage stays invisible right up until they retire or move on. Good thread, thanks for thinking it through.
Exactly. That's probably why the problem is so easy to underestimate.
Senior developers are not just producing code — they are carrying years of accumulated context, judgment, and knowledge that is often invisible until it's gone. As long as they are there, the system appears to work.
The danger is that we may be creating a kind of knowledge debt: saving costs today while reducing the ability to build the next generation of experienced engineers tomorrow.
Thanks for the thoughtful discussion as well. It is a complex issue, and I think the industry will need more conversations like this rather than simple "AI will replace developers" or "AI changes nothing" narratives.
Agreed, and thanks for taking it seriously!
It is a tricky subject, and this is my gut feeling about it. If we still want old-school seniors, then the apprenticeship will have to become part of the education. It will soon be the only place that can still offer an AI-free environment, which is what you need if you want to learn the trade by hand. However, I am not convinced that we still need old-school seniors. I am also not convinced that human review of AI-generated code is the way forward. Coding will soon be the exclusive domain of AI. What the new-school juniors should focus on is the engineering part. We have to become a lot better at specifying systems. Only then will AI be able to automatically create a working implementation and meaningful tests. QA will be about system behavior, not code structure.
Old-school seniors are bound to become the new COBOL programmers who are not allowed to retire due to legacy systems that did not transition into the AI era.
The specification path has one wrinkle I keep running into. A spec precise enough for a machine to implement correctly is code just with different syntax and we took that trip before with UML and the fourth generation languages.Ambiguity is where the actual work lives. And I am not sure you can tell whether a spec is tight enough without having been burned by a loose one first which is the same training problem wearing a different hat
Few clients, product owners, and tech leads know exactly what they want and hardly anyone who knows is able to translate their wishes and visions into unambiguous requirement specifications. As a senior, part of my work starts there already, adding experience, legal requirements, gut feeling, and taste (as a frontend-focused web developer).
Maybe specification is already so close to coding that we will need a completely different apporach to AI than the current LLM-based tools if we truly want secure and stable vibe coding without a human in the loop.
P.S. I'm sorry to say but every time I come back to DEV.to I keep seeing the same pro-LLM-AI propaganda, either 99% of everyone here are bots (Dead Internet agents), paid marketers, or junior developers or what did I miss?
the paradigm will shift. developers will no longer be primarily coders — they'll become architects of product vision, system design, and quality assurance, with AI agents as their primary implementation tool
I agree with the overall premise, but I'd add one thing for junior devs! Don't rely on applications alone. The market is noisy, and networking has become a force multiplier. Join local meetups, contribute to open source, write about what you're learning, help people in communities, and build genuine relationships. Most opportunities I've seen happen because someone trusted the person behind the GitHub profile, not just the code.
AI can generate code, but it can't build your reputation. Keep using AI as a learning tool, but focus on developing judgment, debugging skills, communication, and a network of people who know your work. Those are the things that will compound over your career.
One thing I'd add for juniors: don't optimize for looking experienced, optimize for becoming useful. AI can help you produce code faster, but if you consistently solve real problems, ask good questions, and follow work through to completion, people will remember that. In a market full of polished demos, reliability and curiosity become strong signals.
"Becoming useful" is a good way to frame it. Starting things got cheap, so finishing them is where the signal moved, the last 20% is what people actually remember you for.
Agree!
Good addition, and I think networking works for a reason that's tied to the
same problem: when anyone can ship a clean-looking repo, the rare signal
isn't the code anymore, it's someone having watched you reason through
something messy. A meetup or an open source thread gives people that view.
An application form never does.
Exactly. A GitHub repo shows what you built. A conversation or an open source discussion shows how you think. That's the difference. and AI can help write code, but it can't build credibility. That's something you earn by working with people and being part of the community.
Yeah, credibility is the slow part, and there's no shortcut for it. Curious what you'd actually do if you were starting today? meetups, open source, writing? I'd guess the answer looks pretty different than it did five years ago.
Honestly, I'd spend less time chasing portfolio projects and more time joining communities. Open source, Discords, meetups, hackathons. so anywhere people can actually see how you think and collaborate.
and I'd treat networking as a skill, not an afterthought. Not collecting LinkedIn connections, but building real relationships while learning in public. Technical skills get you noticed.
Makes sense. Learning in public is kind of the mentorship loop rebuilt from outside the company, if nobody's reviewing your thinking at work, you go find people who will.
I agree. Personal skills are actually very important
Great article. I think the biggest challenge is not AI itself, but how we use it. AI should help juniors think faster, not think less. The teams that teach debugging, code reviews, and problem solving alongside AI will build the strongest engineers. Thanks for starting this conversation.
Thanks. The tricky part is that thinking less is the default direction, since it is the path with no friction on it. So it takes an actual push the other way rather than a line in an onboarding doc, which is where most teams stop.
That is a great point. In your experience, what is one practical habit or team practice that actually creates that healthy friction? Have you seen any company get this right without slowing developers down too much?
The cheapest one I know is keeping a few investigation heavy bugs off the automation pile on purpose and handing them to whoever needs the reps. It does not slow the team down, since those tickets were never on the critical path anyway, and they are exactly the ones that force someone to go read the system. The mistake is treating every ticket as pure cost, when a handful of them were quietly doing the training.
I really like that approach. Those investigation heavy bugs are probably where people build the mental model of the system and that is hard to get from AI or simple feature work. Treating a few tickets as learning opportunities instead of pure delivery work seems like a smart long term investment.
Yeah, and it is close to free. Those tickets were never the urgent ones anyway.
I really like that perspective. If you had to pick just one change, what would it be? Better code reviews, limiting AI for some tasks, or something else? I'm curious what has worked in practice.
hmm... that's interesting.... If I had to pick one, I would change what review asks for. Instead of approving a diff, the author walks someone through the change and explains why it is correct. It costs about ten minutes, it does not slow delivery down, and it surfaces the gap straight away, because you cannot explain code you do not understand and everyone in the room can hear it.
I really like that idea. Explaining the reasoning instead of just submitting a diff seems like a much better way to check understanding, and it probably spreads knowledge across the team too. Do you think this approach still works in fully remote teams, or does it depend on having regular face to face discussions?
Remote is fine and writing it down is arguably better since it leaves a record. The part that has to hold is someone actually replying and a walkthrough nobody answers turns into a ritual pretty fast.
That makes a lot of sense. The discussion is what creates the learning, not just the documentation.
now everyone uses AI tools. It's time for a change. we need to rebuild the development process, focus on other angles and paradigms, and increase personal responsibility for the results you achieve through the use of AI agents. using the agent correctly is now a must. Before, people dug the earth with a shovel; then excavators appeared, and the skill of working with them became mandatory. An AI agent is a tool, and you need to know how to work with it
We have to remember — business is the one paying the money. Coders will disappear, replaced by AI agents. Instead, we'll need people who can successfully embed agents into business operations and keep the systems healthy.
The excavator comparison is a good one, and the place it strains is feedback. An operator can see the hole and knows straight away when it is in the wrong spot. Agent output looks equally convincing whether it is right or wrong so nothing tells you that you used the tool badly until much later.That delay is what makes it harder to learn than a machine you can watch.
One thing I keep wondering is whether AI is actually changing where the apprenticeship happens rather than removing it.
Five years ago you learned mostly by writing code. Now I'm finding I learn just as much by building complete products end-to-end: wiring APIs together, dealing with authentication, pricing, rate limits, deployment, monitoring, and all the little problems AI doesn't solve for you.
AI definitely removed a lot of the "write this CRUD endpoint" practice, but it also created a new layer of engineering work around integrating and operating AI systems.
Maybe the apprenticeship isn't disappearing—it just looks different.
I think you are right that it moved rather than vanished and wiring real systems together is proper engineering work. The gap I would flag is that this version is mostly unsupervised.Building end to end on your own teaches you what works but not what you got away with and nobody is reviewing the difference. Someone else in this thread described finding that out months later in production rather than in a code review which is the same lesson at a much worse price.
AI didn’t kill the apprenticeship, it just swapped the training wheels for rollerblades. Instead of endless CRUD drills, juniors now learn by wiring APIs, juggling auth, and keeping systems alive under rate limits. It’s faster exposure to real engineering, but without mentors reviewing shortcuts, you only find out what you ‘got away with’ when production catches fire.😃
Faster and you fall harder, that sounds about right. The part worth putting back is not the slow pace, it is having someone check the work before production does it for you.
The argument I find hardest to counter is that juniors used to learn by doing the exact work that now gets autocompleted, so the on-ramp disappeared while the expectation of seniority stayed the same. Reviewing AI output well takes the judgment you used to build by writing that code yourself. Do you think review of agent output can become the new training ground, or does it need too much prior context to work?
I think it can, but not on its own. Reading correct code mostly teaches you
to recognize correct code, which is a weaker version of the skill. It
probably works if the review is active, so the junior has to explain why
something is right, or go break it and see what falls over, instead of just
approving it. That part is what writing the code used to force on you for
free.
AI speeds up seniors, but it shouldn't sideline juniors. The fix is structured learning: paired programming, clear onboarding, strong mentorship, and a junior-to-mid track that uses AI as a tool, not a crutch. Make every sprint plant a learning goal, and the pipeline can actually flow again.
Agreed on most of that, and planting a learning goal each sprint is the one I would actually try first. The hard part is mentorship, since it is the only item on that list that costs senior time, and senior time is exactly what is short right now. Everything else on the list is cheap by comparison.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.