AI Didn't Kill the Junior Developer—Taste Did

Last month, I was reviewing applications for a mid-level backend position at my company, and I noticed something that made me pause. Three candidates had nearly identical CVs: competent portfolios, solid technical chops, but nothing that suggested they'd ever questioned a decision or pushed back on a requirement. Then one applicant's cover letter mentioned they'd forked an open-source library to add a feature that bothered them, not because their job required it, but because they couldn't stop thinking about it. They didn't mention AI once. That's when I realized what's actually changing in tech hiring isn't about automation—it's about what separates someone who can code from someone who thinks.

I've been following the discourse about AI replacing junior developers with a mixture of skepticism and recognition. Part of that skepticism comes from watching it happen in real-time at places like Coder, where AI adoption is mainstream but layoffs aren't being blamed on it. The real story is messier and more interesting than "AI kills entry-level jobs."

The Skills That Actually Matter Now

Here's what I've learned from talking to hiring managers across Islamabad's growing tech scene: the bottleneck was never "can someone write code." It was always "can someone write code that matters?" AI made the first part trivially easy. Now everyone can generate CRUD applications, write boilerplate, scaffold a basic API. But that's exactly the problem. If building is cheap, the expensive skill becomes judgment.

When I evaluate candidates now, I'm not asking if they can code. I'm asking: have they ever looked at something they built and genuinely disliked it? Have they iterated on their own work? Do they have opinions about the tools they use, and have they actually tried to implement those opinions?

A junior developer who can generate 500 lines of code using Claude is less impressive than a junior developer who generated 50 lines, understood why they worked, and could explain why they rejected three other approaches.

The Tinkerer Advantage

The hiring manager from Coder mentions they explicitly hire tinkerers—people who poke at problems because they can't not poke at them. I've started looking for the same thing. In my experience, the difference between someone who will grow into a senior role and someone who'll plateau is often whether they tinker.

Tinkering is the opposite of AI-generated work. It's messy, intentional, and driven by genuine curiosity. You tinker because something bothers you, not because you got tasked to improve it. That matters because it's exactly the kind of person who actually ships things that stick around rather than code that "gets 90% of the way there and then gets scrapped."

The uncomfortable truth is that if your job description could be fully automated by a large language model, you probably weren't building anything particularly differentiated anyway.

My Take: Where This Gets Uncomfortable

I agree with most of what the Coder team observes, but I'd push back on one thing: not every company can operate on tinkering and undefined expectations. That's a growth-stage, well-funded privilege. Most of the companies I see in Islamabad have clearly defined problems, limited resources, and need people who execute tasks, not explore tangentially related ideas.

But here's what I do think applies everywhere: even in task-execution environments, the people who get promoted are those who occasionally step outside their lane. And the barrier to doing that just got lower. A backend developer can now mock up a quick UI to test an idea. A DevOps person can write a quick monitoring dashboard without being a frontend specialist.

The question that keeps me up at night is whether we're inadvertently raising the bar for entry-level positions. If we hire juniors expecting them to tinker and self-direct, we might be screening out people who are disciplined and organized but haven't had the privilege to explore freely. That's worth being honest about.

What I'm Actually Watching For

When I interview someone now, here's what signals to me they'll thrive in an AI-native environment:

They've used AI to solve something, then asked "but why did that work?" They can articulate what they learned. They've shipped something that required real judgment calls—not just code generation, but deciding what to build in the first place. They can receive feedback on AI-assisted work without defensiveness. They ask good questions about context and constraints.

The Real Question

I don't think AI is replacing junior developers. I think it's replacing mediocre output, which means the bar for entry just got higher. That's genuinely unfair to people without resources to tinker freely. But it's also an opportunity: if you can demonstrate that you think, ship, and refine, you're more valuable than you've ever been.

What's your experience been? If you're job hunting, are you seeing companies actually value tinkering, or are they just listing it as a nice-to-have while screening for resume keywords?

Source: This post was inspired by "A Hiring Manager's Perspective on Tinkering & AI" by Dev.to. Read the original article