LLMs make rewriting cheap and reviewing expensive

Software engineering has a new bottleneck. It is not writing code. It is reading it.

The insight comes from engineer Ishmeet Bindra, who published a short post on June 15 titled “Reviews have become expensive, rewrites have become cheap.” The piece runs 340 words. It captures a shift that changes how teams should organize around AI-generated code.

Bindra’s observation is simple. LLMs do not get tired. They do not take shortcuts. If a model knows how to implement something from scratch, it will write 200 lines of implementation rather than two lines of import. The cognitive cost is the same for the model. The result is code that is technically correct but structurally wrong. It works. It is just more code than it needs to be.

That creates a new cost structure. Reviewing AI-generated code now means reading through unnecessary complexity and deciding whether to accept it or push back. That decision takes time. Making the case in review comments takes time. And because the same pattern repeats across PRs, the same conversation happens over and over.

The flip side is that rewriting is now cheap. Bindra describes asking the AI to simplify code, use a library, or cut a feature that is not required yet. The model that created the problem is also the fastest way to fix it. The economics has inverted. Reviewing is the expensive step. Rewriting is not.

Bindra’s workload has reorganized around this. He spends more time upfront in planning, deciding what should exist, what libraries to use, what the actual scope is. That is where he can head off complexity before it gets written. Then he implements, deploys to a test environment, looks at what is there, and identifies what does not need to exist or could be ten lines instead of a hundred. Then he rewrites that.

The pattern is not unique to Bindra. It is showing up across teams that use LLMs for production code. Several engineering leaders at AI-first startups have described similar shifts in internal workflows. The planning phase becomes more important. The review phase becomes more adversarial. The rewrite phase becomes faster.

This has implications for how teams structure their review processes. If reviewing is the expensive step, the traditional model of writing code quickly and then having a senior engineer catch issues in review breaks down. The senior engineer becomes the bottleneck. They are reading more code, making more judgment calls, and having the same conversations repeatedly.

One response is to shift review earlier in the process. Bindra’s approach of more upfront planning is one version of this. Another is to treat the AI as a junior engineer that needs constant guidance about what not to build. A third is to accept the over-engineering and let the rewrite happen post-deployment, since the cost of iterating is low.

The deeper point is about what AI does to engineering judgment. Bindra notes that LLMs default to building when they should be buying. They mention existing libraries but do not reach for them. The model has no instinct for the shortest path. The shortest path for the model is to implement everything from scratch.

That is a capability issue disguised as a behavior issue. The model can write the code. It just cannot evaluate whether the code should exist. That evaluation is the core of engineering judgment. It is the part that requires context, tradeoffs, and experience. It is also the part that is hardest to automate.

For AI builders, the takeaway is about tooling. Current code generation tools optimize for writing speed. They produce more code faster. They do not optimize for reading speed. They do not produce less code. They do not produce code that is simpler to review.

The next generation of AI coding tools should optimize for the review phase. That means generating code that is minimal, that uses existing libraries, that comes with explanations of why the approach was chosen. It means treating the model as a participant in the review process, not just as a writer.

Bindra’s post is short. It does not offer solutions. It does not name specific tools or workflows. But it identifies a real shift. The bottleneck in software engineering has moved from writing to reading. Teams that recognize this will reorganize their processes around it. Teams that do not will find their senior engineers drowning in code that is technically correct but structurally wrong.

The cost of flagging something and iterating is lower now. The cost of letting it through is the same. That changes how aggressively engineers should push back in review. It changes what good code generation looks like. It changes what the next generation of AI coding tools should build.