DEV Community: raghav sharma

Stop Re-Receiving the Advice You Already Rejected

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

Third time in the same conversation, it suggests change data capture.

You ruled that out an hour ago. The licence cost for the connector was more than the problem is worth, and you had that conversation with your finance partner in March. It is closed.

But you never wrote that down. So the suggestion keeps arriving, you keep skipping past it, and you have now spent three turns being offered something you decided against before the conversation started.

🔍 The reasoning exists only in your head

You did the work. You looked at the licence, weighed it against the pain of the current setup, and decided. That was a real evaluation and it took real time.

None of it is in the conversation. What is in the conversation is your question, which describes the problem you still have. From that, change data capture is a sensible answer. It will keep being a sensible answer until something says otherwise.

The gap here is different from the ones in the last few posts. Those were about information you did not think to include: your engine version, your row counts, who is on call. This is about a decision you already made. It feels less like missing context and more like something that should already be known, because to you it is settled.

There is a second version of this that costs more. You do mention it, but halfway down a long thread, in passing, while explaining something else. The large study of multi-turn conversations I have referred to before found what researchers call a lost-in-middle effect: models pay disproportionate attention to the first and last turns, and references back to middle turns fell below 20%.

So there is a real difference between saying it at the top and saying it in turn nine. The second one is not a substitute for the first.

📊 How this shows up at each level

The mechanism is the same for everyone. What changes is what you are rejecting and why it stays unwritten.

Beginner. You have not ruled much out yet, so this rarely costs you anything. When it does, the rejection is usually simple and easy to write down: tried it, did not work.

Intermediate. Your rejections are technical. Tested it, too slow. Tried the library, it does not handle our date format. These are straightforward to state and the only reason they go unstated is that it feels like admin.

Senior. Your rejections are frequently not technical at all. You cannot use that vendor because of a procurement dispute. You will not propose that migration because the last one damaged your credibility. The team tried it in 2023 and it went badly enough that raising it again would cost you something.

Those are the ones that stay in your head, and it is not because you forgot. Writing "we cannot use vendor X for political reasons" feels like putting something on the record. So the most decisive constraints on a senior's options are the ones least likely to be written down, by the person best placed to write them.

✅ Two lines at the top

Before the question, not after it:

Already ruled out: CDC (connector licence cost, decided March)
                   lakehouse migration (no capacity before Q3)

Three things make this work.

Give the reason, not just the name. "Ruled out CDC" invites it to come back in a different shape. "Ruled out CDC on licence cost" rules out the whole family of paid-connector answers, which is what you actually meant.

Put it above the question. Not because it reads better, but because the beginning of a conversation gets attended to and the middle does not.

Include the awkward ones. Especially the awkward ones. "Not proposing another migration this year for reasons that are not technical" is a real constraint and it will do more to shape a useful answer than anything about your stack.

⚖️ The objection worth taking seriously

The weak version is that this is basic prompt hygiene rather than an insight. Fair enough. Cheap things are often the ones nobody does.

The stronger objection is about what a list of rejections actually is. It is a record of decisions you made in the past, presented as facts about the present, and it goes stale without anyone noticing.

You ruled out that connector on licence cost in March. It is now August. The vendor changed their pricing in June. You ruled out the migration for lack of capacity, and then two people joined. You rejected a tool because nobody knew it, and your new hire used it for three years.

Carry the block forward and none of that surfaces. You will get carefully reasoned answers that route around obstacles which no longer exist, and they will be delivered with total confidence, because you supplied the obstacles yourself. That is worse than the original problem, because at least the repeated suggestion was visible. This failure is silent.

I do not think that is a reason to skip the block. It is a reason to date it. Write the month you decided next to each item, as in the example above. Then when you paste it in October and see "decided March," you have a prompt to ask whether it still holds.

And once a quarter, take the list and ask the opposite question: which of these would you decide differently today. Some of them will have expired. The list is only useful if it is a record of what is true, rather than a record of what you once concluded.

