You paste the stack trace. Claude gives you a fix. It works. You ship it and close the ticket.
Three weeks later a different pipeline throws a different error, and you spend two hours on it before realising it's the same problem you already solved.
This is one of the most common ways AI assistance quietly fails engineers early in their careers, and it doesn't look like failure at any point. Every individual interaction went well. The fix was correct. The ticket closed. The cost lands weeks later, somewhere that looks unrelated.
🔍 The shape of the problem
A fix and a principle are two different things, and only one of them transfers.
Consider a timestamp parsed without timezone information. The symptom is dates landing a day earlier than the source system reports them. Ask for a fix and you'll get one: an explicit UTC conversion at parse time. Correct, minimal, ships clean.
Six weeks later, a different pipeline double-counts a handful of records near midnight. Different symptom, different codebase, no stack trace in common. It takes an afternoon.
Same underlying thing both times. A timestamp with no timezone attached isn't a point in time — it's a string that resembles one, and every system that touches it downstream is free to interpret it differently. The first fix resolved one instance of that. It didn't install the idea.
The version that shows up most often in data work is NULL in a filter:
SELECT * FROM orders WHERE status != 'cancelled'
This silently drops every row where status is NULL. NULL != 'cancelled' doesn't evaluate to true — it evaluates to NULL, and the WHERE clause discards that. The corrected predicate takes seconds to get. But get the fix without the reason, and the same behaviour will find you again in a JOIN condition, a CASE expression, and a NOT IN subquery, and none of them will look like relatives of the first one.
The pattern isn't "I got bad help." The help was good. It was absorbed at the wrong level of abstraction.
Over months this produces a collection of fixes filed by symptom rather than by principle — a collection that can't be searched by the only key that would make it useful.
🧠 Why this hits beginners specifically
This gets misdiagnosed as carelessness, and it isn't.
When an experienced engineer gets a fix, it lands on top of twenty prior fixes. There's already a structure for it to attach to — they've been bitten by timezone handling before, so a new timezone bug files itself under something that already exists. The attachment happens automatically and mostly invisibly. They aren't doing extra work to make it happen.
Earlier in a career, there's no such structure yet. Nothing for the fix to attach to, so it files as a standalone event: the thing that was wrong that Tuesday. Six weeks later there's no category to retrieve it from, because the category was never created.
So a shoebox of unconnected fixes isn't a bad habit. It's what necessarily happens when there's nothing to organise around yet.
What's changed is the thing that used to build that structure by force:
- Before: finding an answer meant an hour in documentation, three wrong turns, and a partial mental model assembled on the way
- Now: the answer arrives in ten seconds and the mental model doesn't
That's not an argument for going back to the slow way. It's an argument for replacing what the slow way was doing for you, deliberately, because it no longer happens for free.
✅ The fix is one sentence
Add this to every fix request:
"Explain why this works, and what would break if the data changed shape."
Two clauses, appended to a prompt you were writing anyway.
The first changes what you get back — you've asked for the mechanism, so you get the mechanism rather than the patch. The second does more work than it looks like it should. Asking what breaks under different data forces the boundary of the solution into view, and the boundary is where the principle usually lives.
"This works as long as every timestamp arrives with an offset" is the principle, stated as a condition.
Then one more step, and this is the one people skip:
📝 Write the principle down in one line
Not a document. Not a wiki page that gets abandoned in a month. One line, in whatever file you already keep open:
2026-06-14 — A timestamp with no timezone is a string, not an instant.
Everything downstream is free to interpret it differently.
2026-06-28 — NULL comparisons return NULL, not false, and filters discard it.
Shows up in WHERE, JOIN, CASE, NOT IN.
Two of those and you have nothing. Twenty and you have the structure that was missing.
The signal it's working is when entries start collapsing into each other — when four things filed separately turn out to be one idea about type coercion. That collapse is the mental model forming, and it can only happen if the entries exist somewhere to be compared.
⚖️ The objection worth taking seriously
The weak version of the pushback is "I don't have time to learn the theory behind every bug, I have tickets." Easy to answer, and not the real argument.
The strong version: understanding-first is a real cost paid now against a benefit that may never arrive. Most bugs genuinely are one-offs. Effort spent extracting principles from problems that never recur is effort you don't get back. Framed that way, skipping it is a rational bet rather than a lapse.
That's substantially correct — and it's exactly why the recommendation here is one sentence and one line rather than "read the documentation properly." At that price the bet changes:
- You're not committing an hour per bug against the chance it repeats
- You're spending about forty seconds, and only on bugs that were already costing you enough to ask about
- Recurring bugs are precisely the population this catches
A one-off you don't understand costs you nothing. A mechanism you don't understand bills you monthly.
🎯 The takeaway
Two things. Forty seconds total.
1. Append this to every fix request:
"Explain why this works, and what would break if the data changed shape."
2. Write the principle in one line, in a file you already have open.
The tool gets you unblocked. It doesn't get you organised, and it won't remember any of this the next time you ask. That part was always going to be yours — it just used to happen as a side effect of being stuck, and now it doesn't.
This is post #1 in a series on AI practice for data engineers — how engineers at every level use AI tools badly, why it happens, and what better practice looks like. Next up: **Confident Is Not Correct — Three Tells That Claude Is Guessing.**
Top comments (0)