DEV Community: raghav sharma

The Mentoring Conversation You Replaced With a Chat Window

raghav sharma — Wed, 19 Aug 2026 09:00:00 +0000

A junior asks why the partition key matters.

You know the answer. You also have four other things open, so you paste them a clear explanation from a chat window and go back to what you were doing.

The explanation is good. It is probably better written than what you would have said out loud. The junior reads it, says thanks, and moves on.

Something did not happen, though, and it will be about a year before anyone notices.

🔍 What the forward leaves out

Here is roughly what you would have said if you had spent the five minutes.

You would have started with the query patterns, because the partition key is not a property of the table, it is a bet about how the table gets read. Then you would have mentioned the time we partitioned by customer ID and produced two million tiny files, and what that did to the metadata layer, and how long it took to find. Then you would probably have asked them what they thought the query pattern was going to be in a year, and let them be wrong about it, and then talked about why.

The pasted explanation contains the first part. It cannot contain the second, because it does not know about the incident. And it cannot contain the third at all, because the third is not information. It is the junior thinking, badly, in front of someone who can see where the thinking goes wrong.

That third part is the whole thing. The answer to the question was never the point.

🧠 Why this lands on seniors

Two reasons, and the second is the uncomfortable one.

You are the only person who can make this trade. Nobody else on the team is being asked the question. The junior cannot choose to be mentored by someone who is not there.

And you are the only person who pays for it, twelve months out. This is what makes it different from most decisions about your own time. Skipping a code review costs you today. Skipping this costs you next year, when you need someone to own a system and find that nobody on the team can reason about it without help.

There is evidence this is happening broadly and not just to you. A study by researchers at UC Berkeley and Yale, published in Harvard Business Review in early 2026, tracked 200 employees at a technology company over eight months. One of its findings was direct: rather than mentoring juniors, senior engineers were spending hours reviewing and fixing AI-generated code. The mentoring time did not disappear into leisure. It went into review.

A paper in Communications of the ACM the same month described the mechanism from the junior's side. They meet a problem beyond their current ability. A working solution arrives in seconds. They ship it, the review passes, the ticket closes, and the mental model that the difficulty was going to build never gets built. Everything about that sequence looks like success.

✅ Prepare with it, do not send it

The rule is small, because a rule that costs 20% of your week will not survive contact with your actual week. Research on mentoring load puts a junior at roughly 20 to 30% of a senior's time in the early months, and I am not going to pretend this fits in that budget. It is smaller than that on purpose.

When a question comes in that has a reasoning answer rather than a factual one, do not forward. Take five minutes.

Use the chat window to prepare, not to reply. Ask it to lay out the tradeoffs so you have them straight, especially if the area is one you know by instinct rather than by explanation. That is a genuinely good use, and it takes thirty seconds.

Then run the five minutes like this:

Ask before you answer. "What do you think happens if we partition by customer ID?" Let them answer. If they are wrong, that is the useful part, and you have now found the actual gap rather than the one they asked about.

Give one thing that is not in any documentation. The incident. The migration that went badly. The reason your team does it differently from the way the internet does it. This is the part no tool has, because it is not written down anywhere.

Stop. Five minutes. You are not running a class.

The test for whether a question needs this: could a correct answer still leave them unable to make the same decision themselves next time? If yes, it is a conversation. If it is "what is the syntax for a window frame," forward it and think nothing of it.

⚖️ The objection worth taking seriously

The weak version is "I am their lead, not their tutor, and they can read." Answerable in one line, so it is not the real argument.

Here is the real one. On-demand explanation is unlimited, instant, patient, and free of social cost. Senior mentoring is scarce, inconsistent, badly delivered about half the time, and requires a junior to admit ignorance to the person who writes their review. For a junior who is remote, or in a different timezone, or simply not confident, the chat window may be far better access to explanation than they would ever have got from you.

I think that is largely correct, and it is worth conceding fully rather than partly. Measured as access to explanation, this is a clear improvement over what most juniors had before, and the people it helps most are the ones who were least likely to ask.

The concession has a limit, though, and the limit is what explanation is. Explaining is answering the question that was asked. What the five minutes does is different: it finds the question they did not know to ask, supplies the history that is not written down anywhere, and lets them be wrong in front of someone who can see why. Judgment gets built by watching decisions get made and seeing the results turn up later. That is not a thing that can be retrieved, because it is not information.

So the honest position is not that the chat window is worse. It is that it is better at one of these two things and cannot do the other at all, and the one it cannot do is the one that turns a junior into someone you can hand a system to.

There is also a signal worth watching. A 2026 survey found 56% of HR leaders reporting that early-career hires turn to unofficial AI tools when guidance is unclear. If the guidance is not there, the chat window fills the space, and it fills it with answers rather than judgment.

🎯 The takeaway

Prepare with it. Do not send it.

1. Sort the reasoning questions from the factual ones. Test: could a correct answer still leave them unable to decide this themselves next time?

2. For reasoning questions, take five minutes. Use the chat window to get your own thinking straight first. That part is fine and fast.

3. Ask before you answer. Their wrong answer tells you where the actual gap is.

4. Give one thing that is not written down anywhere. The incident. The reason your team does it differently.

The pasted explanation answers the question. The five minutes is what makes the question stop being asked.

The Fix That Works in the Tutorial and Not in Your Stack

raghav sharma — Mon, 17 Aug 2026 09:00:00 +0000

You paste the error. You get a pandas answer. You are running PySpark.

Nothing about the response was wrong. It was correct, well explained, and solved a problem you do not have. You spend twenty minutes finding that out, and the twenty minutes feel like your fault.

They are not your fault, exactly. But they are avoidable, and the fix takes four lines.

🔍 What actually happened

When you paste a bare error message, a lot of information is missing. Which engine you are on. Which version. Whether this runs in a notebook, an orchestrator, or a scheduled job. What the data looks like.

An answer still has to be produced, so the gaps get filled with the most common case. Most Python data questions on the internet are pandas questions, so you get a pandas answer. Most SQL questions are Postgres questions, so you get Postgres syntax that Redshift will reject.

Research on this failure describes it precisely: models pick functions that do a similar job but belong to a different situation. The result is correct as code and wrong for your system.

