alt Hacker NewsIt's fascinating.
On the one hand, if you really want to unlock the potential of coding agents you can get a whole lot more value from them if you don't force yourself to read every line of code they produce for you.
On the other hand, that's clearly a terrible idea! These machines make mistakes. Unreviewed code is the most obvious form of technical debt - sure, you'll get a boost in the short term but how much will you regret it later?
Something that's helped me a bit is thinking about how I've collaborated with other teams at large companies. If my team depended on some other team's product I wouldn't review every line of their code before using it - I'd start using it, then if I ran into problems I'd dig into the code to see if I could figure out the problem.
That works with human teams because humans can take accountability for their work. Agents can't.
And yet... the more time I spend with specific agents, the more I learn what kind of problems I can "trust" them with.
If I ask Codex or Claude Code to build me an API endpoint that queries a database and returns JSON, including with tests, they're going to get that right. I can glance at the shape of the tests, hit the endpoint with curl, and be confident that the job is "good enough" without me reviewing every line.
Over time, the pool of tasks like that which I'm confident they're not going to screw up has grown.
A big part of the craft of using these things is developing the instincts to know when you need to dive in to the details and when you can relax a little.
Having a lot of experience helps a ton here. I have 25+ years of experience to help me make these judgement calls. If it's security adjacent I know to review much more thoroughly. I have a good idea for the kind of mistakes that can be made. I know what shape I like my tests in, and how to both manually and get-the-agent-to-manually test things.
Coming up with ways to help the agent prove that the code works is another interesting challenge. I've experimented with a few projects around that now: https://simonwillison.net/2026/Feb/10/showboat-and-rodney/ and https://simonwillison.net/2026/Jun/30/shot-scraper-video/
I think "when should you review the code" is the most interesting question, and the answers are still very much being figured out.
I agree with this. I am also starting to get a "feeling" of when I can trust an agent and when I can't. Recently I had it throw together a dashboard that displayed some basic linear models based on knobs on the dash, and I didn't really worry about it getting those wrong (I did spot check and it seemed good). But I also had to update a pretty complex flink app with state management changes that it totally borked.
The first task was more self constrained and less production impacting. The latter was detail oriented and required understanding complex distributed systems and state.
I would like to be able to formalize these kinds of tasks. I believe there are lots of confounding variables:
- Access to MCPs
- quality of documentation
- strong existing practices
- examples of similar code nearby
And then we can more easily determine what can be totally handed off and what can't be. I think that last one is most important, but similarly:
- how much this type of algo appears in the training set
Which is maybe part of the "feeling" that we have about what it will do well.