There is a specific, dangerous moment in every data-cleaning task where you produce a beautiful, sparkling-clean file and feel, briefly, like a wizard. That feeling is a trap. Because in roughly three weeks the source system will send you another export, it will be just as broken as the first one and possibly more creative about it, and if you cleaned the first export by hand, you now get to do the entire thing over again from increasingly unreliable memory. I have been that person, at 11pm, frantically trying to remember whether I lowercased the emails before or after I deduped them, knowing that the answer changes the result and not knowing the answer.
Cleaning by hand feels productive in the moment because you can see the file getting cleaner under your cursor. But you are building a sandcastle, and the tide is the next export.
The Tuesday the second export arrived
Two weeks after I cleaned our 80,000-row customer migration with the Profile and Clean a Messy CSV with Reproducible pandas Code prompt, the legacy system did precisely what legacy systems are contractually obligated to do: it coughed up a fresh export with about 6,000 new and updated rows, in the same six phone-number formats as before, plus two brand-new corruption patterns it had apparently been saving for a special occasion. The old me would have lost a full Tuesday to it and emerged blinking and resentful. The current me ran one command, watched the before/after summary scroll past, and went to lunch with actual coworkers.
Why the structure made it boring, in the best way
Because GPT 5.2 had written the cleaning as fourteen separate, commented functions rather than one impenetrable chained blob, adapting to the two new corruption patterns meant editing exactly two functions and adding one new one. I did not have to re-read or re-understand the whole script; I went to the function whose name described the problem, changed it, and left everything else alone. The before/after logging immediately told me the new export had also introduced a sneaky column of stray leading whitespace that I would never, ever have spotted by eye scrolling through 6,000 rows. Boring is the entire goal in data engineering. Boring means reproducible. Reproducible means I actually trust the output instead of just hoping.
- Re-ran the existing script on the brand-new export in under a minute, with zero hand-editing of any actual data values.
- Added one new function for a corruption pattern that simply did not exist in the first batch, in about ten focused minutes.
- The row-removal log gave me an instant, auditable diff: this export dropped 11 rows, and here is the exact categorized reason each one went.
- Idempotency meant I could nervously re-run the script three times before the real import and get byte-identical output every single time, which is the only thing that lets me sleep before a migration.
The mindset shift that took two exports to land
My first write-up of this prompt was about cleaning 47 columns of nightmare data in a single afternoon, and that story is completely true and genuinely great. But the deeper lesson needed the second export to actually click: the value was never the cleaned file itself. The cleaned file is disposable. The real value was the repeatable script, the logged decisions, and the TODO stubs that documented every judgment call I made — so that future-me, or a teammate who inherits this when I am on vacation, can understand WHY the data looks the way it does and re-derive it from the raw source at will. A clean file is a snapshot that goes stale the instant the source changes. A clean, documented script is a durable asset that keeps producing clean files forever.
There is also a quieter benefit I only noticed after the third export: onboarding a teammate to this dataset went from a two-hour walkthrough to handing them the script. Every cleaning decision is a named, commented function, and every judgment call is a TODO stub explaining what the human chose and why. A new analyst can read the script top to bottom and understand the full shape of our data's history without me narrating it. The documentation is the code, and the code stays true because it actually runs. Hand-cleaned files have no such memory — the knowledge lives only in the head of whoever cleaned them last, and that person always eventually leaves.
If you find yourself cleaning the same shape of file more than once, stop cleaning files and start generating scripts. Grab the Profile and Clean a Messy CSV with Reproducible pandas Code prompt on Prompt Dock, and when the inevitable second export lands on a random Tuesday, you will rerun a command instead of reliving the whole ordeal. Pair it with my Build a Data Quality Test Suite for a Table prompt and you will even get a loud, specific alert the moment the next export breaks one of your assumptions — before the bad data ever reaches your warehouse and your dashboards.