There is a version of this that is harder to catch. Ask about a library you really do use, and you can get a function that existed two releases ago. Studies of deprecated API use in generated code found that models suggest outdated functions without saying which version they are assuming. One analysis of agent-written pull requests found that 75% specified a version and described this as better than ordinary chat usage, where versions are rarely mentioned at all.

The reason this one is worse: deprecation warnings are usually soft. Code using a deprecated function often keeps working for a release or two, so it passes your tests, gets merged, and fails months later during an upgrade.

And at the far end, roughly one in five packages suggested by language models does not exist anywhere. There is now an attack built on this. People watch for package names that models invent regularly, then publish real malicious packages under those names. So a made-up import is not always an import error. Sometimes it installs.

🧠 Why this hits beginners specifically

The obvious answer is that beginners do not include their setup. True, but that is a description, not a reason.

The reason is that you cannot tell which parts of your setup matter until you have been caught out by them. An experienced engineer mentions the engine automatically because they lost an afternoon to a Postgres answer in a Redshift warehouse. They are not being thorough. They are avoiding a specific memory.

Without that memory, everything about your setup looks equally relevant, which means it all looks equally skippable. You are not omitting the two facts that mattered. You are omitting all twelve, and two of them happened to matter.

There is a second reason, and it is about what you can check. A senior looks at an unfamiliar function and something feels wrong, because they have a rough sense of what exists in their engine. Earlier in your career there is no sense to compare against, so a made-up function and a real one look identical until you run them.

✅ Four lines, pasted every time

Put this above the error, every time:

Engine: Spark 3.5 on Databricks
Runs as: scheduled job, orchestrated by Airflow
Data: ~40M rows/day, JSON from a third-party API, schema changes without notice
Constraint: cannot add new cluster libraries

Four lines. Notice what they are doing.

Engine and version is the one that stops pandas answers reaching PySpark problems, and the one that catches deprecated functions. State the version, not just the tool. "Spark" and "Spark 3.5" are different questions.

Where it runs changes the answer more than people expect. A fix that is fine in a notebook may be wrong in a scheduled job, because a notebook has you sitting in front of it and a job at 2am does not.

What the data looks like matters more than what type it is. Research on test generation found that describing how something behaves improved results substantially more than describing how it is built. "JSON that changes shape without warning" is more useful than "JSON."

One hard constraint, if you have one. This is the line that stops you receiving an answer you cannot use.

This is not the same thing as stating your row counts and latency budget. That matters too, and it is a different problem for a different post. This block is about what your system is. That block is about how much it has to handle.

⚖️ The objection worth taking seriously

The weak version is "surely it can work out the stack from the error." Sometimes yes, and when it cannot, it will not tell you. It will answer confidently for the stack it assumed.

The stronger objection is about the habit itself. A block you paste every time is a block you stop reading, and a stale block is worse than no block at all. If you move to Spark 4 and your saved snippet still says 3.5, you have not just failed to help. You have actively misled, with your own credibility behind the wrong information. Every answer will now be confidently wrong about your environment for a reason you supplied.

I think that is right, and it is the reason for keeping this to four lines. Four lines can be re-read in three seconds. A twenty-line template cannot, so it becomes furniture, and furniture goes stale.

Two habits follow from that. Re-read the block before sending, every time, which four lines makes possible. And treat any change to your environment as a change to the block, in the same commit if you can.

There is one more thing worth being honest about. This block reduces a class of failure. It does not remove it. A study in 2025 found the newest models hallucinating in up to 20% of tasks, some of them with more context rather than less. So verify unfamiliar functions against your own documentation whatever your prompt looked like.

🎯 The takeaway

Four lines, above every question:

1. Engine and version. The version, not just the name.
2. Where it runs. Notebook, scheduled job, or something with a person watching.
3. What the data does. How it behaves, not just its type.
4. One hard constraint. If there is one.

Re-read them before you send. That is why there are only four.

The answer you got was not wrong. It was right about a system that is not yours, and nothing in it told you which one it had in mind.

The AI Usability Framework: Why Your Team Uses Claude Five Different Ways

raghav sharma — Sat, 15 Aug 2026 09:00:00 +0000

Three engineers on the same team, using the same tool on the same codebase, get into trouble in three completely different ways.

The junior ships something that works and cannot explain why. The mid-level engineer describes the problem accurately, leaves out the row count, and gets an elegant query that dies in production. The lead asks for an architecture recommendation and receives one their team has no chance of building.

None of them used the tool badly. They used it differently, and the differences follow a pattern.

🔍 Five things that change

Across the posts in this series, the same five differences keep appearing. Together they explain more about how an AI interaction turns out than which model you used.

1. What you are using it for. Learning, going faster, or thinking through a decision. A study of AI-assisted work found that novices and intermediates use an assistant mainly as a learning resource when they are unsure, while experts use it as a check on something they already believe. Earlier research found the same split in programming: experienced developers speed up familiar work, while novices explore.

2. How you ask. A short direct question, a question loaded with constraints, or a decision broken across several turns. This one has the strongest evidence attached to it. In a study of 218 developer conversations taken from real pull requests, adding context roughly doubled the odds of getting usable code back, and specificity had a larger effect still.

3. What you do with the answer. Accept it, question it, or check it against your own knowledge of the system. The same study of experts and novices found experts were much more likely to spot and ignore a made-up answer, while non-experts often did not.

4. How much it touches. One line, one component, or the shape of a whole system. A 2026 study found that less experienced developers using AI generate more code and push the checking work onto reviewers, and concluded that a team cannot swap experienced engineers for them without adding review capacity.

5. What goes wrong. This is the useful one, and it is the point of the whole framework, so it gets its own section.

🧠 The failure mode is the thing worth knowing

Each of the first four dimensions produces a different characteristic failure, and once you know which one is yours, you can watch for it.

If you are using it to learn, your failure is collecting fixes without principles. You get an answer, it works, and six weeks later the same problem arrives wearing different clothes and you do not recognise it.

If you are using it to go faster, your failure is under-specifying. You describe the problem correctly and leave out the physical facts, so you get an answer that is right for a problem you do not have.

If you are using it to think through decisions, your failure is organisational. You supply every technical constraint and none of the human ones, so you get architecture that is sound and unbuildable by the people you actually have.