🎯 The takeaway

Two lines, above the question:

Already ruled out: [option] ([reason], [month])
                   [option] ([reason], [month])

1. Reasons, not just names. The reason rules out the family. The name only rules out the one.

2. At the top. The middle of a conversation gets less attention than the start.

3. Date them, and review them. A rejection from six months ago is a decision, not a fact, and some of them expire.

The suggestion kept coming back because nothing in the conversation said no. You said it in March, to somebody else, in a different room.

Technically Right, Organisationally Impossible

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

The architecture is correct.

You read it twice looking for the flaw and there is not one. The tradeoffs are handled. The failure modes are addressed. If you had a team of eight it would be the right answer.

You have four people. One of them understands Flink, she is on call every third week, and she has been talking to a recruiter. You cannot build this, and nothing in the recommendation is wrong.

🔍 What was missing was not technical

There is a well-tested finding underneath this, and it is older than most of the tools involved.

In 1968 Conway observed that a system's structure ends up mirroring the communication structure of the organisation that built it. That sat as folklore for decades until MacCormack, Rusnak and Baldwin tested it properly, comparing products built by loosely-coupled and tightly-coupled organisations. They found strong support: in every pair they examined, the loosely-coupled organisation produced a significantly more modular product.

Microsoft went further in a 2008 study of Windows Vista, measuring organisational structure against defects. Their finding was blunt. The organisational measures were statistically significant predictors of how failure-prone a component would be.

So the shape of your organisation is not context around the architecture. It is one of the inputs that determines whether the architecture works. An answer that does not have it is missing a variable, not a nicety.

This is a different gap from the one in the last post. There I was talking about what you cannot change: your orchestrator, your language, what your team knows how to write. That is about whether you can build the thing. This is about whether you can still be running it in two years, which is a separate question with different inputs.

🧠 Why only seniors can supply this

Nobody else on the team has the information.

A mid-level engineer knows their own workload. They do not know that the platform team is losing two people in Q1, that the Flink migration was already attempted in 2023 and abandoned, or that your director has told you no new headcount until the reorganisation settles. You know all of it, and you are the only one who does.

The reason it does not get written down is that it does not feel like part of a technical question. When you ask about handling late-arriving events, the on-call rotation seems like a separate topic, filed under management. So you supply every technical constraint you have and none of the ones that will actually decide this.

There is a second reason and it is more awkward. Some of these facts are uncomfortable to state plainly. "One person understands this system and she may leave" is a real fact about your architecture and it also reads as an admission. It is easier to describe the technology than to describe the situation.

✅ Three lines about running it, not building it

On call:     4 engineers, weekly rotation, ~2 pages/week now
Bus factor:  1 person understands the streaming layer
Slack:       no capacity for a new system until Q2 at the earliest

On call is the most useful line and the one people never write. It converts an architecture question into an operations question, which is what it becomes about a month after launch. A design that adds three new alerting surfaces to a rotation already running at two pages a week is a different proposal from the same design on a quiet rotation.

Bus factor changes recommendations more than almost anything else. An answer that is correct when three people understand the system may be reckless when one does. It moves the right answer toward boring technology and away from the thing that is technically better.

Slack is the line that stops you receiving a plan for a team that does not exist. Not headcount. Whether the people you have could take on another system without dropping something.

Notice none of these mention skill. That is covered by asking what your team knows, and it is a different question. Skill is what they can write. This is what they can carry.

One thing worth adding to important questions: ask what this design would cost to operate, separately from what it costs to build. That is not a normal question and you will not get the answer unless you ask it. It is where most of these decisions actually get made.

⚖️ The objection worth taking seriously

The weak version is "that is a people problem, not an architecture problem." The mirroring research answers it: the organisation predicts the defects, so it is an architecture input.

The strong version is harder. State your limits and you will get advice that works around them, forever.

