Developers Don't Read Code Anymore. What Now?

Developers Arent Reading Code Anymore

With GenAI IDEs in the mix, it's increasingly common for developers to skip fully reading the code they commit.

Not because they're careless. Not because they don't care about quality.

But because the system quietly allows it.

Over time, this becomes normal. Code is written, partially skimmed (hopefully!), quickly committed, and "someone else" is expected to catch issues later.

The result is software that works just enough--until it doesn't--and teams that slowly lose their ability to reason precisely about their own systems.

Unread code is not a minor localized issue.

It is a structural failure of our legacy systems to cope with new developments.

The Hidden Cost of Committing Unread Code

When engineers commit code they haven't properly read, several things degrade--often invisibly at first:

Understanding weakens: Engineers cannot clearly explain what their own changes do.
Debugging skills erode: When production breaks, nobody has a sharp mental model of the code path.
Errors compound: Small logical mistakes, incorrect assumptions, and calculation errors slip through early and metastasize later.
Responsibility diffuses: "It passed review" replaces "I stand by this code."

None of this happens overnight. It emerges gradually as a cultural pattern.

Believing Culture vs Checking Culture

At the root of the problem is a cultural distinction most teams never articulate.

Believing Culture

A believing culture runs on assumptions:

We believe the author read the code.
We believe reviews happened.
We believe tests cover the important paths.
We believe problems will be caught later.

Belief scales poorly. The larger the system, the more fragile belief becomes.

Checking Culture

A checking culture, by contrast, runs on evidence:

Code is reviewed before it is committed.
Reviews leave artifacts.
Responsibility is explicit, not implied.
Assumptions are verified early.

Other serious disciplines learned this lesson long ago:

Aviation uses checklists, not confidence.
Accounting uses audits, not trust.
Cryptography uses verification, not belief.

Modern software engineering, particularly with GenAI, oddly, tolerates belief at its most critical boundary: committing code.

Why Merge-Time Reviews Are Too Late

Most teams rely on reviews at merge time. This feels reasonable--but structurally it is the worst possible moment.

At merge time:

Diffs are large.
Context is stale.
Authors have already moved on.
Time pressure dominates care.

The review becomes ceremonial. It exists to unblock merging, not to build understanding.

If you want a culture of checking, review must happen earlier--when the code is small, fresh, and owned by the person committing it.

Reviewed-by-Default Development

The fix is not "more discipline" or "better intentions."

The fix is a default that makes unread code hard to commit accidentally.

The principle is simple:

Code should not be committed unless it has been checked.

Not "reviewed before merge." Not "reviewed eventually."

Reviewed before commit.

This is reviewed-by-default development.

Making Checking the Default with LiveReview CLI

Culture only changes when systems enforce it.

LiveReview CLI (lrc) (read more) introduces AI-assisted pre-commit reviews, tightly coupled to Git, and enforced at the team level.

The workflow is intentionally minimal:

git add .
git lrc review
# or: git lrc review --skip
git commit -m "message"

Before the commit completes, a review runs on the staged changes.

Every commit records an explicit outcome:

LiveReview pre-commit check: ran

or, if consciously bypassed:

LiveReview pre-commit check: manually skipped

There is no silent path.

Either the code was reviewed--or the developer explicitly chose not to.

That distinction matters.

Why This Works

This approach succeeds not because of AI sophistication, but because it restructures responsibility.

1. Responsibility Is Explicit

Developers can no longer claim "I didn't notice." They either reviewed the code or consciously skipped review.

Both actions are visible.

2. Reviews Are Incremental

Commit-level reviews are small by definition. Small reviews are readable. Readable reviews get done.

3. Checking Happens Early

Mistakes are caught when they are cheapest to fix--before they harden into history.

4. It’s a Hygiene Habit, Not a Process Overhaul

This isn't bureaucracy. It's the same class of habit as running tests before pushing.

Simple. Repetitive. Non-negotiable.

“Won’t This Slow Developers Down?”

Only if you think unread code is fast.

Unread code simply defers cost:

To debugging
To incidents
To lost confidence
To team fatigue

Pre-commit review pays the cost at the cheapest possible moment--when the diff is small and the author is present.

Speed without understanding is not speed. It's debt with interest.

Building a Culture of Checking

What ultimately matters is not the tool--it's the norm.

A healthy engineering culture should make this feel natural:

I don't commit code I haven't read.

LiveReview CLI exists to enforce that norm consistently, across repositories, workflows, and teams--without relying on memory or goodwill.

Believing cultures drift. Checking cultures compound.

Raising the Bar for AI Code Reviews

Those engineers who take pride in their profession won't do the following:

Deploying untested code
Skipping version control
Ignoring production failures

Similarly - with GenAI becoming an important part of engineering activities, we must also not allow unreviewed code into version control.

Unread commits are breaking software--and teams--today.

Building a culture of checking is how we stop it.