This post was machine-translated from Korean with AI.

[vibe-coding]

Before fixing anything, I read it properly first

The call to refactor was the boss's, handed off to me. And once a direction is set, my hands get itchy and I want to start tearing into the code right away.

This time, though, I paused for a beat before that. I decided to first re-check what was actually running, and how, in two files — generator.py and main.py.

By refactoring here I mean the work of leaving behavior untouched and only making the code look cleaner.

Since the outside doesn't change while you swap out the inside, I have to know exactly what the inside looks like before swapping it, or things go wrong.

Reading the whole file is easier — so why didn't I?

Opening a file and reading it top to bottom puts your mind at ease. There's the reassurance of having seen it all.

But that turns out to be a trap. Cram an 800-line file into your head to fix one function, and the range you actually need to fix goes hazy while you start worrying about unrelated code.

This time the goal was clear. In generator.py and main.py, just eyeball the core functions and logic ranges I'd be reusing next — only those parts.

So instead of opening the whole file, I calculated the starting line and length of the range I wanted to see, and read only that much.

It sounds grand, but in practice it's simple. First roughly estimate "which line does this function start at? about how many lines is it?", then pick out and open just that range.

Reading only as much as I need

ApproachHow much you readWhat's left
Open the whole fileEverythingThe range you need, plus a pile of noise
Pick out only the rangeAround the target functionOnly what the current decision needs

Laid out like this it looks obvious, but sit down in front of the code and you keep opening the whole thing anyway. It just feels safer.

But feeling safe and the work actually going well are two different things — something I felt again this time.

One thing I'll leave honest: this session didn't actually reach the refactor. It's the step just before — the prep stage of "reading the current code to decide what to change and how."

So whether this approach also holds up in the actual rewrite, I don't know yet either. There's a real risk of picking out ranges and then missing the connecting point I should have seen.

I'll leave that as something to confirm in the next step.

So what I learned

Don't begrudge the time spent reading before fixing. And even when you do read, picking out "only as much as the current decision needs" scrambles your head less than the habit of "I'm only safe once I've read it all."

Of course, this is a feel I got at the prep stage, so my thinking might change once I finish the actual rewrite. Something I missed by only looking at ranges could jump out.

If I get burned again then, I'll just write another post about it.