There is a measured behaviour behind this. Models tend to accept a user's premises rather than challenge them, which researchers call framing sycophancy. So "we have one Flink engineer and no headcount" produces the best available design for a team with one Flink engineer and no headcount. What it will not produce is the sentence you might actually need, which is that you are attempting something your team is not staffed to run, and that the answer is a hiring decision rather than a design decision.

You are also the person who could change that. A mid-level engineer stating the same constraints is describing weather. A lead doing it is describing something they have some power over. Encoding your organisation's current limits into every technical decision is one way a team stays exactly the size and shape it is, permanently, while the architecture quietly bends to fit.

The Conway's Law literature has a line about this that is worth keeping. When you are fixing a broken organisation or a broken architecture, fix the organisation first, because the architecture will follow it either way.

So the honest version of the practice is two questions rather than one. Ask the constrained version, because you have to ship something. Then ask separately: given this problem, what team would you need to run this properly, and how far is that from what I have? You will not always act on the answer. But that gap is the actual finding, and stating your constraints is how you make sure you never see it.

🎯 The takeaway

Three lines about running it:

1. On call. How many people, how often, how noisy already.
2. Bus factor. How many understand each part. One is a design input.
3. Slack. Whether anyone could take on another system this quarter.

Then ask separately what team this design assumes. The distance between that and your team is the real answer, and you will only get it if you ask for it on its own.

The architecture was correct. It was correct for an organisation you do not have, and nothing in it was going to tell you that.

Claude Assumed You Were Building Greenfield. You Were Not.

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

You ask how to handle late-arriving events in your pipeline. The answer is clean, modern and sensible. It involves Kafka, a streaming framework, and a state store.

You run batch. Everything runs batch. The batch runs on an Airflow instance somebody set up in 2021, the transformations are four hundred stored procedures nobody wants to touch, and the team spent the last quarter learning dbt and is finally productive with it.

None of that was secret. You mentioned Airflow. You just mentioned it the way you would mention the weather.

🔍 Facts and constraints are different things

Here is the sentence most people write:

We use Airflow for orchestration and mostly work in dbt.

And here is what it does not say: whether any of that can change.

Read as a fact, "we use Airflow" is background. It describes where you are, not where you have to stay. An answer that suggests moving to something else has not contradicted anything you said. You said what you use. You did not say you were stuck with it.

Read as a constraint, the same information is completely different:

Orchestration is Airflow and cannot change this year. Transformations must stay in dbt because the team learned it last quarter and is finally productive. We can add libraries but cannot add infrastructure.

That version rules things out. The first version does not rule anything out, so nothing gets ruled out.

This is a different problem from not describing your system at all. You can write a perfectly accurate description of your stack, engine versions and everything, and still receive an answer that quietly replaces half of it, because a description tells you what exists and says nothing about what is fixed.

🧠 Why this catches intermediates specifically

Beginners usually are not asked architecture questions.

Seniors state constraints reflexively, because they have had a recommendation die in a planning meeting over something nobody put in writing.

Intermediates are at the point where they get asked "how should we handle this," which is an architecture question, while still describing their situation the way they would describe it to a colleague. And to a colleague it works fine, because a colleague knows the stored procedures are not going anywhere. They have been on the same team as you for two years. The context they are filling in is not in your sentence, it is in the building.

There is a second reason, and it is about how the constraints feel from inside. The reason you cannot replace Airflow is not technical. It is that the migration would take a quarter nobody has, and the person who knows it best is leaving in March. Those do not feel like engineering facts. They feel like circumstances. So they get left out of a technical question, by the only person who knows them.

✅ Say what cannot move

Three lines, and each one has a job:

Must run on:      Airflow 2.7, existing cluster, no new infrastructure this year
Cannot introduce: streaming, new languages, anything needing a dedicated operator
Team knows:       SQL and dbt well, Python moderately, Spark barely

