The tech industry runs on three reactions to AI: panic, denial, and hype. Sometimes all three in the same Hacker News thread. The more interesting conversation is happening underneath all of that, but it’s quieter.

AI is changing software engineering careers. Not uniformly, not on a predictable schedule, but it’s happening. How much it affects you depends on where you are in your career and what you’re willing to change. Boring answer. Also the honest one.

Haven’t we seen this before?

The anxiety feels new if you’ve only been watching tech. Zoom out and it’s almost boring how familiar the pattern is.

Textile workers watched machines take over skilled labor. Switchboard operators lost their jobs to automated exchanges. Rooms full of human “computers” did math by hand until electronic computers showed up. Cloud computing quietly gutted the sysadmin profession over about fifteen years.

Real jobs disappeared each time. The people who came out okay weren’t pretending nothing was happening, and they weren’t quitting either. They saw where things were going and learned what the machines couldn’t do.

Same story now, except it’s faster. Those shifts took decades. AI capabilities improve every few months.

What can AI actually do right now?

After using AI coding tools every day since they first shipped, here’s where I’ve landed: it’s a fast junior developer.

Scaffolding, boilerplate, writing tests for existing code, refactoring when you give it clear instructions. These are real. They’re also the exact tasks you’d give a new hire.

The limitations show up once you push past that. It loses track of things in big codebases. It writes code that compiles, looks reasonable, and is wrong in ways you won’t catch unless you’re paying attention. It makes architectural decisions based on what’s in front of it and ignores everything else. It can’t tell you when the requirements don’t make sense.

So it needs a manager. Someone setting direction, reviewing output, catching mistakes early. If that sounds like every promising junior you’ve worked with — yeah, it pretty much is. Minus the coffee habit and the small talk.

Why should entry-level developers be worried?

I’d rather not write this part.

Companies hire juniors to do junior work. Lower salary, well-defined tasks, invest in their growth, hope they stick around and take on harder problems later.

AI now does a chunk of that work. A senior developer with good AI tooling can cover what used to take two or three juniors. Hiring managers see the math. Some of them are already doing the math.

Software engineering always worked like an apprenticeship. Junior to mid to senior, each level built on experience at the one below. That ladder is getting narrower. Not gone — there are still things juniors do that AI can’t — but the competition for those entry-level spots is going to get worse.

Same economic logic as every other technology shift. Work that’s easy to systematize is the first to go.

How do experienced developers benefit?

The stuff that matters most now is the stuff AI is worst at.

Architectural trade-offs. Figuring out what to build before anyone writes code. Translating technical problems for non-technical people. Debugging across systems using instincts you only develop by spending years getting things wrong.

For senior devs, AI is a genuine multiplier. I’ve watched features go from whiteboard sketch to working code in an afternoon. The people getting the most out of it aren’t prompt engineering wizards. They’re strong engineers who happen to know how to aim the tool.

For managers, it’s a different game. Structuring work for rapid iteration, evaluating output quality when the volume spikes, knowing when to trust the tool and when not to. If you’ve spent years learning how to get good work out of junior developers, you’ve been training for this without knowing it.

What does managing AI look like in practice?

Most people describe their AI workflow as “ask a question, paste the answer.” That’s like hiring someone and never looking at their work.

The thing that makes the biggest difference is controlling what the AI knows about. It makes way fewer mistakes when you scope the context well — relevant files, your conventions, the constraints that matter. Dumping an entire repo on it works about as well as handing a new hire a hard drive and walking away.

Second opinions help too. Run output through a different model or a different approach. Same reason you do code review, different kind of reviewer.

Building repeatable workflows matters if you’re doing this regularly. Custom instructions, structured prompts, loops that match how you actually build things. Setup cost, but it pays off over weeks.

And you need to be able to review fast. More output means more to evaluate. Testing and the ability to read code critically at speed get more important as volume goes up.

What should you do?

If you’re experienced: start spending real time on this. Not “I’ll get to it eventually.” The learning curve is real, and people who figure it out now are going to be ahead of those who don’t.

If you’re early-career: focus on what the tools can’t do. System design, debugging instinct, talking to humans about technical problems, understanding business domains that don’t fit neatly into a prompt. The bar to get hired is going up.

For everyone: the debate about whether AI matters is over. The only useful question is what you’re going to do about it.

Technology doesn’t wait for you to have an opinion. The people who get through this are going to be the ones who figured out where the line is between what the tools handle and what still needs a person, and kept paying attention as that line moved.