From Friction to Precision

When friction becomes cheap, judgment becomes the signal

Chapter 1 — Opening

Over the last months, something shifted in how I work with AI.

Not in terms of speed.
Not in terms of replacing thinking.

But in terms of where the struggle lives.

AI removed a lot of friction for me, especially when structuring ideas, refining documentation, and iterating on design notes.

What surprised me was that thinking did not get easier.

It got sharper.

The friction decreased.
The pressure to think precisely increased.

And that pressure was not external.
It was not coming from a deadline, a team, or the tool itself.

It was internal.

I could no longer hide behind effort.
If a boundary was vague, the output exposed it.
If an invariant was missing, the structure fell apart.
If my thinking was fuzzy, it became visible immediately.

AI did not remove the struggle.
It relocated it.

Chapter 2 — Externalized Thinking

A recent example made this shift very visible to me.

I was designing a fairly boring but non-trivial backend workflow.
Nothing glamorous, just one of those persistence flows with edge cases, versioning concerns, and lifecycle questions.

In the past, this would have meant whiteboarding, rewriting notes, restructuring paragraphs, refining explanations over several passes.

This time, I externalized the thinking immediately.

I started by exploring options in rough form:

• Should this be snapshot-based or delta-based?
• Where does consistency live?
• What is the atomic boundary?
• Who owns interpretation?
• How do we ensure idempotency?

None of that was new.
The questions were the same as before.

What changed was how quickly incoherence surfaced.

If I tried to gloss over a boundary, the structure collapsed.
If I mixed responsibilities, the description became inconsistent.
If I left assumptions implicit, the output exposed the gap.

The thinking still happened.
But it became visible earlier.

And then something interesting followed.
Compression.

The same design could now exist at multiple resolutions.

For myself, it was conceptual and dense.
Invariants, boundaries, lifecycle semantics.

For another developer, it became a clean summary with clear scope and non-goals.

For an implementation agent, it turned into a deterministic specification with zero ambiguity.

Same thinking.
Different compression levels.
Chosen deliberately.

That is when I realized AI was not generating architecture.
It amplified the clarity in my thinking.
And it exposed where that clarity was missing.

Chapter 3 — Friction vs Pressure

Before using AI this way, friction and thinking were tightly coupled.

Writing was slow.
Restructuring was tedious.
Refining explanations took time.

Effort was visible.
And visible effort often felt like depth.

AI decoupled those two things.

Structural iteration became cheap.
Rewriting became instant.
Reframing an argument cost almost nothing.

That did not reduce the need for thinking.

It removed the hiding places.

The pressure shifted from effort to coherence.

I could no longer rely on the time spent writing as a signal of depth.
The only thing that remained was internal consistency.

If assumptions were vague, the output made that visible.
If trade-offs were unresolved, they surfaced immediately.
If boundaries were blurred, the structure collapsed.

The struggle moved from mechanical friction to semantic precision.

Chapter 4 — The Junior Problem

This shift becomes more complex when we talk about juniors.

There is a real concern here.

Learning has always depended on friction.

Struggling through ambiguity.
Debugging something that should work but does not.
Building a mental model slowly by encountering edge cases.

Recent studies suggest that heavy AI reliance can reduce skill formation in juniors. That risk is real.

If AI removes mechanical friction, it can also remove parts of that formative struggle.

And that matters.

Debugging, in particular, depends on having built an internal simulation of how a system behaves under stress.
That simulation does not form by accepting working code.
It forms by wrestling with why something fails.

The hinge is not AI versus no AI.

It is cognitive engagement versus cognitive delegation.

If a junior uses AI as a completion engine and stops at “it works,” the struggle disappears.

If AI is used to explore options, compare approaches, or clarify trade-offs, and the developer still reasons critically about the result, the struggle relocates.
It does not vanish.

That relocation does not happen automatically.

It requires deliberate supervision.

Not micromanagement.
Not control over every line.

But review that makes reasoning explicit.

Under AI, the role of senior engineers changes.

It becomes less about checking syntax and more about surfacing assumptions, challenging trade-offs, and asking:

“Why is this the right boundary?”
“What invariant are we protecting?”
“What breaks if this evolves?”

AI lowers the cost of generating code.
It does not lower the cost of building intuition.

If anything, it raises the responsibility of seniors to make intuition formation visible.

Chapter 5 — Craft, Effort, and Identity

There is another layer to this shift.

For a long time, craftsmanship in software was closely tied to visible effort.

Whiteboard scars.
Handwritten documentation.
Refactored files.
Long debugging sessions.

Visible struggle became a proxy for depth.

AI disrupts that signal.

Structured documentation can appear quickly.
Clean explanations can emerge without hours of rewriting.
Iteration leaves fewer visible traces.

That can feel suspicious.

If the effort is not obvious, was the thinking real?

I understand that reaction.

For years, effort and depth were tightly coupled in my own mind as well.

When friction becomes cheap, effort is no longer a reliable signal.

Coherence becomes the signal.

Not how long it took.
Not how messy the process looked.
But whether the boundaries hold.
Whether the invariants survive scrutiny.
Whether the reasoning is internally consistent.

That shift can feel uncomfortable.

It moves craftsmanship from visible struggle to structural judgment.

Chapter 6 — Relocating Struggle

What I am describing is not a declaration that AI makes developers better.

It is a shift in where discipline must live.

The struggle must not disappear.
It must relocate.

For experienced developers, that struggle moves upward.
From mechanics to meaning.

For juniors, that relocation does not happen automatically.
It requires guidance.
It requires reviews that surface assumptions.
It requires making intuition formation explicit.

AI lowers the cost of generating code.
It does not lower the cost of engineering judgment.
If anything, it reduces the noise around it.

The tool can amplify clarity.
It can also amplify confusion.

The difference lies in how we engage with it.

Used passively, AI smooths over the very friction that builds depth.
Used deliberately, it exposes weak thinking and forces coherence earlier.

AI did not remove struggle.
It moved it.

The surface changed.
The discipline did not.

Whether that leads to growth or decline
depends less on the tool
and more on our willingness to think precisely.