This summer I built a skill called Bert. Basically everyone I know built one of these: a set of instructions that turns a description into a tested, reviewed pull request. What makes Bert work is that the instructions are my own workflow for a change, stitched together: the ask, the scoping, the plan, the task list, the debugging, the testing and evaluation, the review, the build. Everything I do to a change, Bert does without me. The README calls it "your senior engineer in the terminal." One line in there says Bert "decides the boring stuff."
I was pretty pleased with that line when I wrote it. I'm less pleased with it now.
Because at some point, watching Bert close out another small ticket, I realized that almost everything it handled was work I would once have given to the newest person on the team. The CSV export. The date formatting bug. The migration nobody wanted to touch. And every one of those tickets used to teach somebody something.
Which got me thinking (usually a dangerous thing). If the boring stuff goes to the machine, where exactly do the next senior engineers come from?
What the tickets taught
I've been building for the web for about twenty years. Most of what I know about the browser, I learned by being wrong about it, repeatedly, usually against a deadline. Nobody sat me down and explained how IE6 handled floats. I found out one broken layout at a time.
That was the deal for most of this profession's history, even if nobody said it out loud: junior developers were paid to be slow. You got the tickets nobody else wanted, like the CSS bug on the settings page or the migration that kept sliding to next sprint. You took three days on something a senior would have finished before lunch, and in those three days you learned how the build worked, where the strange corners of the codebase were, and how to read a stack trace without your pulse going up.
None of the specifics mattered for their own sake. I've long since forgotten the random file formats and boilerplate minutiae of whatever project I was on, and remembering them wouldn't help, because it all changes every few years anyway. What mattered was having to figure things out: breaking something I didn't understand into parts small enough to test, isolating the one variable, triangulating between the docs, the error, and the code, and when something that should have worked on paper failed anyway, forcing a creative workaround that got the site building again. I can still picture the evenings spent on a connection that refused to cooperate, or a config file that ignored its documented properties. They were frustrating. They were also the training.
The boring tickets were the curriculum. We just never wrote it down.
Before I wrote software for a living I studied classical composition, and music worked this out a few centuries ago. Nobody learns counterpoint by listening to Bach. You learn it by writing hundreds of bad exercises and having a teacher circle your parallel fifths in red. The exercises aren't the point. The ear they build is.
Software never needed to formalize any of that, because the learning came free with the work. Nobody budgeted for it or measured it, and nobody noticed it was gone until the work stopped coming.
In hindsight, those evenings were the most valuable hours of my first years in this job. They taught me the codebase, and something harder to teach: resilience, the habit of keeping going when the thing is broken and the documentation is wrong, which turns out to be most of real engineering. The same nights built an intuition for what a hard problem looks like before it's solved, and convinced me that this is a creative job, which would have sounded absurd to me at twenty-two. There's no right answer waiting in the reference. There's a constant back-and-forth between trade-offs and the realities of what actually works on your machine, and the people who are good at it hold all of that in their head and keep moving anyway. That's why I love it, and it came to me free, as a side effect of the work nobody else wanted.
So how do young engineers build that intuition now? I built mine by fighting for it. When the frustration is managed for them and the problems that need creativity get solved with the most average answer in the training data, what's left to teach them how to think?
Where the work went
It went to tools like Bert. The boring tickets are exactly what AI is good at: well scoped, low risk, and shaped like a million examples it has already seen. I can describe one in a sentence and get back a reviewed, tested diff while I'm doing something else. That's a real productivity gain, and I'm not going to pretend otherwise.
When I ran a data science team at Azure, the rule I tried to hold myself to was that mentoring had to produce real work. Pair on actual production problems, and let PR review carry the rest. I still think it's the right rule. But it assumed there would always be production problems small enough to hand someone new, and that assumption is getting shakier by the month.
Multiply that across the industry and it starts to show up in payroll data. When Stanford's Digital Economy Lab first published its study of ADP payroll records in 2025, employment for software developers aged 22 to 25 had fallen nearly 20 percent from its late-2022 peak, while older developers in the same roles held steady or grew.
The August 2026 update widens the lens to every AI-exposed occupation and finds young workers about 19 percent below where they would be had they kept pace with peers in less exposed jobs. Experienced workers show no comparable gap. Most of the decline comes from reduced hiring rather than layoffs. The door mostly just stopped opening.
But hiring is the visible part of the story. Underneath it, a second conversation has been running, and it's broader than software. The question "is AI making us dumber?" has moved out of opinion pieces into controlled studies. The one that keeps coming back to me is from early 2025: researchers at Microsoft Research and Carnegie Mellon surveyed 319 knowledge workers and drew on 936 first-hand accounts of using AI on the job. The pattern was consistent: the more trust people had in the model, the less effort they reported putting into the thinking around it, checking the output, catching what looked right but wasn't, deciding what to do when the answer came back wrong. Confidence in the machine and critical thinking moved in opposite directions, while confidence in your own judgment went the other way. The study measures self-reported effort, not measured ability, and it can't tell anyone whether they got dumber. But as a description of how knowledge work is actually practiced right now, it's hard to read it as good news.
The software-specific version of that conversation is where the productivity numbers live, and they're real. GitHub's controlled experiment had developers implement an HTTP server with and without Copilot; the tool group finished 55.8 percent faster, and the authors read the result as a promise for people trying to break into the field. I don't doubt any of it. I would only point out what the benchmark measured: a well-understood task, judged on speed. There is no benchmark for the other half of the job, because it has no ticket and no acceptance criteria. It's the half that takes years.
Software is hard to build in the way a sonnet is hard to write, and that fact never survives being summarized: the difficulty lives in the choices, not the syntax. Every real system is thousands of small creative decisions strung together: how this service talks to that one, where a piece of state is allowed to live, whether the problem in front of you is the one the pattern in the book was named for, or only looks like it. Generations of engineers fought that accumulated judgment into a shared inventory: an entire Wikipedia list of architecture styles and patterns, each entry a war story. None of it is learnable by being told. You only get the feel by choosing, and by choosing wrong often enough that the right shape starts to feel like the obvious one.
So when the people entering the profession have never had to care which pattern fits, because the model picked one and it was fine, what happens to the applications? The quality of a real system is the compound interest of ten thousand of those choices. And what happens to the intuition itself, the thing that tells you, before you can explain why, that a design is going to come back and haunt you? I don't know what it gets replaced with. I'd like to believe the answer is nothing. I can't quite get there.
The answer before the confusion
For the young developers who do get in, the struggle is now optional: the answer shows up before you've finished being confused.
In January, researchers at Anthropic tested what that does to learning. 52 working programmers, most with several years of experience, learned an unfamiliar Python library, half with an AI assistant and half without. The AI group finished about two minutes faster, not enough to be statistically meaningful. On a quiz afterward they scored 50 percent against the other group's 67, and the widest gap was on debugging, which is the skill you need most when the generated code is wrong. That's one hour, with people who mostly had years of experience. I don't want to guess what a year of it does to someone in their first job.
The more interesting part is how the scores broke down by the way people used the tool. The few participants who handed the whole task over scored below 40 percent. The handful who only asked it conceptual questions, and fixed their own errors, scored well and were nearly as fast as anyone. The groups were small and the authors are careful not to claim cause and effect, but it's hard not to notice who did well: the people who used the assistant to explain, not to write.
None of this would have surprised Lisanne Bainbridge. In 1983 the cognitive psychologist published a short paper called "Ironies of Automation." Her argument was that automating most of a job leaves the human with only the hardest part, the rare moment when the automation fails, while removing the daily practice that would have prepared them for it. Aviation has lived with this for decades. Pilots who lean on the autopilot mostly keep their hands. What fades is the picture: where the aircraft is, what it's doing, and what's about to go wrong.
She saw the next part coming, too. The automated systems of her day, she wrote, were monitored by former manual operators who were "riding on their skills, which later generations of operators cannot be expected to have." That later generation is starting work now.
I've made this argument before
Here's the part that stings a bit. I've spent the last couple of years making this exact argument about novelists.
When I built Story Stream, the one rule I wouldn't bend was that the agents don't write the book. They read it, carefully, and help the writer see what's actually on the page. A writer who lets a model draft their chapters ends up with a finished manuscript and no better at writing the next one. I believed that about fiction long before I noticed it was true of my own profession.
Bert, it turns out, writes the chapters.
If I were twenty-two
So I want to be careful about who I'm blaming here, because it isn't the young developers.
If I were twenty-two right now, I would use the tools too. The market is brutal and your manager probably counts tickets closed. You can't tell someone to take the slow road when the slow road is how they lose the job. Reaching for the assistant is a correct reading of the incentives we built. The people who set those incentives are people like me.
Some obvious objections
Switching sides, for a moment.
Isn't this just a hiring freeze? Partly. Zero-interest-rate hiring ended in 2022, a tax change that same year made engineering salaries more expensive to write off, and junior hiring froze in 2001 and 2009 too, then came back. The Stanford researchers controlled for interest-rate exposure and reran the numbers with tech companies excluded. The gap held. It kept widening long after rates peaked. The losses also show up where AI is used to automate work, and not where it's used to help people do it. The picture isn't settled, and Yale's Budget Lab finds no broad disruption across the labor market yet. But in 2001 and 2009 the budget left and the work stayed, waiting for the juniors to come back. This time the work itself went somewhere else.
Aren't you just nostalgic? Some, yes. My generation copied plenty of code we didn't understand, and our seniors worried about us too. Before Stack Overflow it was frameworks, and before frameworks it was compilers, and senior engineers kept appearing anyway. What's different is where the friction lived. The answer you copied from Stack Overflow almost never fit your problem. It was written for someone else's schema and someone else's version, and you had to bend it until it worked. The bending was where you learned. jQuery hid the browser's quirks, but you still had to decide what the page did when a request failed. The model does the bending for you. What it hands back usually fits well enough that you never have to understand why, and when it doesn't, the natural move is to prompt again rather than read. I can't fully separate the real difference from my nostalgia, and I suspect none of us can while we're living through it.
Can't juniors learn faster with AI? Honestly, yes. That's what the conceptual-questions group in the Anthropic study suggests, and I'd have killed for a patient tutor at 2 a.m. with a broken layout. The tool will teach you if you ask it to. It will also do the thinking for you if you let it, and right now every incentive says let it.
Why train people who'll leave in eighteen months? Some will. Plenty of us did. Somebody paid for our first two years anyway.
Writing the curriculum down
So what do we do? Banning the tools won't work, and neither will telling people to try harder. If the boring tickets were an unwritten curriculum, the job now is to write it down on purpose. Bainbridge has a warning for that, too: this kind of knowledge only develops through use and feedback, so the curriculum can't be a wiki page. It has to be real work, with someone paying attention. That falls mostly on those of us with enough seniority to shape how teams work.
- Hire juniors. Charity Majors put it plainly: "By not hiring and training up junior engineers, we are cannibalizing our own future."
- Keep some tickets human. Pick a few each sprint that would teach something, give them to a person instead of an agent, and budget the three days.
- Ask before you answer. When someone is stuck, or when you're reviewing their change, have them walk you through what they think is happening, especially in the parts the model wrote.
- Measure growth, not just throughput. If tickets closed is the only number that matters, every sensible junior will outsource their learning, and they'll be right to.
And if you're early in your career, the advice is short: ask the model to explain, not to write. Use it the way the people who scored well in that study did.
So, about Bert
No, I'm not deleting it. It's too useful, and pretending otherwise would be exactly the kind of nostalgia I just admitted to.
I got good at this job because someone decided my slowness was worth paying for. I didn't earn that. It was the default, and the cost was absorbed by teams that never knew they were running a school. That default is gone now, and it won't come back on its own.
So I think that README owes the world an edit. Bert shouldn't decide all of the boring stuff. Some of it belongs to whoever is new.