If you accept output as-is, your failure is confident nonsense. Made-up functions, wrong-engine answers, numbers with no source.

If you check output against expertise, your failure is habituation. Your scrutiny quietly decays over months of reviews that were mostly fine, and nothing tells you it is happening.

That last one is why this matters for people who already know what they are doing. Being good at this does not remove the failure mode. It changes which one you have.

✅ How to use this

Take one week of your own AI conversations and mark each one on the five dimensions. Not from memory. Open them and look.

You will usually find you are operating at a different point than you assume, and almost always in a specific direction: more like a beginner than your job title suggests, on the dimensions where the work is unfamiliar. A senior data engineer moving into streaming for the first time behaves like a beginner in that area, with the beginner's failure mode, while continuing to feel like a senior.

That is the practical value. The framework does not tell you how good you are. It tells you which mistake you are set up to make right now, on this piece of work.

There is one finding that sits underneath all of it and is worth stating plainly. A study of 60 developers found that correctness related to how much AI output they accepted in a curved rather than straight line, and it peaked in the middle. Near-total acceptance did badly. Near-total avoidance also did badly. Balanced engagement beat both.

That is the whole argument of this series, measured. The question was never whether to use these tools. It is where on that curve you are sitting, and none of the five dimensions tells you unless you look.

⚖️ The objection worth taking seriously

The weak version is that frameworks are usually common sense with labels attached. Sometimes true, and the test is whether it predicts anything.

The strong version is more uncomfortable, and I found it in the research I have been citing. The level differences come from separate studies of separate populations, not from one study that compared beginners, intermediates and seniors directly. A 2026 review of this literature says plainly that no study compared AI assistant use across groups even within software engineering. Another notes the same problem: the findings are drawn from work targeting distinct populations rather than designs that compare them.

So the neat progression from beginner to senior might be an artifact of putting incomparable studies next to each other. That is a real risk and I cannot rule it out.

What I can offer is a test. The framework claims that failure modes shift by level in a specific order, and that a senior working in an unfamiliar area shows the beginner failure mode rather than the senior one. That is checkable on your own team. If your seniors and juniors fail in the same way, or if the failure tracks the person rather than the situation, the framework is wrong and you should throw it out.

I would rather give you something you can disprove than something that explains everything after the fact.

🎯 The takeaway

The five dimensions:

1. Purpose. Learning, speed, or deciding.
2. How you ask. Bare, constrained, or decomposed.
3. What you do with the answer. Accept, question, or verify.
4. Scope. A line, a component, or a system.
5. Failure mode. Determined by the four above.

Mark one week of your own conversations against these. The point is not to score yourself. It is to find the dimension where you are working outside what you actually know, because that is where the next mistake is coming from.

Every other post in this series is one cell of this table, examined closely.

The First Answer Is a Starting Position, Not a Verdict

raghav sharma — Thu, 13 Aug 2026 09:00:00 +0000

You read the response and decide it is about 80% right. So you fix the last 20% yourself, ship it, and move on.

That is a reasonable way to work. It is also the point where two very different second moves are available, and most people never notice there was a choice.

🔍 The two second moves

Say you asked for a retry policy for a pipeline step. What came back retries three times on any failure, with no backoff.

You can see two problems. There is no exponential backoff, so a struggling downstream service gets hit three times in quick succession. And it retries on every error type, including the ones that will never succeed on a retry, such as a malformed record.

Move one, the patch. You add backoff yourself and filter the error types. Fifteen minutes. It works.

Move two, the follow-up. You say what is wrong and ask again.

Most people take move one, and the reason is not laziness. Patching feels like ownership. You read the code, you found the problems, you fixed them. That is what an engineer does. Asking again feels like handing back a piece of work you already understand.

But your patch fixed the two problems you spotted. It did not touch the third one, which is that a retry on a partially written record can produce duplicates, because the step is not idempotent. You did not miss that through carelessness. You were checking the retry logic, and idempotency is a different question.

🧠 Why this lands on intermediates

Beginners do not usually reach the 80% judgment. They accept or they get stuck.

Seniors have usually been through the version of this where their own patch was the thing that broke, so asking again is already a habit.

Intermediates are at the exact point where the judgment to spot problems has arrived, and the habit of using it well has not. You now have enough skill to improve the answer yourself, so you do, every time. The skill that arrived first is the one that gets used.

There is a second reason, and it is about the shape of the work. Intermediates are usually building components rather than single queries. A component has more surface area than you can check in one read, so the gap between "the problems I found" and "the problems that exist" is wider than it was earlier in your career, at exactly the moment you have started trusting your own read.

✅ Take the second turn, but restate rather than append

Here is where the common advice is wrong, and where the research is genuinely useful.

The obvious way to take a second turn is to append. You say "add exponential backoff and only retry transient errors" and send it. This is what almost everyone does, and it is the weaker option.

A large study presented at ICLR in 2026 tested 15 models across more than 200,000 simulated conversations and found that performance dropped by an average of 39% when a task was spread across turns rather than stated once. The mechanism is specific and worth knowing. Models commit to assumptions early, produce a solution before they have enough information, and then hold on to that solution. As the paper puts it, once a model takes a wrong turn, it does not recover. It layers corrections on top of the mistake instead of starting again. The study also found that middle turns get very little attention, and that larger models were no better at avoiding any of this.

So appending sits directly on the failure mode. You are asking the model to fix an answer it is already committed to, and it will patch rather than reconsider, which is exactly the thing you were trying to avoid doing yourself.

Restating works differently. Instead of "add backoff," you send the whole problem again with the correction included:

Retry policy for a pipeline step calling a third-party API. Around 40,000 calls per run. Needs exponential backoff. Only retry transient errors, not malformed records. The step writes partial records, so retries must be safe to repeat. What breaks?

That is one turn, fully specified, with what you learned from the first answer folded in. The study's own suggested mitigation is the same idea: consolidate the context before asking again, rather than relying on the conversation history.

The first answer was not a deliverable. It was a way of finding out what you had failed to specify.

⚖️ The objection worth taking seriously

The weak version is "sometimes the first answer is genuinely fine." True, and it costs one turn to find out.

The strong version comes from the same research I just used: multi-turn measurably makes things worse, by 39% on average. If a second turn degrades quality, the honest advice is to ask better once and stop.

