I was trained, like most developers, to value the code I wrote. A blank function became lines, files, features. The visible proof of the work was the thing I had produced. I often enjoyed refactoring more than writing the first version. Tidying a messy corner of the codebase, finding the smaller shape inside the larger one, chasing a bit of elegance: that felt like craft. It gave me a real sense of accomplishment. Once the code existed, I checked it the direct way: run it, click through it, look at the result.
Three activities, roughly in this order of time spent:
- Writing code. The bulk of the day.
- Refactoring it. The cleanup, the polish, the chase for a bit of elegance.
- Testing it by hand. Clicking through, printing values, eyeballing output.
Coding agents invert all three. This note is about the first two: production and deletion. The third, how I now check the work, deserves its own note.
Production stops being the bottleneck
When a capable agent can generate a plausible first draft in seconds, typing is no longer the constraint. Generation is cheap now. The expensive work is deciding whether the generated code deserves to enter the system at all. Is it the right shape? Does it duplicate something that already exists? Is it carrying three abstractions where one would do? Does it make tomorrow's change harder?
When code becomes cheap to produce, the cost shifts to reading it, constraining it, and deciding what to keep.
The new core skill is subtraction
Agents overproduce. They hand me helpers I did not ask for, defensive branches for states that cannot occur, and layers of indirection for futures nobody has committed to. That excess is a predictable result of making production almost frictionless.
My own attachment to code became the problem. I held on to it because it represented effort, judgment, and time. Refactoring felt good because I could improve something rough without losing it. Deletion felt different. Removing code could still feel like removing a small part of my work, even when the system was better without it.
Coding agents exposed that attachment. The code was often not mine, and even when it was, keeping it was not proof of care. Deleting more was only part of the adjustment. I had to treat generated output as raw material, assume the first version was too large, and keep working until the useful shape was smaller and clearer.
Refactoring moved from occasional cleanup to the main loop. De-slop the diff. Cut every part that is not paying rent. Collapse three near-duplicate functions back into one. The question I keep asking is: "what can come out without losing anything that matters?"
From adding to subtracting
Two of the three activities have already flipped. Producing code, once the bulk of the day, is the cheap part. Refactoring, once the occasional cleanup, becomes the operating mode. My center of gravity has shifted from adding to subtracting: from "what should I write?" to "what can come out?"
The tool changed quickly; my habits did not. An agent can produce a credible draft, but I still have to decide what belongs in the codebase. More output does not help if the selection stays weak. The difficult part is letting go without treating deletion as a loss.
The inversion changes more than the balance between production and deletion. It also changes how a human and an agent should divide a feature that still needs design, implementation, testing, verification, and documentation. I cover that next in The Work Is the Same. The Working Style Is Not.
That still leaves the third activity: how to check the work. Eyeballing the output of a system that writes faster than I can read does not scale. The replacement changes the job as much as production and deletion did. I cover it in The Verification Loop. The open-source release that came out of this shift is Governance Kit.