Care About the Input, Not the Code

In January I wrote that I read every change before it lands, every time. I meant it. A few weeks ago I noticed I hadn't opened VS Code in about four months, so I deleted it. I haven't missed it.

This isn't a hot take about AI replacing engineers. It's an honest account of how my job changed over the last year, and why I think the engineers who get the most out of these tools are the ones willing to let go of the code.

How it used to work

I work at Deskpro, and a good chunk of my time goes on fixing bugs. A year ago that was a manual job. Read the ticket, try to reproduce it, dig through the code to work out why it happens, write a fix, test it, open a PR. Reproducing alone could eat most of a day, especially when the bug depended on a third-party service we don't run locally.

Most of the effort wasn't the fix. It was everything around it.

How it works now

Now a bug goes through a chain of skills I run with Claude. It grabs the context from the story. It reproduces the bug, often in minutes, mocking any services we don't have locally. It hashes out a plan with me. Once I'm happy, it carries out the plan, checks the fix in the browser if it's a UI bug, reviews its own changes and argues with anything that looks off, runs a security pass, and opens the PR with evidence attached.

My part is the decisions. When Claude shows me options, I'm looking for the most surgical fix. The smallest blast radius, the fewest trade-offs, the least chance of breaking something two screens away. That judgement is the part that needs me. Typing the fix doesn't.

"But how do you know it's right?"

Honestly? I don't. But I never did.

When I wrote every line myself, I still shipped bugs. I was never the thing that made code correct. The safety net was always the system around me: unit tests, the end-to-end suite, CI, manual QA, and now a rule that every PR ships with evidence that it actually does what it says. I trust that process. It caught my mistakes before, and it catches Claude's now.

Reading the diff line by line felt like diligence. Most of the time it was comfort.

Why I stopped caring about nits

Code review changed for me too. When I'm asked to review a PR, Claude triages it first. It marks the mechanical, obvious files as viewed and leaves me the files that actually changed behaviour. I look at those, understand what changed and why, and decide whether it's right.

I don't leave nits. How someone wrote a loop, how a file is laid out, whether I'd have named something differently. Prettier and PHP CS Fixer handle style, and I'm not reading the code anyway. Machines read the code now. Arguing over how it looks is arguing over something nobody is looking at.

What matters is whether the change is correct, safe, and does what the ticket asked. That's the review.

Where it's harder

It isn't all smooth. Exploratory work, especially new features where nobody knows the shape of the answer yet, takes a lot more back and forth. But even then I don't reach for an editor. I just have a longer conversation. Talking a problem through like I would with a colleague beats typing things into a file and seeing what sticks.

This leans on experience

I should be clear about something. Not reading the code works for me because of what I bring to the decisions. I've been building for the web for about twenty years and I've been at Deskpro for nearly four. When Claude gives me three options, I know the codebase, the product, and the customers well enough to pick the right one quickly, and to spot when none of them are right.

That context is the input. Without it, you're approving things you can't judge, and that's a different and riskier game. If you're earlier in your career, I don't think the lesson is "stop reading code". It's that knowledge of the domain, the product and the trade-offs is what will carry you, not the speed of your typing. Build that up, and the trust follows.

Care about the input

Everyone I work with has the same tools. The same models, the same shared skills, the same sandboxes. The tools aren't the difference. Letting go is.

I think a lot of engineers are still attached to writing the code, or at least reading it, because that's what the job has always felt like. But writing code was always the slow part of building software, and it isn't any more. The job now is the input and the output. Give clear boundaries, good context and solid guidelines going in. Check the evidence coming out.

If you've got both of those right, what are you reading the code for?

AI isn't going anywhere. The sooner we stop treating the code as the work, the sooner we can focus on the parts that actually need us.