I think that is largely right, and it is why the recommendation here is not "iterate more." The study measured conversations where requirements arrived piece by piece, and that is a real description of how most people use these tools. If your second turn is "no, add backoff," you are inside the pattern the study measured, and you should expect the result to get worse rather than better.

The evidence for iteration helping is narrower and has conditions attached. One study found that conversations with human feedback improved results by roughly 16 to 18 percentage points over single-shot prompting. Another found multi-turn prompting produced better fault detection, at 187% more compute. Both involved a person supplying real information the model did not have, rather than nudging it toward a fix.

So the honest version of this advice is conditional. Take a second turn when the first answer taught you something you had not specified. Restate the whole problem rather than appending to it. If you are only nudging, ask better once and take the single-turn answer instead.

🎯 The takeaway

The second turn is worth taking only if you restate.

1. Treat the first answer as a specification test. What it got wrong tells you what you failed to say.

2. Restate the whole problem with that correction included. Do not append "also add backoff" to a conversation. Send the full thing again.

3. If you have nothing new to add, stop. Nudging a committed answer makes it worse, and the research is clear about that.

Your patch fixes the problems you found. A restated question finds the ones you did not.

You Review AI Code Less Carefully Than Human Code. That Is Backwards.

raghav sharma — Tue, 11 Aug 2026 09:00:00 +0000

Two pull requests land. A colleague wrote one by hand, and you read every line. The other came out of an AI tool, and it looks clean, consistent, and idiomatic. You scan it, leave no comments, and approve.

If you had done that on your first week of reviewing AI code, you would not have. You were careful then. Something changed in between, and it did not change because you decided it should.

🔍 What the data actually shows

Start with the part that goes against the common complaint. Reviewers are not casually waving AI code through from the start. Measured across large samples, the opposite happens. One benchmark covering 8.1 million pull requests from 4,800 teams found AI-generated pull requests were accepted at 32.7%, against 84.4% for human-written ones. Another study found senior engineers spent about 4.3 minutes on an AI suggestion against 1.2 minutes on human-written code. Reviewers also go back and forth about 12% more on AI code.

So the first instinct is right. People do treat this code as suspect.

The problem is what happens to that instinct over time.

A study tracked 400 reviewers who each reviewed repeatedly over seven months, covering more than 11,000 reviews. It compared each reviewer's early reviews with their later ones. Approval rates for AI agent pull requests rose from 30.1% to 36.8%. Over the same period, the same reviewers became more critical of human-written pull requests, not less. The change was not explained by the pull requests getting easier, and it held after accounting for the calendar date.

Two numbers from that study matter more than the approval rate. Review latency went up by three and a half times. Inline comments went down by 22%.

Read those together. Reviewers spent longer with AI pull requests and inspected them less. The time went into the queue. It did not go into the code.

That is habituation, and it is a well-known effect. Repeated exposure to something that usually turns out fine gradually lowers the attention you give it. Nobody makes a decision to care less. Attention just quietly reallocates.

🧠 Why this lands on seniors first

The study measured repeat reviewers, and that is the group this happens to. If habituation comes from repeated exposure, then whoever reviews the most habituates first.

On most teams, that is you.

There is a second reason, and it is about consequence rather than exposure. When a junior's attention drifts on a review, a senior often catches it downstream. When a senior's attention drifts, nothing catches it. You are the last check, and you are also the person whose review behaviour sets what the rest of the team thinks normal looks like.

The failures that get through are the kind you would expect from code nobody thought about carefully. A transformation that is correct today and that nobody on the team could safely modify in six months. Aggregation logic that runs clean and returns numbers that are quietly wrong, which a business user finds weeks later.

Neither of those is caught by reading faster. Both are caught by reading differently.

✅ Raise the bar, and measure the right thing

Two changes. The first is a rule, the second is what tells you whether the rule is working.

Require the author to state what they verified themselves. Not "AI wrote this." Something specific: which parts they ran, which assumptions they checked, what they did not check. This does two things. It puts the burden back on the person submitting, and it tells you where to spend your attention. A pull request that says "I verified the join keys but not the null handling" has told you where to look.

Review for maintainability, not only correctness. Ask one question of every AI-assisted change: could someone else modify this in six months without the original context? Generated code tends to drift toward generic patterns rather than your team's, and toward default error handling rather than yours. Each of those choices is individually defensible and collectively produces a codebase your team does not recognise. One study across more than 800 GitHub projects found static analysis warnings rose about 30% after AI adoption, with complexity rising over 40%.

Now the measurement. Do not track how long reviews take. That number goes up while attention goes down, which is exactly the trap. Track inline comments per pull request, and watch it over months.

If your comment count on AI-assisted pull requests is falling while the volume rises, that is habituation, and you can see it in the numbers before you can feel it in yourself. That is the whole value of measuring it.

⚖️ The objection worth taking seriously

The weak version is "this will slow us down." Easy to answer.

The strong version is an allocation problem: review capacity is fixed. Raising the bar on AI pull requests means lowering it somewhere else, and you have not said where. Nobody is given extra hours because the review policy changed. In practice, stricter AI review means slower human pull requests, or fewer design discussions, or a senior who stops writing code.

That objection is correct and the honest answer concedes most of it. There is no version of this where the time comes from nowhere.

What I would say is that the allocation already moved, without anyone choosing it. One report found AI-generated pull requests wait 4.6 times longer than human ones just to be picked up. Review is already the constraint on most teams. The question is not whether to spend more attention on AI code, because you already are. The question is whether that attention lands on the code or evaporates in the queue.

There is also a finding that should unsettle everyone, on both sides of this argument. In a controlled study, experienced developers using AI tools were about 19% slower, while believing they had been 20% faster. If your sense of how fast the team is moving is that unreliable, then "this will slow us down" is a claim to measure rather than to assume.

One caution on all these numbers. Several come from companies that sell code review tools, and their figures are not neutral. The habituation study and the developer speed study are independent, and those are the two the argument actually rests on.

🎯 The takeaway

An AI-assisted pull request checklist:

1. The author states what they verified themselves. Specifically, including what they did not check.

2. Ask the six-month question. Could someone else modify this without the original context?

