When AI writes the code, what's left for engineers?

Why judgment, prevention, and curation became the skills that matter

You are on a path to senior position and you want to deliver the perfect code: not too complex, not too simple, exactly right to solve the problem in an elegant way given the real world you work in. At the end of the day you feel proud... proud of those beautiful lines and those smart decisions you made along the way.

Some days you feel less proud. Perhaps a PM is pressuring you to whip up something good enough to give users the value before someone else does. But still, you have these good days to live for.

But this was yesterday. Today you woke up to a world that is totally different than it was yesterday. It seems that craftsmanship isn’t that important anymore. How did this happen? Why? Where did the fun go?

A few weeks before today

By some random chance you were in a strange meeting. At least strange to you. Up until now you might not have been involved in planning, but this time you had to jump in for some reason.
The PM walked into planning with a feature spec. Sixteen pages. User interviews, wireframes, acceptance criteria. The team started estimating: two weeks, maybe three. Someone asks about database schema changes. Another about the API layer. You were already sketching microservices in your head. Tech lead lets you all talk for five minutes and then asked three questions.

Who asked for this?
What problem does it solve?
Can the existing admin panel already do this?

Ten minutes later, everyone realizes the whole thing can be solved by exposing an existing feature to a different user role. No new code. No sprint. No architectural debate that takes longer than the actual work.

The PM looks relieved. The team (including you) looks vaguely cheated because they were ready to build something interesting. Tech lead just saved two weeks of engineering time by asking what didn’t need to exist.

Their GitHub commit history will show nothing. Their performance review won’t list this under features shipped. But they just delivered more value in fifteen minutes than most engineers create in a month.

This is what being senior actually looks like. And it’s invisible.

The value that doesn’t show up in GitHub

Junior engineers are evaluated on what they build. How fast they ship. How fast they learn the domain knowledge. Lines of code written. PRs merged. Features deployed.

The metrics are concrete because the value is obvious: they’re learning to translate requirements into working systems. Output matters at this stage.

Then you hit mid-level and get really good at this. You write clean code. You know the patterns. You can architect elegant solutions. You take pride in the quality of what you ship. This is where it feels right. You’re a craftsperson. Your GitHub activity graph is a thing of beauty, deep green fields of your worthiness.

And then something uncomfortable starts happening.

You’re in more code reviews than implementations. More planning discussions than deep work sessions. People keep asking your opinion on things before they’re built.

The equation already shifted. Your value isn’t what you write anymore. It’s what you prevent from being written.

The unnecessary feature that creates years of tech debt. The over-engineered solution nobody can maintain. You get the idea.

Your Github doesn’t resemble the green pastures anymore. And that’s not bad, it just seems to you this way.

Because you’re not prepared for this shift.

Why saying no is the highest leverage

Every feature you ship creates a maintenance burden. Someone has to monitor it. Debug it. Update it when dependencies change. Explain it to new team members and even support users who misunderstand it.

One harmless example: the team wants to add a feature flag system. Sounds reasonable, right?

Feature flags solve deployment risk. They also create combinatorial explosions of system states. Six flags create 64 possible configurations. Most are never tested. Some are broken. And any of them can happen in production.

You just traded one problem for sixty-four.

Then you ask: what are we actually trying to solve? Turns out they want to A/B test one feature for two weeks. You suggest a time-based rollout instead. Same outcome, fraction of the complexity. No permanent infrastructure to maintain.

This is force multiplication. One conversation prevented months of maintenance burden. The team ships the feature, learns what they need, and moves on. No lingering infrastructure debt.

The best engineering leaders I’ve worked with have this in common: they say no more than they say yes. Not because they’re negative or risk-averse, but because they understand opportunity cost and want to say yes to the right things.

The engineer who can’t say no is just a backlog execution engine. The one who says no strategically is leading.

No sense optimizing for output when the game already shifted to judgment.

The curation skill that AI makes critical

AI can generate code in seconds. Entire functions, sometimes entire features. The initial reaction is panic: if AI can write code, what’s left for engineers?

Wrong question. AI made code generation cheap. It made code curation critical.

