Reviews have become expensive, rewrites have become cheap

Hacker News Top News

Summary

LLMs make code reviews more expensive by generating over-engineered code, but rewrites are now cheap, shifting developer workload toward more upfront planning and iterative simplification.

No content available
Original Article
View Cached Full Text

Cached at: 06/16/26, 03:02 AM

# Reviews have become expensive, rewrites have become cheap Source: [http://ishmeetbindra.com/posts/reviews-have-become-expensive-rewrites-have-become-cheap/](http://ishmeetbindra.com/posts/reviews-have-become-expensive-rewrites-have-become-cheap/) LLMs aren’t lazy\. They don’t cut corners because a simpler solution feels good enough\. If they know how to solve something thoroughly, they will\. An LLM defaults to building when it should be buying\. Not because it doesn’t know about existing libraries, it often mentions them, but because for an LLM, writing two hundred lines of implementation is the same cognitive effort as writing two lines of import\. There’s no instinct to reach for the shortest path\. The shortest path for the model is to implement it completely\. So reviewing AI\-generated code has gotten more expensive\. You’re reading code that’s technically correct but over\-engineered, and you have to decide whether to accept the complexity or push back\. That decision takes time\. Making the case in review comments takes time\. And because the same thing shows up repeatedly, you’re having the same conversation over and over\. On the other hand, rewriting is now cheap\. If I identify code that’s more complex than it needs to be, in my own work or in someone else’s PR, I ask the AI to simplify it, use a library, cut a feature that isn’t required yet\. The rewrite is often a quicker turnaround\. The model that created the problem is also the fastest way to fix it\. The economics has changed\. Reviewing is the expensive step now\. Rewriting is not\. My workload has reorganized around this\. I spend more time upfront in planning, deciding what should exist, what libraries we’re using, what the actual scope is, because that’s where I can head off complexity before it gets written\. Then I implement, deploy to a test environment, look at what’s there, and identify what doesn’t need to exist or could be ten lines instead of a hundred\. Then I rewrite that\. If something in review feels like too much, rewriting it later is not the sunk cost it used to be\. That’s changed how aggressively I push back\. The cost of flagging something and iterating is lower\. The cost of letting it through is the same\.

Similar Articles

Coding Models Are Doing Too Much

Hacker News Top

A blog post investigating the "Over-Editing" problem where coding LLMs rewrite more code than necessary when fixing simple bugs, proposing metrics and training approaches to encourage minimal, faithful edits.

Code is Cheap(er)

Lobsters Hottest

Carson Gross (htmx creator) argues that while AI has made code generation cheaper, understanding code has become more expensive, and warns developers against the 'Sorcerer's Apprentice' trap of letting LLMs generate unmanageable complexity. He advocates for incremental LLM use and maintaining deep understanding of codebases.

- -dangerously-skip-reading-code – olano.dev

Hacker News Top

The article argues that as organizations adopt LLMs for code generation, engineering practices must shift from reviewing generated code to focusing on specifications and tests, with organizational buy-in for new processes.

The minimum viable unit of saleable software

Hacker News Top

An essay exploring how LLMs have shifted the buy-vs-build calculus for software, arguing that while AI lowers build costs, maintenance and human oversight still make building a non-trivial investment, using the example of replacing Jira with an LLM-built internal tool.