3. Track inline comments per pull request, not review time. Time goes up while attention goes down. Comments are the honest signal.

You did not decide to read AI code less carefully. That is what makes it worth measuring, because you will not notice it happening.

Using AI Without Deskilling

raghav sharma — Mon, 10 Aug 2026 06:00:00 +0000

The worry is not that AI makes you lazy.

It is that AI removes the difficulties that were building the skills you are paid for. You do not notice, because the work still ships. Your output stays the same. What is underneath it does not.

Every other post in this series points at this one. It is also the post where the evidence is strongest, and where the honest answer is more complicated than "keep struggling."

🔍 What is actually being lost

Learning research has a well-established finding that explains the whole problem. It is called desirable difficulties.

Robert and Elizabeth Bjork named it in 1994. The result is the opposite of what most people expect. Conditions that slow you down while you are learning often lead to better long-term memory and better transfer to new situations. Conditions that make learning feel smooth tend to lead to worse memory. Learning that feels easy now usually means weaker recall later.

The reason is that recalling something with effort strengthens the memory more than recalling it easily does. When you struggle to work something out and then get there, the working out is the part that teaches you. When the answer is handed to you, you never work anything out.

So the useful question about any tool is not whether it makes work faster. It is whether the difficulty the tool removed was also teaching you something.

Debugging was. You formed a guess, you were wrong, you found out why, and you made a better guess. Nobody designed that as training. It happened because the work was hard.

Reading documentation was. You went in for one answer and came out understanding more of the system, because finding the answer you needed meant reading past four you did not need.

Both of those still happen when you use these tools. They just happen much less often, and you cannot see the difference, because the output looks the same.

🧠 This is structural, not a discipline problem

Any tool that removes friction also removes whatever that friction was teaching. That is not a complaint about tools, or about the people who use them. It is just how tools work.

The reason it is easy to miss comes from a second finding in the same research: doing something well today and learning it properly are different things, and we mix them up constantly. How well you perform today is visible. Whether the skill will still be there in two years is not. So a change that improves the first while damaging the second looks like a straight win, both to you and to your manager.

That is why this is not only a junior problem, and why nobody's discipline is the issue. Everyone's short-term output goes up. Nothing tells you that anything else has changed.

📊 How this appears at each level

The mechanism is the same everywhere. What differs is where the damage lands.

Beginner. The skill never forms at all. There is no earlier version of you to fall back on, so nothing decayed. The skill was simply never built, which is harder to notice because there is no "before" to compare with.

Intermediate. Your existing skills stay flat while your output rises. That feels fine, and mostly it is, until you compare yourself with someone who kept practising on purpose. The gap opens slowly, and it shows up on unfamiliar problems rather than routine ones.

Senior. Your own skill is mostly intact, because you built it earlier. Your team is losing theirs, quietly, and you are the person answerable for what they can do in eighteen months. You will not see it in delivery metrics.

✅ Work out what was doing the teaching

The advice is not "use AI less." It is more specific than that, and the research explains why the specifics matter.

Bjork warns against the obvious misreading: making something harder is not automatically useful. Some difficulties teach you something. Others are just annoying. A badly documented internal tool creates a huge amount of friction and teaches you nothing except how to get around that one tool. Removing that friction costs you nothing.

So the job is to separate the two.

Step one: list what became easier. Not in general. In your own week. Writing boilerplate. Remembering syntax. Finding the cause of an error. Choosing between two designs. Reading unfamiliar code.

Step two: for each item, ask what it was teaching you. Boilerplate taught you nothing, so let it go completely. Remembering syntax taught you very little. Finding the cause of an error taught you a lot. Choosing between designs taught you the most.

Step three: keep two or three of them on purpose. Not all of them. Two or three, with a small fixed time limit, chosen because they were teaching you something you will need later.

One condition matters more than the rest. The research finds the benefit only holds when the effort ends in getting the answer. Struggling and never getting there teaches you nothing. So whatever you keep, finish the loop: try it unassisted, then check the answer, then compare the two. The comparison is where you actually learn something.

That is the whole method. Three steps: name what became easier, ask what it was teaching you, and keep two or three of them with a timer and a check at the end.

⚖️ The objection worth taking seriously

Here is the strongest version:

Every generation of tools caused this same worry, and it was overblown every time. Compilers, garbage collection, ORMs, Stack Overflow. Each one was going to produce engineers who did not understand their systems. Each one produced engineers who worked on more interesting problems instead. Why is this different?

I think this objection is largely right. This case probably is not entirely different, and some of what I have written above will look overcautious in ten years. More importantly, you cannot tell from the inside which case you are in. Every generation that worried was sure its case was the real one, and most of them were wrong. I have no special view that lets me say this time is the exception, and neither does anyone else who says so confidently.

What I can offer instead is a test you can apply later. The earlier tools removed work but left the learning loop alone. A compiler wrote your assembly, and you still thought about the program, still guessed why it was slow, and still found out when you were wrong. The loop survived.

This tool can remove the loop itself, because it can give you the guess as well as the code. That is the specific difference worth watching. If the loop turns out to come back somewhere else, further up, then this was the usual worry and it was overblown again. That would be a good outcome, and I would be happy to be wrong about it.

The precaution costs a few hours a month. That seems worth it either way.

🎯 The takeaway

Three steps:

1. List what became easier this month. Specifically, in your own work.

2. For each item, ask what it was teaching you. Boilerplate taught you nothing. Working out the cause of a problem taught you a lot. Be honest about which is which.

3. Keep two or three of them. Small time limit. Always check your answer at the end.

Not all friction is worth keeping. But not all friction is waste either, and the whole skill is telling the two apart.

The Debugging Intuition That Never Developed

raghav sharma — Thu, 06 Aug 2026 09:00:00 +0000

Three years in. Competent, shipping, well-regarded by the team.

Then the AI tool was unavailable for a day, and a pipeline timeout that should have been routine turned into most of an afternoon. Not because the problem was hard. Because the approach to it was never built.

This is worth taking seriously and worth being careful about, because it is easy to turn into a moral complaint about people who use tools. It isn't that. It's a specific claim about how a specific skill forms, and what happens when the conditions that form it stop occurring.

🔍 What debugging intuition actually is