You ask AI to build an API integration. Thirty seconds later, you have 500 lines of code. It runs, tests pass, ships to staging.

Then you read it.

There’s redundant error handling. The retry logic will DOS your own service under load. If this is what you intended, good for you, but I doubt it. It’s using a deprecated version of the library, half the code is boilerplate that belongs in a shared utility, and the other half makes assumptions about the API that aren’t documented and will break silently when they change.

You delete 400 lines. Rewrite 50. Ship 100.

AI just made your judgment more valuable, not less.

Junior engineers using AI are productive until something breaks. Then they’re stuck because they don’t know how to evaluate what AI generated. They can’t tell good code from plausible garbage.

Senior engineers using AI move faster because they know what good looks like. They can review, refine, and reject in seconds. The fundamentals let them treat AI like a junior developer: helpful, needs oversight, occasionally brilliant, frequently over-complicated.

When generation is cheap, curation becomes the constraint.
Can you tell if the code is correct? Secure? Maintainable? Necessary? That’s the value.

The engineers panicking about AI are counting lines of code. The ones who know they’re safe are counting decisions made.

When your identity doesn’t match your career

Now someone’s telling you the valuable skill is not writing code?

Your identity is tied to I write excellent code. That’s what you’re confident doing and that’s how you measure a productive day.

If you’re still measuring yourself by output, this feels like going backwards. I’m not even doing real engineering anymore. I’m just...talking.

Some engineers resist this for years. They keep trying to be pure implementers because that’s where they feel valuable. They avoid planning meetings. They measure their worth by GitHub activity. Then they wonder why they plateau, why they’re passed over for senior roles, why engineers who aren’t as good get promoted past them.

It’s not that they’re not skilled. It’s that they’re optimizing for the wrong thing. They’re trying to be the best at a game that stopped mattering at this level.

Others make the shift but feel guilty about it. They’re not coding so they must not be contributing. They prevent a disaster but can’t point to a feature they shipped. They delete half a system and feel like they wasted time because there’s nothing new to show.

Both are wrong about what’s valuable. The market already decided. The people who can prevent bad work are worth more than the people who can only do good work.

Your identity has to catch up to where your career already is.

The new scoreboard

If your self-concept is I write code, AI is an identity crisis waiting to happen. If it’s I solve problems and build systems, AI is just another tool.

AI just compressed the timeline. Mid-level engineers used to have years to develop judgment before they needed it for promotions. Now they need to start building it immediately, while AI handles more of the implementation. You won’t become senior overnight. But you need to start acting more like one— asking different questions, making different decisions and honing slightly different skills.

This means updating how you measure your value. Stop counting commits. Start tracking how quickly you spot problems in requirements, how many architectural decisions you influenced, how effectively you questioned assumptions before code was written. The work shifted from writing code to deciding what code should exist.

None of this shows up in velocity metrics or GitHub stats. All of it shows up in team effectiveness, system quality, and whether people trust your judgment.

Measure how good you became at problem solving, how many subtle bugs you caught in AI-generated code, how well you designed the system for others to use.

This isn’t the first time (and it won’t be the last)

If you’re resisting this shift, you’re not alone. Engineers resist every time their value proposition changes. The pattern repeats. The adapters win and the resisters plateau.

In 1968, the NATO Software Engineering Conference declared a crisis. Programming had been math and art, which is a nice way of saying ad-hoc, individual, and impossible to scale. The shift to software engineering demanded systematic rigor, planning, and discipline. Engineers who saw themselves as creative problem-solvers resisted the factory metaphor. They insisted real programming was craft, not process. The ones who adapted became the first generation of professional software engineers. The ones who refused stayed hobbyists.

Fast forward to the 2000s. You write it, you throw it over the wall to ops. Then Amazon and Netflix said you build it, you run it. Engineers had to own production, on-call rotations, security, monitoring. Developers who saw themselves as pure coders resisted. I’m not an ops person. I write code. The ones who adapted became the high-value full-stack engineers who could ship and maintain. The ones who refused got stuck in legacy roles while the market moved to DevOps.