Must run on is the boundary of the answer. Anything outside it is not a recommendation, it is a project proposal.

Cannot introduce is the line people skip, and it is the one doing the most work. "No new infrastructure this year" removes about half of all modern data advice in six words.

Team knows is the one that seniors include and everyone else forgets. A recommendation your team cannot operate is not a recommendation. If nobody has run Spark in production, an answer built on Spark tuning is a plan to find out what happens when they try.

Notice these are not preferences. "We prefer dbt" invites a discussion about whether you should. "Transformations must stay in dbt" does not. If it genuinely is a preference, say so, and expect it to be argued with.

⚖️ The objection worth taking seriously

The weak version is "sometimes I want the unconstrained ideal answer." Fine, and you should ask for that on purpose rather than getting it by accident.

The strong version is more troubling, and there is research behind it. If you state a constraint, it will be accepted, including when the constraint is the actual problem.

There is a measured behaviour here called framing sycophancy: models tend to accept a user's premises rather than challenge them. Researchers at Stanford describe this as defaulting to going along with the user's assumptions without enough scepticism, and a 2026 paper in Science found the broader pattern of excessive agreement present across eleven current models.

Applied here, that means if you write "must stay on Airflow," you will get the best available answer for staying on Airflow. You will not get told that late-arriving events are painful in your setup because of the batch orchestration, and that you are solving a problem you have chosen to have. The constraint you stated becomes the ceiling on what you can learn, and nothing signals that a ceiling was applied.

That is a real cost, and over a couple of years it means these tools become very good at making your existing decisions work and never at questioning them.

Two things follow. First, ask the unconstrained version as a separate question, deliberately, and read it as information rather than as a plan. "If you were starting fresh, how would you handle this" tells you what you are paying for your existing setup, which is worth knowing even when you cannot change it.

Second, invite the challenge explicitly. The same Stanford research found that small changes to how a prompt is phrased, including something as simple as adding "wait a minute," measurably improved models' willingness to push back on a premise without producing a lot of false alarms. So a line like "before answering, tell me whether any of these constraints is what is actually causing this problem" is worth adding to anything consequential. You will usually be told nothing is wrong. Occasionally you will not, and that is the one you needed.

🎯 The takeaway

Three lines, stated as boundaries and not descriptions:

1. Must run on. What the answer has to fit inside.
2. Cannot introduce. The line that removes most generic advice, and the one people leave out.
3. Team knows. A solution nobody can operate is not a solution.

Then one more line for anything important: ask whether one of those constraints is the cause of the problem. It will usually say no. That is not the point of asking.

Describing your stack tells the answer where you are. Only a constraint tells it where you have to stay.

You Are Describing the Symptom, Not the Problem

raghav sharma — Fri, 21 Aug 2026 09:00:00 +0000

There are nulls in the report. You ask how to handle them.

You get a good answer. Coalesce them, or filter them, or flag them for review, with a sensible discussion of which is appropriate when. You pick one, ship it, and the report looks correct again.

Two days later somebody notices the totals are down about 3% against last quarter, and you find the actual problem. A key upstream changed format, so a join that used to match stopped matching, and it has been quietly producing nulls for six weeks. Your fix hid it.

🔍 The question you asked was answerable

Nothing went wrong in that exchange, which is what makes it hard to catch.

You asked a well-formed question about null handling and got a well-formed answer about null handling. There was nothing in your question suggesting the nulls were new, or unexpected, or concentrated in rows that used to match something. So the answer treated them as a normal data condition to be handled, which is what they usually are.

A person looking over your shoulder might have asked "were they always there?" A prompt has no way to ask that unless you have made it possible.

Two versions of this show up constantly in data work, and they are different failures worth telling apart.

Nulls that are new. A join key gains trailing whitespace, or changes case, or gets cast to a different type upstream. A LEFT JOIN that used to match now does not, and unmatched rows come through as nulls. The symptom is nulls. The cause is a key format change three steps back.

