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:

1. Ship the same roadmap with fewer engineers (head-count reductions).
2. 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 comparison of AI coding assistants.

5. Stay technical, even as you grow

The pull to become a “manager who used to code” is strong, especially when AI is changing what coding looks like. Resist it for at least two more years. The most valuable engineers in 2027 will be the ones who stayed deeply technical through the AI transition — they will have judgment about AI-assisted work that pure managers can never develop.

A note on doom

Doomerism is easy in 2026. Layoffs are real. Compensation is being squeezed. AI is unsettlingly capable. But every wave of automation in software has played out the same way in the long run: the work shifts upward. The boring bottom is automated; the productive ceiling rises; the engineers who adapt end up doing more interesting work than they used to.

That doesn’t help if you get laid off in the meantime. So build the safety net (savings, side income, network), keep the technical edge sharp, and stop trying to be the thing the AI does. Be the thing the AI cannot do, surrounded by AI doing the rest.

And practically: build something of your own

This site started as exactly that — a working programmer’s hedge. If you are thinking about the same thing, the practical sequence is short: pick a niche you know well, set up a static site, write 30 articles in 90 days, plug into the standard ad/affiliate stack, and let it compound. The hardware and software side of “running AI at home” is the niche we picked. If you are reading this, you are inside the audience for it.

For the practical “set this up” path, our archive contains the hardware, software, and setup guides for getting started.

The job-security worry is real. The way out of it is to build, not to wait.