Same pattern with Agile in 2001. Waterfall engineers valued specialization, documentation, upfront planning. Agile demanded iteration, collaboration, generalists who could work across the stack. The specialists who insisted I’m a backend engineer, not a generalist watched as full-stack engineers became more valuable. Not because full-stack engineers were better coders. Because they could move faster with less handoff friction.

AI is creating another shift, but it inverts the pattern. Agile generalists were valuable because they could implement across the entire stack. AI-era generalists are valuable because they can think across domains while AI handles implementation. The new generalist isn’t someone who codes in five languages, but someone who understands business problems, architects solutions, validates AI output, and iterates on problem framing rather than implementation details. The engineer who insists I just write code is becoming today’s waterfall specialist.

Every shift follows the same script: the market redefines what’s valuable. Engineers with identities tied to the old definition resist. Adapters shape the new landscape. Resisters wait for things to go back to normal.

They don’t.

The engineers who thrived through these shifts weren’t necessarily the most technically skilled. They were the ones who recognized the pattern early and asked: What does the market need now? How do I stay relevant? What’s my value if the old metric broke?

AI is the latest iteration of this pattern. And it’s happening faster than the previous ones.

The question isn’t whether this shift will happen. History already answered that.

AI just made this shift non-optional

If you were going to resist this shift for another few years, AI just killed that plan.

When code generation was slow, companies needed people who could type fast. When AI can generate a working feature in minutes, companies need people who can tell if that feature should exist at all and what should exist instead.

The shift from write code to decide what to write just became urgent. Not in five years. Now.

The engineers who aren’t panicking already made the shift. They knew their value was judgment, architecture, prevention, curation. AI made them more productive because they can generate, review, and reject faster. Their constraint got more valuable.

Career paths are changing, and some engineers are helping shape them.

Most leadership teams haven’t fully figured this out yet. We’re trying to understand what senior engineer even means when juniors with AI can ship features in days. The engineers who show up early to those conversations help define the criteria. The ones who wait find out later what the new bar is.

The shift is happening. Some are steering it. Others are watching it happen to them.

How to navigate this shift

For engineers

The engineers I’ve watched navigate this successfully started by asking themselves uncomfortable questions. What would your job look like if AI could write all the code you write today? If the honest answer is I’d have nothing to do, that’s a signal worth paying attention to.

Look at the senior engineers you respect. What are they doing with their time? Probably not grinding out features. The ones who made this shift started using AI differently—not just to generate code, but to challenge their solutions, help them brainstorm, identify weak spots in their thinking.

Another question worth sitting with: if you couldn’t touch code for a month, how would you add value? If you can’t answer it, you might need to develop different skills. Not guaranteed to be easy, but beats ignoring the pattern.

For leaders

You can’t force your team to see this shift. But you can create conditions where they’re more likely to notice.

What I’ve seen work: start measuring and recognizing different things. Problems identified and framed clearly. Architecture decisions that prevented future issues. Bugs caught in AI-generated code. Time from problem to deployed solution, not time coding.

The identity piece is tricky. Engineers tie their worth to craft. The leaders who handle this well don’t tell their teams coding doesn’t matter (it does), but help them see they’re moving up the value chain. You’re too valuable to spend time on implementation that AI can handle. I need you focused on problems AI can’t solve.

Some practical forcing functions I’ve seen: require AI usage for routine tasks, make hand-coding the exception that needs justification, pair engineers on problem decomposition before any coding starts.

The emotional resistance is real. Some engineers feel like they’re cheating or losing skills. Acknowledging it directly seems to help. Yes, you’re writing less code. That’s the point. Your judgment is what matters now, and judgment only develops by solving more problems, not by typing more characters.

Engineers who resist aren’t wrong or stupid. They’re measuring themselves by the old scorecard. The work is helping them see a different scorecard, which changes what they optimize for.

Some won’t make the shift. They’ll insist real engineering is code and plateau. I learned my job wasn’t to save everyone. It was to make the pattern visible.

The market is already sorting this out. Companies going AI-native are looking for engineers who can evaluate, architect, prevent, and decide, not just implement. The job descriptions have shifted. The interview questions have shifted. The career paths are shifting.

Some engineers are participating in defining what this looks like. Others are waiting for someone else to decide their value.

Both are choices.