The file I couldn't find

A few months ago, an app I was working on threw an error. The message pointed at a file. For once I didn't paste it into the AI. I wanted to fix it myself.

I opened the project and I couldn't find the file.

It was my project. I had built it and shipped it, and I didn't know where anything was. I felt embarrassed, scared and angry, and honestly it was a little funny too. All of it at once.

How I got here

I wrote my first Python in CPGE, the two prep years after the bac. It was a calculator. I'd heard programming was the future, and at the time that was reason enough.

In my first year of engineering school I started reading books about programming. Clean Code was one of them, and it clicked. I started caring about how code reads.

In my second year I met chatgpt.com. It was a big deal. Then came Cursor, then Antigravity, and now Claude Code inside VS Code. Each tool sat a little closer to the code than the one before.

The drift

It didn't start with code. When I was looking for a job, I let the AI write my application emails. I remember thinking I didn't need to do that part anymore.

Code went the same way. At my worst, about 80% of what I shipped came from the AI, and I didn't review it. It worked, the client was happy, and I moved to the next ticket. Nothing broke loudly enough to make me stop.

What I actually lost

I want to be precise here, because "I forgot how to code" isn't true. With the language docs open next to me, I can still write the code.

What I lost was the map. I didn't know how my own projects were laid out, which file did what, or where a bug could hide. Debugging went with it, because you can't trace a bug through a project you've never walked through. The AI had read every file. I hadn't.

Why I changed

Mostly the embarrassment. Under it was a simple question. If the AI writes the code and I can't find my way around it, what am I adding?

I build AI agents for a living, and I was afraid AI would replace me. It wouldn't be because the AI got that good. It would be because I'd stopped bringing anything it couldn't.

How I work now

I didn't quit AI. I took back the parts I had handed over. My workflow now runs in stages, and the AI writes code only after I understand what we're building.

  1. Understand the project first. Before any change, I go through the codebase and list what I need to reread. My note on this step says the person who stopped reading the project eats the weeks-long debug. I was that person.
  2. Plan before building. The AI asks me one question at a time until we agree on what we're doing. Thirty minutes of planning saves hours of review.
  3. Write a spec that lives in the repo. The spec is the authority, and the code follows it.
  4. Break the work into small vertical slices.
  5. Build a slice, read the code, then move on. I review one to three slices at a time and steer again around 150 lines, not 2,000.
  6. Close the day with a log of what I decided and what I learned, so I don't learn the same thing twice.

The rules that matter most don't depend on willpower. They run as hooks that block the step if I skip it. Any rule I wrote after a real incident lives in a hook.

Not every task gets the full process. About 40% are small enough to go straight to the agent, with the hooks still on. New projects get every stage.

My delivery pipeline: understand the project, plan, write a spec, break work into slices, build with human code review, then log decisions and learnings. Hooks enforce the gates throughout.
My delivery pipeline, from understanding the project to closing the loop. Open the diagram full-size.

What I'm reading and practicing

I watched a talk with Robert C. Martin, Uncle Bob. What I took from it is that humans stay in the loop, AI hits a wall at some point, and experience is what gets you past it. His advice for people starting out now was to read the old books from the 90s, because that's where the real struggle is.

I'm starting with a newer one, Designing Data-Intensive Applications by Martin Kleppmann. My goal is system design. I want to draw the boxes myself before the agent fills them in.

For coding, I'm keeping it small. I write short functions by hand to get the reps back. I also pay more attention to clarity now: clear procedures, simple code, and less of it. More code isn't better code, and the AI tends to write more than the job needs.

To be honest about where I am, I haven't made an open-source contribution without AI yet. My one contribution so far, to the Federated Agent Protocol, I wrote with AI. Doing one by hand is next.

If you're starting out now

I'm still early in this myself, so take these as notes from someone a few months ahead of you.

  • Know where things live in your own project. If an error names a file, you should be able to open it without asking anyone.
  • Read every line before you ship it. If you can't explain a line, it isn't ready.
  • Learn some system design early, so you tell the AI what to build instead of finding out afterwards.
  • Read a few old books.

The software engineer job is not to say i trust u bro to the AI, while everyone says it, the job is to say stop !