AI Did Not Replace Me, It Promoted Me

By Odilon8 min read

AI Did Not Replace Me, It Promoted Me#

I started leaning on AI tooling heavily in October 2024. Copilot inside VS Code, mostly — autocomplete on steroids. A year and a half later I barely write code the same way, and honestly, I barely think about my job the same way either.

This post is me trying to write down what actually changed, without the hype and without the doom.

The Timeline#

  • October 2024 — Copilot in VS Code. Mostly inline completions. Useful, not transformative.
  • Early 2025 — Moved to Copilot CLI. First time I felt something shift. Running an agent in a terminal is a different mental model than tab-completing inside a file.
  • October 2025 — Switched to Cursor by request of the client I was working with. Good editor. Never clicked with me the way the CLI flow did.
  • December 2025 — Same client pushed me to Claude. The web app was fine. The CLI surprised me. Not incrementally — categorically. First week using it I rewrote a module in an afternoon that I had been picking at for two weeks.
  • March 2026 — Swapped back to Copilot VS Code + CLI for a while. Not because the quality is better. Because the quota is. Claude is the best tool I have used. It is also the most expensive per "fix this one thing" request, and when you are doing a hundred of those in a day, the math stops working.

That last point matters and nobody in the marketing materials wants to say it out loud: the best model is not always the model you should be running. Quality-per-dollar is a real axis.

My current ranking:

  • Raw performance: Claude > Copilot > Cursor
  • Quota / cost / daily viability: Copilot > Claude > Cursor

I flip between them depending on the task. Claude when I need something to actually think. Copilot when I need ten small things done and do not want to watch a token budget bleed.

What Actually Changed About My Work#

I used to code all day. I mean that literally — eight hours of typing, reading, debugging, typing again. Now I spend most of my day reviewing, prompting, redirecting, and occasionally fixing something an agent could not figure out.

It feels less like "senior engineer writing code" and more like "tech lead running a team of four juniors who never sleep and never get offended when you reject their PR."

The shift I did not expect: I work on multiple things at the same time now. Not context-switching in the bad sense. Actual parallelism. One agent is implementing a story in the money-track module. Another is writing tests for yesterday's work. I am reading the output of a third and deciding whether to let it keep going or kill it and retry with better framing.

This sounds exhausting. It is not. It is the opposite of exhausting, because the part of the job that used to drain me — grinding through boilerplate, wiring up the fifth CRUD form of the week — is not my problem anymore. My job is to decide what gets built, make sure it gets built correctly, and catch the cases where the agent confidently ships something subtly wrong.

From Idea to MVP in a Weekend#

The clearest measurable change: time to MVP.

Before AI, a side project idea was at minimum two to three weekends of work to get something demo-able. Auth, database wiring, a handful of pages, some kind of design that did not look like a 2011 Bootstrap template. By the end of weekend three I usually had something I was embarrassed to show people.

Now: one weekend. Sometimes Saturday afternoon to Sunday night.

The pattern that works for me:

  1. Friday evening — write the idea down in plain English, break it into four or five stories.
  2. Saturday morning — plan each story with an architect agent.
  3. Saturday afternoon — implementer agents run in parallel. I review.
  4. Sunday — glue, polish, deploy.

The speedup is not magic. It is that I stopped doing the boring parts, and the boring parts were most of the calendar time.

The Tension Nobody Talks About Enough#

Here is the honest part. AI tooling is not a free ride. The thing that determines whether you get 10x or 0.5x is not the model. It is how you manage context.

Agents work spectacularly when the scope is small and the context is curated. They hallucinate, contradict themselves, and silently break things when the scope is too big and the context is a mess.

The skill that matters now is not "prompting." Prompting is table stakes. The skill is:

  • Scoping the task small enough that the agent has a fighting chance.
  • Structuring the codebase so an agent can load just the relevant slice without dragging in the world.
  • Writing durable documentation — plans, conventions, architecture notes — that you can point an agent at instead of re-explaining the rules every single session.
  • Knowing when to stop an agent that is confidently going in the wrong direction, instead of letting it burn tokens trying to rescue a doomed approach.

The question I keep coming back to, and have not cleanly solved: how do you build up historical context for an agent without eating your entire token budget feeding it old conversations?

Memory files help. CLAUDE.md files help. Per-story implementation plans help. But there is still a real cost to "context as a first-class artifact" that did not exist when I was the one holding all the context in my head.

Small scope + good context = excellent results, almost no hallucinations. Large scope + vague context = a machine that lies to you in complete sentences.

The job, increasingly, is making sure you are always on the first side of that equation.

What This Means For How I Think About The Role#

I do not think "software engineer" is going away. I think what counts as one is shifting under our feet.

The value I bring to a project in April 2026 is not that I can type TypeScript faster than the next person. It is that I know what to build, I know what good looks like, I know when the agent is bullshitting me, and I know how to decompose a problem into pieces small enough that the tools work reliably.

That is a supervisor role. An orchestrator role. An editor role. Whatever you want to call it — it is not the role I signed up for in 2019, and I am genuinely surprised by how much I like it.

Where I Land#

Eighteen months in, my honest take is that AI tooling did not replace me. It promoted me into a role I would never have gotten otherwise, because no company would have given me four simultaneous juniors to manage on a side project.

Now I have them. They cost me tokens instead of salary. They are faster than I am at the boring stuff and dumber than I am at the interesting stuff, and that split is exactly where I want them.

The parts I still have to figure out: the economics (Claude quality at Copilot prices, please), the context management (how do I stop re-explaining the same project to the same tool every week), and the drift (am I losing skills I will miss in two years).

But if you asked me whether I want to go back to doing it the old way, the answer is no. Not even close.