When an experienced engineer looks at an intermittent pipeline timeout, they don't start from nothing. They start from a ranked list: what usually causes this, what's changed recently, what would explain the intermittency specifically rather than a constant failure.

That list isn't knowledge in the sense of facts they could recite. It's compressed experience. It came from having been wrong about this class of problem enough times that the wrong answers got pruned.

The same thing applies to a silent data quality failure, which is a harder case: no error, no alert, wrong numbers found weeks later by someone in finance. There's no stack trace to paste. The starting question is "where could this have gone wrong without anything complaining," and that question only has a useful answer if you've built a mental model of where your systems fail quietly.

Neither of these is knowledge you can look up. Both are built the same way, and the way they're built matters for what follows.

🧠 Why this is about cohort, not seniority

Research on deliberate practice is consistent on the core mechanism: skills develop through repeated performance with feedback, targeted at things you're currently bad at. Struggle alone doesn't do it, and comfortable repetition doesn't either. You need the attempt, the outcome, and the correction.

Debugging used to supply all three whether you wanted them or not. You formed a hypothesis, you were wrong, you found out you were wrong, you formed a better one. Nobody designed that as a training programme. It was just what debugging was.

An engineer who worked that way for five years before these tools existed has the resulting instinct, and now uses AI on top of it. The tool makes them faster at something they can already do.

An engineer whose entire career has been AI-assisted may not have had those cycles. Not through any choice, and not through working less hard. The hypothesis-and-correction loop simply didn't occur, because the answer arrived before the hypothesis was needed.

That's why this is a cohort effect rather than a seniority one. It doesn't track years on a CV. It tracks how many times you were wrong about something and had to find out why.

Worth noting: the productivity research points the same direction. In a controlled study, developers using Copilot completed a task around 56% faster, with larger gains for less experienced participants. The people helped most are the people whose skills are still forming. That's genuinely good, and it's also exactly where the loop matters most.

✅ The unassisted-first window

The recommendation is small and deliberately limited.

Pick one non-urgent bug per week. Spend a fixed amount of time on it unassisted before reaching for anything.

Three details that make this work rather than just cost you time:

Non-urgent only. This is practice, not principle. If production is down, use every tool available. Nobody benefits from you being slow during an incident.

Fixed and short. Thirty minutes. Set a timer. The point is the attempt, not the completion, and an open-ended commitment gets abandoned within a fortnight.

Check your answer afterwards. This is the part people drop, and it's the part the research says is essential. Deliberate practice requires feedback. After your thirty minutes, whether you solved it or not, ask the AI and compare. The gap between your hypothesis and the actual answer is the whole lesson. Struggling without ever finding out if you were right builds nothing.

Thirty minutes a week is roughly one percent of your working time. That's the price, and it's low enough that the honest cost-benefit argument doesn't really apply.

⚖️ The objection worth taking seriously

Here is the strongest version, and it deserves a real answer rather than a dismissal:

We don't hand-optimise assembly any more, and nobody laments the lost skill. Compilers made it unnecessary, the profession moved up a level, and that was straightforwardly good. Maybe debugging intuition is the same, and preserving it is nostalgia rather than engineering.

That's a serious argument and I think it's partly right. Some of what we currently call debugging skill will look like assembly optimisation in ten years, and time spent preserving it will have been wasted. I can't tell you which parts.

The distinction I'd draw is this. Assembly stopped appearing in the work. You don't encounter it, so not knowing it costs you nothing. Debugging hasn't disappeared. The systems still fail, and a meaningful share of failures are novel: undocumented interactions, a vendor behaving unexpectedly, a silent data corruption with no error attached. Those still require someone to reason from symptoms to cause in a system nobody has written about.

If that changes, this advice expires and it should. Until then, the thing being preserved isn't the manual labour. It's the ability to form a hypothesis about a system you don't fully understand, which is a more general skill than debugging and shows up in design, incident response, and architecture too.

One more honest note: the evidence here is thinner than I'd like. Developers report concern about deskilling in surveys, and the deliberate practice research is solid on how skills form. But I'm not aware of a study that directly measures debugging capability in AI-assisted cohorts against unassisted ones. The mechanism is well-supported. The specific outcome is reasoning, not measurement, and you should weigh it accordingly.

🎯 The takeaway

One non-urgent bug per week. Thirty minutes unassisted. Then check your answer.

The checking is not optional. Practice without feedback isn't practice, it's just slower work.

You're not protecting a craft. You're maintaining the ability to reason about a system nobody has documented, which is still, for now, a thing the job requires.

This is post #5 in a series on AI practice for data engineers. Next up: **Using AI Without Deskilling.**

You Forgot to Mention the 500 Million Rows

raghav sharma — Tue, 04 Aug 2026 09:00:00 +0000

The query Claude wrote is genuinely elegant.

It's also a self-join across a table you didn't mention has half a billion rows. It ran fine against your dev sample. Production is a different story.

Nothing went wrong in that exchange. You described the problem accurately. You got a correct answer. The answer was correct for the problem as you stated it, and the problem as you stated it was missing the part that mattered.

🔍 The two problems in every query

Every query you write is solving two problems at once.

The first is logical. What data do you need, how does it relate, what shape should the output take. This is the problem you think about, the one you can describe in a sentence, and the one that naturally goes into a prompt.

The second is physical. How much data, how it's distributed, how fast the answer needs to come back. This is the problem that determines whether your correct query finishes in four seconds or four hours.

Describe only the first one and you get an answer that solves only the first one. Logical correctness is the harder thing to get right in general, so the answer looks complete. It reads as finished work.

Two examples.

A window function over an unpartitioned table. The logic is right: rank records within each customer, take the latest. Against a dev sample it returns instantly. Without a PARTITION BY clause the engine treats the entire table as a single window, and the sort that follows is the most expensive part of window function execution. A query that should take seconds takes twenty minutes and puts pressure on everything else running at the time.

A self-join that's fine at a million rows. Join a table to itself to compare each record against its predecessor. At a million rows, fine. At five hundred million, the intermediate result is enormous and the job either spills to disk or fails. The logic never changed. The physics did.

🧠 Why intermediates specifically

Beginners aren't usually handed production-scale problems. Seniors have been through enough of these that scale questions come first automatically, before the logic is settled.