Numbers that are slightly off. A join that was one-to-one becomes one-to-many, so rows get duplicated. Counts inflate and averages move toward whatever the duplicated rows contain. The symptom is a metric that looks wrong by a few percent. The cause is a join that fans out.

In both cases you can ask a reasonable question about the symptom and get a reasonable answer that leaves the cause running.

🧠 Why this happens early in a career

There is well-established research here, and it is not about programming.

In 1981, Chi, Feltovich and Glaser asked physics students and physics professors to sort problems into groups. The students grouped them by what the problems looked like: the ones with pulleys together, the ones with inclined planes together. The professors grouped them by the principle needed to solve them, so a pulley problem and a ramp problem sat together because both were about conservation of momentum. The finding has been replicated enough to be widely accepted, and the same literature notes that novices depend more on visible clues than experts do.

That is this problem exactly. Nulls in a report are the pulley. The join behaviour is the principle.

It is not that beginners are careless about where they look. It is that the visible thing is genuinely the only thing available to organise a question around, until you have enough experience for the deeper structure to be visible at all. An experienced engineer sees "nulls appearing in a column that used to be populated" and thinks join, because they have been caught by that before and it filed itself under something.

Which means the advice "look for the root cause" is not usable. If you could see the root cause you would already be asking about it. What you need is a way of writing the question that opens the path to it without requiring you to know the answer first.

✅ Write the gap before you ask anything

Two lines, before the question:

Expected: every order row has a matching customer name
Actual:   about 4% of rows have a null customer name, starting some time this month

That is the whole technique. Write what you expected. Write what you got. Then ask.

Notice what happened just by writing it. "There are nulls" is a state. "Rows that should have matched are not matching, and this is new" is a change, and a change has a cause. The second version cannot be answered with "here is how to handle nulls," because it is no longer a question about nulls.

Three things make it work:

Expected is where the information is. You are stating what the system is supposed to do, which is knowledge nobody else has. That single line rules out most of the wrong answers.

"Starting this month" turns a state into an event. Anything with a start date has something that changed. That is the most useful thing you can say, and it is the thing people leave out most.

A percentage beats "some." Four percent of rows suggests a subset that shares a property. Ninety percent suggests something structural. Those lead in different directions.

You do not need to know the cause to write these two lines. That is the point of them.

⚖️ The objection worth taking seriously

The weak version is "I do not know where the cause is, which is why I am asking." Fine, and the two lines do not ask you to know.

The stronger objection is this: in a lot of data work you do not know what to expect either. You are looking at a metric you do not own, in a pipeline someone built before you arrived, and the honest state is that you have no idea what the correct number is. "What should this be?" is the actual question. The expected-versus-actual framing assumes you hold one half of a comparison, and often you do not.

That is a real limitation and it applies more often than I would like. When you genuinely do not know what to expect, this technique does not help you, and pretending to an expectation you do not have is worse than saying nothing.

What it changes is what you should do first. If you cannot write the expected line, then establishing the expectation is the task, and it is a different one from fixing the symptom. Find who owns the metric. Find what it looked like six months ago. Find whether anyone has ever validated it. Those are unglamorous and they are the actual work, and no amount of prompting substitutes for them.

The technique is for the common case where you do have a violated expectation and have not written it down. That covers most bug reports. It does not cover exploration, and it is worth knowing which one you are in before you start.

🎯 The takeaway

Two lines, before the question:

Expected: [what the system is supposed to do]
Actual:   [what it is doing, with a rough size and a rough start date]

1. Expected is the line only you can write. It carries the knowledge that rules out wrong answers.

2. Say when it started. A state invites handling. A change invites investigation.

3. Give a rough proportion. Four percent and ninety percent point in different directions.

If you cannot write the expected line, that is useful information too. It means the job is not fixing this yet. It is finding out what the number is supposed to be.

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.**