Building · Essay

What seven days of AI-assisted coding changed about how I build

I built a server tool in a week with an AI pair. The build was the easy part. What it permanently changed about how I scope, delegate, and review.

A little over a year ago, I built a working server tool in about a week with an AI model as my pair. People still ask me about the speed, as if seven days were the interesting part. They were not. The build was the easy part. The part worth talking about is what those seven days quietly changed in how I work now, on everything, long after the novelty wore off.

I want to be precise about this, because there is a lot of noise on both sides. AI-assisted coding did not make me a ten times engineer, and it did not make engineering obsolete. It moved the work. It took the part I was good at and made it cheap, and it took the part I used to skip and made it the whole job.

The build was the easy part

For seven days, the model wrote most of the lines. I described what I wanted, it produced a first draft, and I corrected it. The boilerplate, the glue code, the second and third versions of a function, all of it came fast. If you measured the week in lines of code per hour, it looked like a miracle.

But lines of code per hour is a deeply silly way to measure building, and it always was. The miracle wore off the moment the tool met a real server with a real edge case, and I had to understand every line I had not actually written. Which, it turns out, is a different skill from writing it yourself.

From writing code to specifying intent

The biggest shift is that my job is now mostly upstream of the code. I spend my time saying, as exactly as I can, what the thing should do and why. The clearer I am about intent, the better the output. The vaguer I am, the more confidently the model gives me something plausible and wrong.

This sounds like a small change. It is not. For twenty years, the act of writing the code was also the act of thinking through the problem. The typing was slow enough that it forced clarity. Take the typing away and you can produce a great deal of code before you have actually finished thinking, and the model will happily help you do exactly that. So I had to learn to do the thinking on purpose, separately, before I let the machine type.

AI did not make me twice as fast. It made me twice as fast and exactly as wrong, until I learned to slow the thinking down.

The debugging tax nobody mentions

Here is the part the demos skip. Code you did not write is code you do not yet understand, and understanding it later, under pressure, costs time. The first week I leaned hard on AI output, I shipped quicker and then spent the following week paying it all back in confused debugging, because I was now maintaining decisions I had never consciously made.

So I changed the rule. The model can draft anything. But nothing ships until I can explain every meaningful line as if I had written it, because in the way that matters, I am about to own it. Our testing tooling catches a lot, but a test only checks the behavior you thought to check. Judgment is still mine.

What now counts as a weekend project

The practical effect is that the line between "too small to bother" and "too big to attempt" has moved. Things that used to need a sprint now genuinely fit a weekend, so we attempt more of them. That is the real productivity gain, and it is large. But the same shift makes it dangerously easy to start things, because starting is now almost free. Finishing, maintaining, and operating them costs exactly what it always did.

This is why I am stricter than ever about asking why before I start. When building gets cheap, the scarce discipline is not building. It is choosing.

The part that did not change

After all of it, the things that decide whether software is any good are exactly the things the model cannot do for me. Picking the right problem. Having taste about the shape of a solution. Knowing which 5 percent of the work is the actual point. Being accountable when it breaks. The model is a remarkable typist and a fast, confident, occasionally hallucinating junior. I am still the one who has to run the thing in production and answer for it.

So I have stopped asking whether AI will replace engineers. The better question is which part of engineering you were actually being paid for. If it was the typing, that part is now cheap. If it was the judgment, you just got more valuable, and a lot busier.

NJ Nikhil Jathar “The machine wrote the code. I still own the 2am pager.”