How AI Replaced My Job (Not Really)

The Reluctant Start

I have worked with a UK-based company for well over a year now. A few months before joining, I discovered agentic IDEs. At the start, I was reluctant to not write a single line of code. I had a junior developer I'd assign tasks to, and I'd verify and fix the small bits with the IDE on the side.

That worked for a few months, until a task landed on me that was nothing like what I'd been delegating. I had to take the whole thing on myself.

So I went back to the good old days. Whiteboard. System diagrams. DB schema. Sequence flows. Complex logic mapped out by hand. Then I prompted the AI with everything I had, and it gave me a working POC. Because the logic was mine, I could verify every endpoint and the entire flow. It worked. A few more prompts and the prototype was with QA.

Their feedback came back. I read it, thought about it, and pretty much copy-pasted it into the IDE. Version 2 was ready. This loop kept running. I delivered a production-ready system without writing a single line of code. But absolutely reviewing every line of it.

Learning by Prompting

After that, I was assigned a task to automate the testing suite for the website. I had basics: I knew what test cases were, that they were written in pytest, and that browser apps used Selenium and Playwright. That was the whole of my knowledge.

The first PR I shipped had unit tests and integration tests, the only two I'd heard of. It merged. Phase two was end-to-end, which I didn't even know existed as a category. Conversing back and forth with the AI, I learned about the test pyramid (unit, integration, e2e). That PR was significant: I spent the week untangling the mess that was already there. I learned about structure, baselines, CI integration, mock databases.

The point: I wasn't writing code. I was prompting, reviewing, and learning. The end result was a stable test pyramid that everyone on the team followed after the development phase.

The Workflow That Stuck

A few projects in, I stopped reading PRDs and feature requirements line by line. Instead, I recorded every meeting, dumped them into NotebookLM, and curated everything into one large markdown file. That file lived in the repo root, as context the AI could pull from at any time.

I was basically running a Recursive Language Models (RLM) pattern before the MIT paper came out: a primary model orchestrating itself against a large dumped context, recursively pulling what it needed instead of trying to fit everything into one prompt.

Every day looked the same: long meeting, long message threads, dump into context, AI does the heavy lifting, review, ship.

The Fear Underneath

From the outside, everything looked smooth. I was praised for efficiency and professionalism. My learning curve was at a peak: production-grade tools, real company processes, real systems.

But there was a quiet fear underneath: if a bug landed that the AI couldn't fix, would I actually be able to handle it myself?

That fear shaped how I worked. Every loop, the strategy got tighter. More context up front. More review at the end. Less trust in any single output. It is the most useful kind of anxiety I've had, the kind that keeps you sharp.

What I Actually Think Now

We are the middleman between requirements and implementation, passing context both ways. At this point, theoretical knowledge is what means the most. If you don't know how to protect your system, the AI only takes you so far. It doesn't know what your threat model is. It doesn't know what shouldn't exist.

My prediction for the future of coding: it comes down to how efficiently you can steer a model. The typing is the easy part now. The thinking isn't.

What a time to be alive.