AI 不應只幫我寫程式碼

When implementation outpaces your mental model, staying in control isn't about reading more code—it's about working through compressed representations.

The Slipping Baseline

When I started using AI to build software, the beginning usually felt fine.

I understood the problem well enough. I made some design decisions. Then I started implementing. AI just made that part faster.

The problem came later.

As the system grew, one decision created another:

• New dependencies appeared.
• More code accumulated.
• Independent logic turned out to share state or rely on decisions made somewhere else.

My understanding wasn't gone—it was just falling behind.

At first, the gap was small enough that I could catch up: read some code, ask a few questions, get an explanation, and keep moving.

Then the gap widened. Eventually, I wasn't really directing the implementation anymore.

"I was just asking the AI to do the thing."

And that works surprisingly well—until it doesn't.

Keeping Up With Code Isn't the Answer

My first instinct was to brute-force my way back into the details:

• Read more code.
• Ask more questions.
• Slow down.

It didn't work. AI can produce implementation far faster than a human can consume it. If staying in control requires understanding every generated line at generation speed, you've already lost.

What I actually need is a reliable understanding of the system at the level where I'm making decisions.

An architect doesn't stare at every line of code. They understand the boundaries, relationships, behavior, data, constraints, and tradeoffs.

And AI can help clarify those, too.

Compress, Then Expand

If I can't keep up with AI at the implementation level, implementation doesn't need to be the level where I maintain my mental model.

The representation depends on what I'm trying to understand:

Architecture   ───────→   Architecture diagram
Data           ───────→   Schema / ERD
Behavior       ───────→   Tests / scenarios
UI             ───────→   Rendered interface
Performance    ───────→   Metrics
Security       ───────→   Threat model

I saw the difference while working on a system that initially looked trivial: process a spreadsheet through eight business rules and produce a few output files.

As implementation progressed, hidden dependencies emerged between the rules. Eventually, I drew the system:

Eight simple-looking rules
            ↓
      Implementation
            ↓
  Relationships emerge
            ↓
         Diagram
            ↓
Relationships become visible

I hadn't discovered new information. I had changed how the information was represented.

That is what compression means here: not generic summarization, and not simply fewer words. It means preserving what I need to understand while hiding what I don't.

Then, I let AI expand that understanding into implementation—and compress it again when it finishes:

UNDERSTAND
    ↓
COMPRESS
    ↓
AI EXPANDS
    ↓
COMPRESS
    ↓
VERIFY

Directing Instead of Chasing

AI can augment that entire loop.

It can write code faster than I can, and that's fine. I don't need to compete with it on raw generation speed.

I need enough understanding to direct what gets built—and enough visibility to know whether we built the right thing.