This article was originally published on runaihome.com
A short phrase — "vibe coding" — captured the 2025 mood among developers. The basic shape:
you describe what you want in natural language, an AI agent writes most of the code, you
review and accept. The productive ceiling has gone up dramatically. The number of engineers
companies need to staff a given roadmap has gone down. Layoffs in 2025 hit hard, and the
2026 numbers are not looking better.
If you are a working programmer reading this, you have probably wondered the same thing
everyone has: what does my career look like in two years? This article is one
practitioner's honest answer, written from the inside of the change rather than from a
think-piece distance.
What changed, concretely
I have been a backend engineer for years. The shape of my workday has shifted noticeably.
Before AI assistants:
- 30% of time: actually writing code (typing into editor)
- 30% of time: reading existing code, looking up docs, debugging
- 30% of time: meetings, design discussions, code review
- 10% of time: deciding what to write next
Now:
- 5% of time: actually typing code (the AI types, I tab/accept)
- 25% of time: writing detailed prompts and specifications
- 25% of time: reviewing AI-generated code carefully (more careful than I used to be on my own code, because the AI is overconfident)
- 30% of time: meetings, design, system thinking
- 15% of time: deciding what to do next, integrating, testing
The keyboard time dropped a lot. The thinking time stayed similar. The reviewing time went
up sharply. The "deciding what to build" time grew because I can now build more things, so
the bottleneck moved upstream.
Net effect on what I produce: maybe 2x the merged code, with significantly fewer bugs that
make it past review. The AI is a tireless code reviewer of its own output if you ask it to
be.
The fear is rational; the conclusion isn't always
The 2025 layoffs were real and they will continue. Companies absorbed AI productivity gains
in two ways:
- Ship the same roadmap with fewer engineers (head-count reductions).
- Ship a much bigger roadmap with the same engineers (rare; happens at growth-stage companies).
Most public companies are in bucket 1 right now. Most growth-stage companies are in bucket 2.
Where you sit determines whether AI is a threat or a tailwind.
But "AI replaces programmers" overshoots. The closer truth is: AI replaces typing-bound
programming work. It does not (yet) replace the work of:
- Deciding what to build
- Modeling a complex domain
- Navigating ambiguous requirements with stakeholders
- Code review with judgment about long-term maintainability
- Debugging production issues with incomplete information
- Operating under unusual constraints (latency budgets, regulatory requirements, hardware limits)
The bottom 30% of programmers — those whose contribution was mostly typing implementations
of well-specified work — are at real risk. The top 30% — those who do the work in the bullet
list above — are seeing their productivity multiplied. The middle 40% are figuring it out.
What is appreciating in value
I have been watching what the senior engineers who thrive in this period do. Some patterns:
Specifications, not implementations
The skill of decomposing a vague problem into a precise specification an AI can execute
is the single most valuable skill that has appreciated. If you can write a prompt that
captures all the constraints, edge cases, and stylistic preferences for a piece of code,
you can ship features 5–10x faster than someone who can only write code by hand.
This skill turns out to be roughly the same as "being good at reviewing other people's
PRs" — you have to think carefully about what is required and what is not. Senior engineers
who were great PR reviewers seem to adapt fastest.
Code review judgment
The AI will produce code that compiles, passes tests, and looks correct — but is wrong for
the codebase. Wrong abstraction. Mixes layers that the team has explicitly separated.
Re-implements a utility that already exists. Adds a dependency the team has been trying to
remove.
Catching these requires taste and context. Both are hard-earned. AI does not have them.
Engineers who can review AI output the same way they reviewed junior engineers' output —
with patience and judgment — are massively more productive than those who just accept what
the AI produces.
System thinking
When you can produce a feature in 30 minutes that used to take 3 days, the question shifts
from "can we build this" to "should we build this, and how does it fit." Engineers who can
see across services, data flows, and architectural boundaries are catching the work that
"vibe coding" creates upstream.
Debugging production
Logs lying. Metrics confusing. Heisenbugs. Distributed-system failures that only happen
under specific load. AI is improving here but is still much weaker at debugging an
under-specified, half-broken system than at writing a clean greenfield service. Strong
debugging skill is appreciating.
Domain expertise
Three years deep in a specific business domain — payments, ML infrastructure, healthcare,
embedded — beats six months of generalist experience plus an AI assistant. Domain-shaped
problems require domain-shaped intuitions, which AI assistants do not have unless you load
them into the prompt every time.
What is depreciating in value
- Pure coding speed. If your value was "I can crank out CRUD endpoints fast," that premium is gone.
- Memorizing language and framework details. The AI knows the docs better than you do. It is fine to look things up; the time taken is no longer a meaningful productivity gap.
- Implementing well-specified tickets. Junior tickets that were "implement this exactly as described" are increasingly handled by AI directly.
- Boilerplate work — config, glue, scaffolding, repetitive transformations.
This is uncomfortable for engineers who built their identity around speed-of-typing or
breadth-of-syntax knowledge. Those skills are not useless, but they no longer differentiate.
Concrete things to do this year
If you are an in-the-trenches programmer trying to stay valuable, here is the actual list:
1. Become better at code review than the AI
Start treating AI output exactly like a junior engineer's PR. Comment on it. Push back on
it. Force yourself to articulate why a chosen abstraction is right or wrong. The skill
of fast, deep code review — including for AI-generated code — is the single most valuable
muscle to build right now.
2. Move up the value chain on at least one axis
Pick one of: domain expertise, debugging skill, system architecture, technical leadership.
Spend deliberate time getting better at it. Read the architecture review docs at your
company. Volunteer for the on-call rotation. Take the messy bug everyone is avoiding.
The engineer who is "the person who knows the payments system end to end" is irreplaceable.
The engineer who is "the person who can write JavaScript fast" is replaceable by an
AI agent.
3. Build a side asset
Not because side hustles are a financial necessity (yet), but because owning something
outside your employer is hedging your single-point-of-failure risk. A blog with technical
content. An open-source library. A small SaaS. A book. Anything that compounds in your
absence.
This blog you are reading is one such asset. Building a public technical reputation is
roughly as productive as a 10% raise per year, compounded over a decade.
4. Get fluent with AI tools, not anxious about them
The engineers who are most threatened are not the ones using AI tools heavily — they are
the ones who refuse to. Use Cursor or Continue.dev daily. Run local models. Build agents.
Become the person on your team who teaches others how to do this. Tool fluency is a real
moat.
For the practical setup, see our [compariso
Top comments (0)