Intermediates are in the specific position of owning real systems while still thinking correctness-first. That ordering is a strength in most contexts. It's how you build things that work. But it means scale facts get filed as background information rather than as requirements.

The row count feels like a property of your environment. The latency budget feels like something the business decided. Neither feels like part of the technical question, so neither reaches the prompt.

They are part of the technical question. At five hundred million rows they are most of it.

✅ Three numbers, before the question

Lead every performance-relevant request with these:

Row count. Cardinality of the join or partition key. Latency budget.

Instead of:

"How do I get the latest record per customer from this table?"

Send:

"Table has roughly 500M rows, about 2M distinct customers, and this needs to complete in under 2 minutes. How do I get the latest record per customer?"

Same question. Different answer. The first gets you a window function. The second gets you a discussion of whether you should be maintaining a separate current-state table instead.

Why these three:

Row count determines whether an approach is viable at all. Some patterns hold at any scale. Others fall apart past a threshold, and the threshold is the thing worth knowing.

Cardinality determines what your partitioning options are, and the right answer depends on your system. In a warehouse or lakehouse, low cardinality is usually what you want: a date column with a few hundred distinct values gives manageable partitions and effective pruning. Partitioning by customer ID with two million distinct values gives you two million tiny partitions, heavy metadata overhead, and queries slower than no partitioning at all. In distributed key-value stores the guidance inverts, because there the goal is spreading write load evenly rather than enabling pruning. Either way the number is what determines the recommendation, so state it.

Latency budget determines how much you're willing to spend. A query that runs nightly can afford things a query behind a dashboard cannot. Without this number you get an answer optimised for nothing in particular.

Put them before the question, not after. Context that arrives afterwards tends to be treated as clarification rather than as a constraint that reshapes the whole answer.

⚖️ The objection worth taking seriously

The weak version is "I shouldn't have to specify everything, a good engineer would ask." True, and easy to answer: you won't be asked, so state it.

The stronger objection: you often don't know these numbers precisely, and a wrong number can be worse than no number. Guess two million distinct customers when it's actually forty thousand and you get an answer optimised for a distribution you don't have, delivered with the extra confidence that comes from having been given specifics. Precision you don't actually possess is a real risk.

The answer isn't precision. It's order of magnitude, stated as such. "Hundreds of millions of rows, millions of distinct keys, needs to finish in minutes not hours" is enough to change the recommendation correctly, and you almost always know that much. Being off by a factor of two inside the right order of magnitude rarely changes anything. Being off by a factor of a thousand changes everything, and that's the error this catches.

If you genuinely don't know the order of magnitude, that's worth finding out before you optimise anything, independent of AI.

🎯 The takeaway

Three numbers, before the question:

1. Row count. Order of magnitude is enough. Say it's an estimate.

2. Cardinality of the join or partition key. And name your engine, because the right partitioning answer differs between warehouses and key-value stores.

3. Latency budget. Nightly batch and dashboard-backing are different problems.

The logical problem is the one you naturally describe. The physical problem is the one that decides whether the answer works. Only one of them reaches your prompt by default.

This is post #4 in a series on AI practice for data engineers. Next up: **The Debugging Intuition That Never Developed.**

The Most Underused Prompt in Data Engineering

raghav sharma — Sun, 02 Aug 2026 09:00:00 +0000

You've learned not to trust the first answer.

So you read it carefully. You spot two problems. You fix them yourself, ship it, and move on. That's a reasonable way to work, and it's what separates an engineer who uses these tools well from one who copies and pastes.

But there's a step you skipped. You never asked Claude to find the problems, and asking produces a different kind of output than reviewing does.

🔍 What actually happens

Here's a specific case. You ask for an incremental load. You get something clean: a watermark column, a filter on records newer than the last run, an upsert into the target.

You review it. You notice it assumes source records arrive in order, which yours don't, so you add a buffer window. You notice it doesn't handle the first run when the watermark is null, so you add a default. Two fixes, maybe fifteen minutes, and now it's correct.

What you didn't find was the third problem: the upsert assumes a stable business key, and in your source system that key gets reassigned when records are merged. That one surfaces in production six weeks later as duplicate rows nobody can explain.

You caught the problems you were looking for. You didn't catch the one you weren't.

This is the normal outcome of self-review. You check against your own mental list of things that go wrong, and your list is good but finite. The problems that hurt are the ones outside it.

🧠 Why intermediates specifically miss this

Beginners don't review AI output much at all, so this isn't their failure mode yet. Seniors have usually developed the habit after being caught out by something their own review missed.

Intermediates sit in an awkward middle. They have learned, correctly, that AI output needs questioning. And they have concluded, understandably, that the questioning is entirely their job.

That conclusion makes sense. Reviewing is what you do with a junior's pull request. It's what you do with your own code before you push. Review is a human activity performed on work someone else produced, so of course you review the model's output yourself.

The step that doesn't occur to you is asking a second, differently-shaped question about the same code. Not because the model has privileged knowledge about its own output, but because a request to find problems produces different text than a request to solve one.

✅ The prompt

After any output you intend to ship, send this:

Critique this. What breaks first? What did you assume that I didn't tell you?

One extra turn. Here is what each part is doing.

"Critique this" changes the task. You asked for a solution and got one. Asking for problems produces a different response, and the overlap with what you already noticed is usually partial.

"What breaks first?" forces a ranking. You don't want a list of twelve theoretical concerns. You want the one most likely to actually fail, which is usually the only one worth acting on today.

"What did you assume that I didn't tell you?" is the most useful clause and the one people leave out. Every answer rests on things filled in from nothing, because you didn't specify them. Source ordering. Key stability. Null behaviour on first run. Timezone consistency. Surfacing that list is how you find the problem outside your own checklist.

In the incremental load example, that third clause is what surfaces the business key assumption. Not because the model knew it was a problem, but because listing assumptions is a mechanical task and you can then check each one against a system you know and it doesn't.

⚖️ The objection worth taking seriously

The weak version is "if it knew what was wrong, why didn't it say so the first time?" Easy to answer: you asked for a solution, not a critique.

