The Profession That Eats Its Young

Written by:
Ken Baum

April 27, 2026

blog

This series, Engineer Formation in the Age of AI, explores what it means to become, and remain, a software engineer when AI tools are rapidly reshaping the profession. We examine the cultural forces pressing against deep formation, make the case that technical judgment, professional identity, and personal responsibility are more essential now than ever, and offer a practical framework for how engineers can intentionally develop these qualities. The series moves from diagnosis to conviction to action, with the goal of equipping engineers not just to survive an AI-accelerated world, but to lead in it with integrity and craft.

Go ahead and search for entry-level software developer jobs. I’ll wait.

Notice anything? A lot of those “entry-level” postings want two, three, sometimes four or more years of experience. Entry level. It would be funny if it weren’t so discouraging for the people trying to break in.

And if you’re one of the lucky ones who actually gets through? Congratulations. You’ve earned a spot on a team that fully intended to invest in you. They also just had a release this week. And a production issue last week. And somehow “let’s get the new person up to speed” keeps landing at the bottom of the list.

You fought your way in the door. Nobody told you the door was the easy part.

That’s not bad luck. It’s the culture.

I Feel the Need…the Need for Speed

Software engineering, and business in general, has built a culture around speed, and it really does makes sense. The economic pressures are real: competitive markets, short release cycles, Agile methodologies built to maximize throughput. We measure what we can see: pull requests merged, tickets closed, features shipped. Output is visible. Progress is trackable. It feels good to move fast.

What’s harder to see, and easier to skip, is whether the person generating all that output is actually growing. And this will be harder and harder as AI is integrated into the development process.

Many times the new developer learns just enough to close the next ticket. They develop habits through trial and error, with no one around to help sort the good ones from the bad. They accumulate experience without accumulating wisdom, because wisdom requires reflection, and reflection is a lot more effective when you have someone to reflect with.

A lot of teams run on exactly this arrangement. It works fine in the short term. In the long run it’s a recipe for disaster.

What Formation Actually Is

Formation isn’t training. Training is the transfer of information and skills: here’s the framework, here’s how to write a test, here’s how to submit a PR. Formation is something slower and more personal: the development of technical judgment, professional identity, and a genuine sense of responsibility for the quality of your own work.

A trained engineer knows how to do the thing. A formed engineer knows why it matters and when to use it. You can spot the difference pretty quickly. Give a bootcamp grad a problem and one of the first things out of their mouth is “where do I start?” Not because they lack ability, but because nobody ever taught them how to think through a problem before they started solving it.

That distinction matters more than it might seem, because output and formation can actually work against each other. A culture that prizes velocity above everything else will consistently underinvest in formation, because formation takes time that doesn’t show up in any sprint metric. It happens in code reviews that go beyond style nits. In postmortems where someone asks “what should we have known?” In moments where a senior engineer says “let me show you how I think about this” instead of just fixing the problem themselves.

None of that is free. It requires time and attention. And in a velocity culture, time and attention are always already spoken for.

The Debt We Inherited, and Are Failing to Pass On

Every senior engineer was formed by someone. Maybe it was a patient tech lead who explained not just whatto do but why. Maybe it was a team that actually cared about craftsmanship. Maybe it was a mentor who saw something worth developing and decided to invest in it.

That formation was a gift. It was also a debt, the kind you don’t repay to the person who gave it, but forward, to the next generation coming up behind you.

What happens when that debt stops being paid?

The erosion is quiet at first. Junior engineers who were never formed become mid-level engineers who don’t fully trust their own judgment. Mid-level engineers without that foundation become senior engineers who don’t know how to build it into others. And the craft knowledge that makes engineering engineering, not just the syntax and the frameworks, but the hard-won instincts about tradeoffs, about risk, about what it means to build something that lasts, starts to disappear. Not all at once. Gradually. And then, at some point, it’s gone.

This isn’t nostalgia for some golden age that probably wasn’t as golden as we remember. It’s a practical observation about how professions sustain themselves. A profession that stops forming its successors eventually erodes its own foundation. The output continues for a while. But the judgment underneath it thins out and will result in brittle structures and questionable output.

The Accelerant

This isn’t a new problem. But it’s becoming a more urgent one.

AI tools are raising the pressure to ship. The promise, and it’s a reasonable one, is that engineers can produce more, faster. So the demand for output increases. The sprints get denser. The backlog grows faster than it can be cleared. And the message that we hired you to produce gets louder and harder to push back on.

Formation, already undervalued, is now swimming against a stronger current.

Where that leads isn’t entirely clear yet. But the early signs aren’t great. When the pressure to produce is at its highest, investment in formation is the first thing to get deferred. And deferral, repeated long enough, becomes something closer to abandonment.

A Profession Worth Defending

This series isn’t ultimately about what’s wrong. It’s about what’s worth defending, and what it would cost us to actually take that seriously.

The argument, stated plainly: technical judgment, professional identity, and personal responsibility aren’t soft extras we bolt on when things slow down. They’re the foundation of engineering skill. They’re what makes output trustworthy, sustainable, and worth producing. And they don’t develop on their own. They require intentional formation.

The question this series keeps asking is a simple one, even if the answer isn’t: in an AI-accelerated world, who is responsible for that formation?

The rest of the series works toward an answer. But the first step is seeing the problem clearly. And the problem is this: we’ve built a profession that celebrates what its people produce while quietly neglecting what they become.

That’s a profession eating its young. And it can’t sustain itself on that diet forever.

Next: What does it actually mean to be a professional? And why does that word carry more weight than most engineers realize?