실행하기 전에 출력을 예측하는 것은 내가 처음부터 작성할 수 없는 스크립트가 실제 작업을 자동화하게 된 방법입니다.

I burned through the vibe-coding phase fast. Anything past a basic webpage needs real software fundamentals — no amount of prompting substitutes for that. What I've settled into instead is slower: learning AI and Python theory properly, alongside actual software-dev practice, in a loop that's started paying off.

I can't write Python from a blank file yet. That's not the point of the workflow.

This week I built a script I'm now using, on two Macs, against real data: it searches CSV files of accounts, finds someone by name or login, and safely updates their password. It backs itself up before touching anything, handles a batch job's leftover error rows without crashing, and replaced a manual find-and-edit process I used to do by hand.

None of that came from me typing code. It came from a loop:

1. Specify: describe exactly what I want, before any code exists.
2. Generate: the code gets written.
3. Predict: before running it, say out loud what I think will happen.
4. Run and compare: the gap between prediction and result is the lesson.

First time through, my prediction for a print statement was something like "o row laura row gus*** login: LOG***...", half-guessed and missing a lot of syntax in the details. That mismatch taught me how an f-string assembles a line.

Reading code instead of just generating it

AI is teaching me to read code, not just accept it. A check flagged any password starting with "Error" as a failed reset. I asked: what if a real password starts with "Error," like Error99!? That's the kind of question the loop trains you to ask. We fixed it to match the actual error phrase instead.

Same instinct applied to trusting the output itself. I learned diff isn't a one-off trick: it's how you check whether two versions of a file differ, line by line, instead of eyeballing them. And I learned why the backup mattered in the first place. Editing a CSV in Python doesn't touch one cell in place; it reads the whole file into memory, changes the one value, and rewrites the entire file from scratch. If that write fails partway through, the backup is the only thing standing between you and a corrupted file. Before this touched real data, I diffed the backup against the freshly written version. One line differed: a missing newline, unrelated to any data. I checked it myself rather than taking "it's fine" as an answer.

What works for me

Understand exactly what a script does. Build it in small, checked steps. Explain it back (Feynman style) before moving on. That loop is slower than vibe coding. It's also the reason I trust what I shipped.

The loop is slower than pointing an agent at a repo and walking away. But slow is where the backup got tested, where the Error99! edge case got caught, where the diff got read instead of trusted on faith. I didn't write this script. I can account for every line in it, and right now that's the trade I'm making.

If you've built something with a similar predict-then-check habit, I'd like to hear your experience.

For further actions, you may consider blocking this person and/or reporting abuse