The stronger objection, and one with real evidence behind it: models asked to critique their own work do not reliably identify their own errors. There is published research finding that self-correction without external feedback can leave output unchanged or make it worse, and that a model asked to find problems will often generate plausible-sounding concerns about code that is fine. If you treat the critique as a defect list and implement every item, you can end up with something more complex and less correct than what you started with.

That is a real limitation and it changes how you should use this. The value here is not that the critique is accurate. It's that it produces a list of things to check, and you are the one doing the checking. "This assumes source ordering" is useful to you because you know whether your source is ordered. The model doesn't. You're using it to widen the search, not to make the judgment.

Used that way, a wrong item in the critique costs you thirty seconds of reading. Used as a defect list, it costs you a worse pipeline. The distinction matters more than the prompt does.

🎯 The takeaway

One extra turn on anything you plan to ship:

Critique this. What breaks first? What did you assume that I didn't tell you?

Read the response as candidates to check, never as defects to fix. Most of the value sits in the last question, because the assumptions you never specified are exactly the ones you won't think to review.

This is post #3 in a series on AI practice for data engineers. Next up: **You Forgot to Mention the 500 Million Rows.**

Confident Is Not Correct: Three Signs That Claude Is Guessing

raghav sharma — Sun, 02 Aug 2026 03:12:55 +0000

The answer arrives clean, well-formatted, and certain. You run it. The config flag doesn't exist.

Nothing in the response told you the difference between the parts it was sure about and the parts it filled in. The syntax was right. The explanation was reasonable. The flag had a sensible name and a clear purpose. It just wasn't real.

This is a calibration problem, not a trust problem. "Don't trust AI" is useless advice. It tells you to doubt everything, which is the same as doubting nothing, because you can't actually work that way. What you need instead is a way to tell which parts of an answer are grounded and which were filled in. There are patterns to look for, and once you know them, they are hard to miss.

🔍 Why this affects beginners specifically

This isn't about intelligence. It's about experience.

An engineer with a few years behind them has already lost time to a function that didn't exist. They have wasted an afternoon on a config parameter that turned out to belong to a different engine. They have built up a collection of "that looked right but wasn't" memories, and those memories now activate automatically. A small feeling that says check this one before they run it.

Beginners haven't had those afternoons yet. The pattern recognition that comes from repeated failures doesn't exist, because the failures haven't happened. Everything arrives in the same confident tone, and without past mistakes to compare against, there is no internal signal separating a grounded answer from a made-up one.

That's not a character flaw. It's missing experience, and it can be partly replaced with three concrete things to look for.

✅ The three signs

These aren't perfect. They are a minimum standard, and they catch the common cases. I'll be clear about what they miss at the end.

Sign 1: Very specific details with no source

When the answer includes a precise detail (a specific config flag, a particular function signature, an exact version number) and doesn't say where that detail comes from, that is the highest-risk part of the response.

Grounded answers tend to be general where the model is less certain and specific where it is more certain. Made-up answers are often specific everywhere, because there is no visible uncertainty signal in the output. A real Spark config parameter and an invented one arrive looking exactly the same.

The check: if a detail is specific enough to copy into code, verify it exists in the actual documentation for your version before you run it. Not whether the logic makes sense. Whether the thing itself is real.

A Spark config flag that sounds right, follows the naming convention, and controls exactly what you need. And doesn't exist. That's sign 1.

Sign 2: A function that exists, but in a different tool

This is closely related to sign 1, but it appears differently.

You ask how to do something in Snowflake. The answer uses a function that does exactly what you need, with clean syntax and a sensible name. You check the Snowflake documentation. The function isn't there. You search further. It exists in BigQuery.

The function is real. The capability is real. It just belongs to a different engine. This is more dangerous than a completely invented function, because it almost checks out. You can find documentation for it, just not for your system.

The check: when a function is unfamiliar, verify it against your engine's documentation specifically, not a general web search. "Does this function exist" and "does this function exist in Snowflake" are different questions, and only the second one matters.

Sign 3: Answers that don't change when you remove important context

This is the least obvious sign and the most reliable one.

Try this: ask a question with a specific constraint. Get an answer. Then ask the same question again with the constraint removed. If the answer barely changes, the constraint wasn't actually being used, which means the model may have produced a generic answer and wrapped it in your details.

For example: you ask for a partition strategy for a table with 500 million rows and heavy read traffic on a date column. You get a detailed answer. Now ask for a partition strategy for "a large table." If the answer is mostly the same (same recommendation, same reasoning, just without your numbers) then the first answer was not shaped by your constraints. It was a generic answer with your context added on top.

The check: on anything important, remove a key constraint and ask again. If the answer stays the same, it probably wasn't using that constraint in the first place.

⚖️ The objection worth taking seriously

The strongest version of the pushback isn't "don't trust AI." It's this: these signs are rules of thumb, and a model can be confidently wrong while showing none of them.

That's true. There will be answers that pass all three checks and are still wrong. The function exists in your version, the answer changes when you remove context, the specific details are real, and the logic is still subtly flawed. A three-point checklist can create false confidence in exactly the cases it misses.

That's a real risk, and it's why the framing matters. These are a minimum standard, not a guarantee. They catch the common failures: functions that don't exist, answers from the wrong engine, generic advice dressed up as specific advice. What they don't do is confirm that everything else is correct. Anything that passes all three checks still needs your judgment. But anything that fails one of them can be caught in thirty seconds, before it costs you an afternoon.

The goal isn't eliminating every bad answer. It's catching the ones that follow a pattern, cheaply, so your actual thinking time goes to the ones that don't.

🎯 The takeaway

Three signs. Check before you run.

1. Very specific details with no source. If it's specific enough to paste into code, verify it exists in your version's documentation.

2. A function from the wrong tool. Check against your engine specifically, not a general search.

3. Answers that don't change when context is removed. Take out a key constraint and ask again. If the answer stays the same, it wasn't using your context.

These won't catch everything. They catch the failures that follow a pattern, and those are the ones costing you the most time right now.

This is post #2 in a series on AI practice for data engineers. Next up: **The Most Underused Prompt in Data Engineering.**

The Bug That Comes Back Wearing a Different Hat

raghav sharma — Thu, 30 Jul 2026 06:24:38 +0000

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, and that collection 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 caught out 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. Next up: **Confident Is Not Correct: Three Signs That Claude Is Guessing.**