DEV Community: Jason Lau

Prompt Engineering Won't Survive — the Skill Underneath It Will

Jason Lau — Wed, 02 Sep 2026 09:49:37 +0000

For about two years, "prompt engineer" was the job title recruiters attached to six-figure listings and career-changers scrambled to add to a resume. Then the interest mostly stopped converting into jobs. The Wall Street Journal reported that Indeed searches for the role spiked to 144 per million U.S. searches in April 2023 and have since flatlined at 20-30 per million — and, per Indeed VP of AI Hannah Calhoon, that interest was never matched by actual employer job postings in the first place: "Maybe they talked about the value of prompt engineers, but they weren't then actually hiring for that." A title that rose and mostly stalled out inside two model generations. Microsoft's Jared Spataro put the reason bluntly: "You don't have to have the perfect prompt."

That's a fair obituary for the "prompt engineer" job title. It's a bad obituary for the underlying work, and the mistake is treating both as the same thing.

What actually died was a set of tricks tuned to specific models

Open any 2023-era prompt-engineering article and it's mostly mantras: "think step by step," phrase it as a role assignment, wrap the instruction in triple quotes, promise the model a tip. These worked because they guided a specific model around a specific weakness — and weaknesses don't persist across model generations.

Chain-of-thought is the clearest case, because it's the most-cited prompting technique there is and it's now been re-measured against current models. A 2025 technical report from Wharton's Generative AI Labs ran chain-of-thought prompting against eight models spanning both non-reasoning and reasoning types. The results don't point one direction. Gemini 2.0 Flash gained 13.5% and Sonnet 3.5 gained 11.7% — real improvements. GPT-4o-mini gained 4.4%, a difference the authors couldn't call statistically significant. Gemini Pro 1.5's rate of getting every part of a problem fully correct dropped 17.2 percentage points with chain-of-thought turned on. Among the reasoning models — the ones already trained to produce their own extended reasoning — o3-mini and o4-mini picked up a marginal 2.9-3.1%, while Gemini Flash 2.5 lost 3.3%. All of this arrived with a real tax: 35-600% longer response times for non-reasoning models, 20-80% longer for reasoning ones. The paper's own framing is careful rather than dramatic — "its effectiveness depends significantly on model type and specific use case" — but read against the trend, that's a technique whose payoff is shrinking and inverting as the models it was compensating for get better at reasoning on their own.

A 2025 arXiv paper on what it calls the "Prompting Inversion" makes the same point sharper by comparing one technique across two model generations directly. The authors built "Sculpting," a heavily constrained prompting method, and pitted it against plain chain-of-thought. On GPT-4o, Sculpting won clearly — 97% accuracy against chain-of-thought's 93%. On GPT-5, the ranking flips: Sculpting drops to 94.00% while plain chain-of-thought reaches 96.36%. Their explanation is that the same constraints acting as guardrails for a mid-tier model become "handcuffs" on a more capable one — the scaffolding that stopped GPT-4o from wandering off just gets in GPT-5's way. A technique doesn't get more true as models improve; it can flip sign entirely.

The instability was already visible in how fragile the tricks were

None of this should be surprising if you look at how sensitive prompt outputs already were to changes that had nothing to do with meaning. Sclar, Choi, Tsvetkov, and Suhr measured how much purely cosmetic prompt formatting — whitespace, separator characters, capitalization — could move accuracy on the same task with the same content, and found swings of up to 76 accuracy points on LLaMA-2-13B. Critically, they found this sensitivity "remains even when increasing model size, the number of few-shot examples, or performing instruction tuning" — it isn't a small-model problem that scale quietly fixes.

That finding reframes what a lot of "prompt engineering" tips actually were. If reformatting a prompt with no change in meaning can swing accuracy by 76 points, then a technique's measured 10-point gain on some benchmark was never a stable property of the technique — it was one sample from a distribution of formatting accidents that happened to land favorably on that model, at that snapshot in time. Chasing that kind of gain by memorizing the exact phrasing that worked last week is chasing noise, and noise doesn't transfer to the next model release. You have to separate the parts of a prompt that are doing real work (the schema, the goal, the constraints) from the parts that are stylistic residue — which is exactly the split SophiArch's AI-Assisted Data Science course spends its second lesson on, precisely because the residue is what breaks first when your model evolves.

What was actually being taught the whole time

Strip out the mantras and what's left in a good prompt is closer to a specification than a sacred phrase. A 2024 peer-reviewed framework in Frontiers in Education defines prompt engineering as "the skill of communicating the problem, its context, and the constraints imposed on the desirable solution to an LLM to solve it correctly as fast as possible" — and its authors explicitly push back on the idea that this reduces to generic communication skill, arguing it's closer to task decomposition: knowing what you actually want closely enough to state it, before you ever open a chat window.

That's the part that doesn't expire when a new model ships, because it isn't a fact about models — it's a fact about the gap between what's in your head and what's on the page. Consider the difference between two requests to deduplicate a customer table:

"Clean up the duplicate customers in this table."

versus:

"Two rows are the same customer if email matches exactly (case-insensitive) OR both phone and last_name match. When rows conflict, keep the one with the most recent last_order_date; if that's tied, keep the one with more non-null fields. Do not merge rows that share only a last_name — that's a coincidence, not a duplicate. Return a mapping from removed customer_id to the customer_id it was merged into, so the removal is auditable."

Neither of these is a prompting trick. No chain-of-thought cue, no role-play framing, no promised tip. The second one just doesn't leave the model — or a junior analyst, for that matter — a single ambiguous decision to make on its own: what counts as a match, which record wins a conflict, what NOT to merge, and how the result gets checked. A model that's gotten better at reasoning will make smarter guesses at filling those gaps than last year's model did. It will still be guessing, and on a dataset that decides refund eligibility or fraud flags, "the model guessed well" is not the standard anyone should be signing off on.

That's the actual content of "prompt engineering" once you take the model-specific mantras out of it, and it's also why the skill was never new — it's requirements-writing and problem specification, wearing a 2023 label because a chat interface made the gap between vague and precise suddenly visible to everyone, all day, on every request. The interface is what's new. The gap it exposed is not, and closing it is a durable skill for exactly the reason the mantras weren't: it doesn't depend on which model happens to be running underneath.

References

Meincke, L., Mollick, E. R., Mollick, L., & Shapiro, D. (2025). Prompting Science Report 2: The Decreasing Value of Chain of Thought in Prompting. SSRN / Wharton Generative AI Labs.
You Don't Need Prompt Engineering Anymore: The Prompting Inversion (2025). arXiv.
Sclar, M., Choi, Y., Tsvetkov, Y., & Suhr, A. (2023). Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design. arXiv.
Bousquette, I. (2025). The Hottest AI Job of 2023 Is Already Obsolete. The Wall Street Journal.
Prompt Engineering as a New 21st Century Skill (2024). Frontiers in Education.
SophiArch. AI-Assisted Data Science — second lesson module on separating durable prompt structure (schema, goal, constraints) from model-specific tricks.

Your RAG Pipeline Doesn't Have an Accuracy Problem - It Has an Evaluation Problem

Jason Lau — Wed, 26 Aug 2026 03:37:34 +0000

A team builds a retrieval-augmented chatbot over the company's internal policy documents. In the demo, someone asks "how many days of parental leave do we get?" and the bot answers correctly, citing the right PDF. Someone asks about expense limits - correct again. Ten questions, ten good answers, applause, ship it.

Three months later an employee asks whether their contractor status qualifies for the health stipend, gets a confident "yes" assembled from a policy that was superseded last year, and files the claim. Nobody on the team can say when the pipeline started producing answers like that, because nothing was ever measuring whether it did.

That is the real state of most RAG systems in production. The pipeline is not unusually inaccurate - every retrieval system misses sometimes. What's missing is the apparatus that would notice. The demo was treated as the evaluation, and a demo is the one test a RAG system essentially cannot fail: the questions were chosen by the people who built the index, phrased the way the documents phrase things, asked about content everyone knew was in there.

A wrong answer and a right answer look identical

Traditional software fails loudly. A broken API call throws an exception; a bad deploy serves 500 errors; a failing test case turns red. A RAG regression does none of this. Swap the embedding model, change the chunk size, re-index after a document update - the system keeps returning fluent, well-formatted, confidently cited answers. Whether they are grounded answers is invisible in every signal you get: no exception, no latency spike, no schema violation.

This isn't an edge case of RAG engineering; it is a recurring finding in the engineering literature on it. A CAIN 2024 experience report across three RAG case studies (research, education, and biomedical domains) catalogued seven recurring failure points - missing content, missed top-ranked documents, answers retrieved but lost in consolidation, answers present in context but not extracted, wrong format, wrong specificity, incomplete answers - and its two headline takeaways are blunt: "validation of a RAG system is only feasible during operation, and the robustness of a RAG system evolves rather than designed in at the start."

Read that first clause again. You cannot fully validate this class of system before shipping it. Which means the eval harness is not a nice-to-have you add after launch - it is validation-during-operation, systematised: built from the questions real users actually asked, and run continuously as the system and its corpus change. It is the only mechanism by which you ever learn whether the thing works.

"RAG fixes hallucinations" is marketing, and there's a measurement to prove it

The reason teams skip evaluation is an ingrained assumption: retrieval grounds the model, so the hallucination problem is handled. The strongest counterexample comes from a domain with real money behind getting this right. Legal research vendors marketed their RAG products as "eliminating" or "avoid[ing]" hallucinations, even guaranteeing "hallucination-free" citations. When Stanford's RegLab ran the first preregistered empirical evaluation of these tools, the flagship products from LexisNexis and Thomson Reuters "each hallucinate between 17% and 33% of the time."

These are professional-grade systems built by teams with enormous resources over curated, authoritative corpora - the best case for RAG. Retrieval reduced hallucination relative to a bare model, but between one in six and one in three answers still contained fabrication. The gap between "we added retrieval" and "we measured what retrieval actually delivers on our queries" is exactly the gap the vendors' marketing fell into. If they can fall into it, your internal chatbot certainly can.

"Is it accurate?" is two questions wearing one trenchcoat

Suppose you accept the premise and ask: fine, how accurate is my pipeline? The question is underspecified, and that underspecification is why demo-vibes evaluation persists - there was never an agreed definition of correct to check against.

A RAG answer can fail in two independent places, and they need different fixes:

Retrieval failed. The chunks handed to the model didn't contain the answer - it wasn't indexed, didn't rank into the top-k, or got cut during context assembly. No prompt engineering will fix this; you need to change chunking, embeddings, or ranking.
Generation failed. The answer was in the retrieved context and the model ignored it, contradicted it, or embellished beyond it. Re-ranking harder won't fix this; you need to change the prompt contract, the model, or add output validation.

An aggregate "accuracy" number collapses these together and leaves you optimising blind. This decomposition is precisely what the RAGAS evaluation framework formalised into separately measurable quantities: context relevance scores the retrieval step (did the right evidence show up, without drowning in irrelevant material?), while faithfulness and answer relevance score the generation step (is every claim in the answer supported by that evidence, and does it address the question?). The Ragas library has since split the retrieval side further into context precision and context recall. The individual metric implementations have known rough edges - but the decomposition is the part that matters, because it turns "the bot was wrong" into a bug report that identifies a component.

What an actual evaluation harness looks like

None of this requires a research team. A minimum viable harness is three artefacts and a habit.

1. A golden set: your domain's definition of correct, written down. Collect 50-100 real questions - from support logs, pilot users, and the subject-matter expert who knows where the knowledge is buried. For each, record the expected answer and which document(s) it must come from:

{
  "id": "policy_031",
  "question": "Does the health stipend apply to contractors?",
  "expected_answer": "No - eligibility requires full-time employment status.",
  "must_cite": ["benefits-eligibility-2026.pdf"],
  "trap": "superseded 2024 policy still in corpus says yes"
}

That trap field is where the value lives. Easy questions inflate your score; the golden set earns its keep on superseded documents, questions whose answer spans two chunks, questions the corpus cannot answer (the correct behaviour is "I don't know" - the first failure point in the CAIN taxonomy is systems that fabricate rather than decline), and negation cases where the retrieved text says the opposite of what the surface phrasing suggests.

2. Scoring that preserves the retrieval/generation split. Score "did the must-cite document appear in the retrieved set?" separately from "is the answer faithful to what was retrieved?" For the generation side at scale you'll likely use an LLM judge - which is workable but not free of pathology: the MT-Bench study of LLM-as-a-judge found strong judges agree with human raters over 80% of the time, while also documenting systematic verbosity bias (longer answers score better regardless of quality) and signs of self-enhancement bias (judges may favour their own model's outputs). Use a judge, but spot-check it against human labels before trusting it as your regression signal.

3. A regression gate. The harness runs on every change - new embedding model, new chunking strategy, re-index, prompt edit, model version bump - and a score drop blocks the change, the same way a failing test suite blocks a merge. This is the step that converts evaluation from a one-time report into an engineering control. Without the gate, your golden set is a benchmark you ran once in a notebook; with it, "did we just get worse?" has an answer before users provide it.

The demo answered the questions you chose. The golden set answers the ones your users will actually ask - including the ones designed to make your pipeline lie. Build the second thing before you trust the first.

References

Barnett, S., Kurniawan, S., Thudumu, S., Brannelly, Z., & Abdelrazek, M. (2024). Seven Failure Points When Engineering a Retrieval Augmented Generation System. CAIN '24.
Es, S., James, J., Espinosa-Anke, L., & Schockaert, S. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. arXiv.
Magesh, V. et al. Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. Stanford RegLab.
Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS.
Ragas documentation. List of available metrics.

If you want to go deeper than a blog post can, evaluation is where SophiArch's Building AI Applications with LLMs course plants its flag: a full module on golden sets, LLM-as-judge trade-offs, and regression gates, sitting inside a validation architecture that runs from prompt contracts through output checking to production observability.

Clustering Isn't Discovery - It's a Hypothesis You Still Have to Test

Jason Lau — Wed, 19 Aug 2026 09:56:42 +0000

An analyst runs KMeans(n_clusters=4) on dataset of customer purchase history, it gets back four groups, and he/she writes up the report as "from the data, it revealed four customer segments!" Management simply loves this - after long periods struggling to grasp at their customer base, they now have data-backed insights on real-names associated with each segment (Loyal Regulars, Bargain Hunters, At-Risk, New & Exploring), and pretty soon all the strategy meetings will silently assume those four groups are real and nobody even dares to question.

Unfortunately, those groups are not real and clustering does not "discover" hidden nuggets of insights in the data. Instead clustering imposes a partitioning based on what the analyst chooses as a similarity rule. If the analyst had chosen another reasonable rule, clustering can also fit the same dataset in a different way. Let's be clear - the four groups are a hypothesis about how to group the customers. To determine if the grouping is accurate, as in we can use this grouping to predict customer behavior, now that is a separate question that the clustering method can never answer by itself.

Same data, different "discovery"

To illustrate, try running KMeans clustering on an RFM table (recency, frequency, monetary value per customer) and only change the random seed:

from sklearn.cluster import KMeans

km_a = KMeans(n_clusters=4, n_init=1, random_state=7).fit(X_scaled)
km_b = KMeans(n_clusters=4, n_init=1, random_state=42).fit(X_scaled)

print(km_a.inertia_, km_b.inertia_)
# 8421.3   8103.9 - different local optima, neither one "wrong"

inertia: measure of how tightly grouped the data points are within the clusters

Notice that you get different inertia values. KMeans does not find the globally best grouping - it cannot. Instead the algorithm finds a local optimum based on randomly chosen initial centroids and two runs on the same data can converge to genuinely different groupings. In fact scikit-learn's user guide states "Given enough time, K-means will always converge, however this may be to a local minimum. This is highly dependent on the initialization of the centroids". As mitigation, the default behavior is to run the algorithm several times with different centroid seeds (n_init) and retain the run that scored the lowest on inertia - it does not guarantee a single answer.

What if you change to use a different method - say hierarchical clustering with average linkage on the same RFM dataset? In hierarchical clustering, you do not need to specify the number of clusters and hence, the group counts that appear "natural" in your dataset also shifts. This is because hierarchical clustering with average linkage and KMeans are optimizing on different objectives ( nested merge vs compact spherical clusters )

This dissonance between run-to-run, method-to-method is well studied under clustering stability - a collection of research whose overview by von Luxburg (2010) shows how sensitive clustering results are to the seed, sample, algorithm and why stability by itself is not sufficient for meaningful clustering.

Aren't there any methods to decide?

One might say: "We are very data-driven and we use the elbow method to pick k."

There are various metrics or methods to measure how well your clustering algorithm groups the dataset:

elbow (inertia vs k)
average silhouette method (silhouette score vs k)
gap statistic

Side-by-side comparisons of various methods on same dataset often leads to contradictory recommendations on cluster count. There is no one-metric and final decision requires human judgement based on your domain knowledge.

At times, you might have another situation:

from sklearn.metrics import silhouette_score

for k in range(2, 7):
    labels = KMeans(n_clusters=k, n_init=10, random_state=0).fit_predict(X_scaled)
    print(k, silhouette_score(X_scaled, labels))

# 2  0.41   <- highest score
# 3  0.33
# 4  0.29   <- the k the business narrative was built around
# 5  0.24
# 6  0.22

Here, the silhouette score shows k=2 is highest but you get push back from Marketing - "We need 4 separate personas to target!". Nothing wrong with that request, 2 clusters will usually lead to "Loyal" vs "Non-Loyal" segments and it is meaningless for marketing planning. 4 clusters do help in the business narrative to target specific market segments. If this is the case, a disclaimer is in order that k=4 was due to business narrative (instead of "insights from dataset" as authority)

Cluster on demographics may not mean different customer behavior

Your clustering tells you have four groups of customers and they look different based on the features you cluster on - recency, frequency, spend. Note that their behaviors that businesses care about - who leaves for a competitor, who upgrades to higher tier, who responds to coupons - may look different across those same groups. This discrepancy is what marketing teams struggle with using demographic and behavioral personas - the behavioral patterns often cut across various demographic personas.

The fix is not to have a better clustering metric but to validate externally based on your business objectives and goals (churn in the next quarter, response rate to campaign, etc) and check if they differ between clusters more than within the clusters.

What is the correct approach to clustering?

The above does not mean clustering is a useless technique to avoid. Instead what it means is that clustering is only a starting hypothesis for further investigations.

Before presenting the clustering results:

re-run with different seeds and subset of data
- this is to verify the stability of the cluster
check with multiple metrics and methods (elbow, silhouette, gap statistics)
- highlight in report when they disagree
validate externally
- select a business outcome
- confirm it varies across clusters more than within cluster
treat the chosen number of clusters as modeling decision

A clustering that complies with all four does not mean it is "true" but it does earn the right to be acted upon.

References

Kleinberg, J. (2002). An Impossibility Theorem for Clustering. NeurIPS.
von Luxburg, U. (2010). Clustering Stability: An Overview. arXiv.
scikit-learn. Clustering - K-means, User Guide - local-minimum convergence and multiple-initialization behavior.
scikit-learn. sklearn.cluster.KMeans API reference - n_init and random_state parameter definitions.
Datanovia. Optimal Number of Clusters: Elbow, Silhouette, Gap Statistic.
Ahmed, M. et al. (2022). K-Means Clustering Approach for Intelligent Customer Segmentation Using Customer Purchase Behavior Data. Sustainability, 14(12).
MarTech. Why behavioral segmentation beats personas for real personalization.

SophiArch's Unsupervised Learning & Clustering course covers k-means, hierarchical clustering, and validation together for this reason - an algorithm that returns groups is the easy half; judging whether those groups mean anything to the business is the half that determines whether the analysis survives contact with a skeptical stakeholder.

You Don't Need a Math PhD for Data Science — You Need to Stop Skipping the Boring Step

Jason Lau — Wed, 12 Aug 2026 03:08:07 +0000

Ask someone switching into data science what worries them and it's almost always the same thing: do I know enough math? So they spend weeks on gradient descent derivations and eigenvalues before they've ever wrangled a messy CSV. Then the job starts, a real dataset lands on their desk, and it turns out the model was never the hard part.

The hard part is everything upstream of it. Framing a vague question precisely enough to answer it. Checking whether the data can actually support that answer. Noticing the assumption that breaks silently instead of throwing an error. None of that needs research-level math — most of it doesn't need statistics at all, just the discipline to check before trusting. It needs the willingness to slow down exactly when it's tempting to jump to the model, because the model is the part that feels like progress.

Three moments from a fairly ordinary analytics project show what that looks like in practice

The question shows up vague, and STAYS vague
A stakeholder asks "are our customers happy?" — which is a request for a feeling, not something a query can return. Happy compared to what: last quarter, a competitor, what they expected at signup? Which customers — everyone, or just the ones active in the last 90 days? Measured by what — a survey score, a churn rate, or support-ticket volume, which could reflect a product bug as easily as unhappiness? The junior move is to pick a metric and start coding. The useful move is rewriting the question until two different analysts would agree on exactly what to compute — same population, same comparison point, same metric — even if their pulls differ by a rounding error. Nobody drills that rewrite explicitly; it doesn't sit next to "regression" and "clustering" in a syllabus, but it decides everything that follows it.
Somewhere in the pipeline, rows disappear and NOBODY notices
Say the next step is joining an orders table to a customers table:

merged = orders.merge(customers, on="customer_id")
print(len(orders), len(merged))   # 48,201  →  44,987

Three thousand orders just vanished — every one with a customer_id that didn't find a match on the other side. They might be test accounts. They might be guest checkouts. They might be exactly the segment the analysis was supposed to describe, quietly deleted by an inner join before anyone got to look at them. merge() doesn't warn either way; a silently biased dataset and a clean one produce the exact same "no errors" console output. The only defense is checking row counts before and after every join and being able to explain any drop.

Data type problems hide the same way. A column named signup_date sounds unambiguous right up until .dtype returns object instead of datetime64, and a sample of five values turns up '2024-01-15', '01/15/2024', '2024-15-01', and 'Jan 15 2024' sitting in the same column — three years of manual entry, a spreadsheet import, and an API migration, never reconciled. 01/15/2024 alone is ambiguous between January 15th and an invalid 15th month, depending on which locale wrote it. Parse that carelessly and some rows land on the wrong date, quietly skewing any monthly bucket or tenure calculation downstream. Catching it costs about five minutes: check .dtype, then eyeball a random sample of raw values before trusting what the column name implies. Skipping it costs a wrong number that someone else finds later.

A join doesn't just drop rows — it can multiply them, and a plausible-looking total hides it

Say the next step is tagging orders with any promo code they used, to break out revenue by month:

revenue_by_month = orders.merge(
  promotions,on="order_id"
).groupby("month")["revenue"].sum()
# reported total: $1,284,000 — actual total: $1,061,000

If even a handful of orders matched two promotion rows instead of one — a coupon logged twice, a duplicate entry from a batch re-run — the merge doesn't collapse them, it repeats that order's revenue row once per match. The total comes out $223,000 too high, and nothing about the output looks wrong: no error, no null, just a bigger number than reality. The fix costs nothing statistical — it's checking that the row count and the total after a join still match a number you trust from somewhere else, before either one gets reported.

None of these three moments required anything past intro-level statistics — most required none at all. Each one involved noticing something easy to miss and choosing to stop and check it rather than push on to the modeling step, which is the part that actually feels like work. That's closer to the real shape of an entry-level data science job than most course outlines suggest — the algorithms are documented, implemented, and one import away in scikit-learn; the dropped rows, the ambiguous date format, and the inflated total are not, and they're what a hiring manager is actually screening for whether or not the posting says so.

For anyone building toward a first role, that argues for a different practice list than "learn another algorithm":

Rewrite a vague business question into one with an unambiguous metric and comparison, before writing any code
Check row counts before and after every join or filter, and be able to explain any change
Inspect column dtypes and a sample of raw values before trusting what a column's name implies
After any join, check that both the row count and a key total still match a number you trust from elsewhere
Practice stating a finding's limitations in the same breath as the finding itself

None of it is glamorous, and none of it shows up as a line on a certificate. It's also the difference between an analysis that survives a second question from a skeptical stakeholder and one that quietly comes apart the first time someone re-runs it on next month's data.

SophiArch's Intro to Data Science course is built around exactly this — not another pass through the algorithm list, but deliberate practice framing questions, auditing data, and catching this class of mistake before it reaches someone else's desk.

The Most Dangerous Phrase in Analytics Is "The Data Speaks for Itself"

Jason Lau — Wed, 05 Aug 2026 08:02:13 +0000

The data speaks for itself is usually offered as a defense. It means: I didn't put my thumb on the scale, I just showed you what's there. It sounds like humility. In practice it's the opposite — it's a claim that the analyst's choices aren't part of the result, when they always are.

Data never speaks. Someone chooses the time window, the bucket size, the baseline, which outliers stay in, and which comparison gets drawn on the same axis. Those choices are what turn raw numbers into a chart anyone can read in five seconds. The phrase the data speaks for itself is what lets those choices pass without anyone — including the analyst — examining them.

Here's what that looks like in practice, and why naming the choice out loud is the actual discipline.

1. Truncated axis

ax.set_ylim(80, 100)   # "to make the trend visible"

A bar chart of conversion rate moving from 82% to 86% looks like a rounding error on a 0–100 axis. Truncate the y-axis to 80–100 and the same bars look like a dramatic surge. Neither chart is fabricated — every number on it is correct. The difference is entirely in a choice that's invisible unless someone asks what the axis range is and why.

Truncated axes aren't always wrong — sometimes the full 0–100 range genuinely hides a real, meaningful shift. The point isn't "never truncate." It's that the decision to truncate is doing real interpretive work, and "the data speaks for itself" is exactly the phrase that lets it go unstated.

2. Baseline nobody picked on purpose

df["growth"] = (df["revenue"] - df["revenue"].shift(12)) / df["revenue"].shift(12)

Year-over-year growth looks like a neutral, standard metric. It's a choice: this quarter compared to the same quarter last year, not last quarter, not a trailing average, not the pre-pandemic baseline. If last year had an unusual dip, this year's "growth" is partly an artifact of a low starting point — and the chart won't tell you that, because a percentage doesn't carry its own denominator's history along with it.

3. Outliers that got dropped "for clarity"

df = df[df["order_value"] < df["order_value"].quantile(0.99)]   # cuts the long tail

Trimming the top 1% before plotting a distribution is often reasonable — a few extreme values can flatten a histogram into something unreadable. But it's a modeling decision about what counts as signal versus noise, made silently, before the reader ever sees the shape of the full data. If those extreme orders are disproportionately from one customer segment, "clarity" just deleted the most important 1% of the story.

4. Comparison that implies causation without claiming it

"Users who completed onboarding had 3x higher retention."

Looking at the chart on the left, every word of this is true and it will be read as onboarding causes retention by nearly everyone who sees it.

What is left unmentioned are possible confounders, like for instance as shown on the right, the people who complete onboarding are typically also the people motivated enough to complete onboarding — and hence we can never establish for sure that the training caused anything.

The chart didn't lie. The framing did the arguing that implies causation when there may be none.

5. p-value treated as a verdict

stats.ttest_ind(group_a, group_b)   # p = 0.03 → "significant" → done

A p-value answers one narrow question — if there were actually no difference between these two groups, how likely would it be to see a difference this big just from random luck? A p-value of 0.03 means "about a 3% chance of seeing this by luck alone if nothing real is going on."

It says nothing about how big the difference is, whether it matters in practice, or whether the study was well-designed. It's a statement about coincidence, not about importance — and the 0.05 cutoff itself is just a convention, not a law of nature.

However, a p-value below 0.05 typically gets treated as an on/off switch: significant, ship it. When in reality, p-value is actually a statement about one specific null hypothesis, under one specific test, on one specific sample — not a verdict on whether the effect is real, large, or durable.

Reporting "p < 0.05" without reporting effect size, sample size, or how many other comparisons were run alongside this one lets a single threshold stand in for a judgment call about how much evidence is enough.

Take the example below of four studies (A, B, C, D) with roughly similar p-values (all < 0.05) but different effect sizes, measured using Cohen's d. Effect size is just "how big is the difference, really" — the gap between the two groups, scaled so it's comparable across studies. A small effect size means the two groups barely differ even if the math calls it "significant"; a large effect size means the difference is big enough to see with the naked eye.

The four studies in the chart above all clear the same p-value < 0.05 bar, but they're not telling the same story: Study D ran on 8,000 people and found a difference so tiny it's practically nothing — with a sample that large, even noise can become "significant." Study A ran on just 40 people and found a difference big enough to matter. Same headline, opposite substance.

That's why the p-value alone can't be the verdict — it only says a difference probably isn't zero, not that the difference is big enough to care about.

Why "just double-check the numbers" isn't the fix

Every example above involves numbers that are individually correct. Fact-checking the arithmetic won't catch any of them, because the distortion isn't in the math — it's in which math got chosen, and what got left off the chart. That's a different kind of review: not "is this number right," but "what would this look like if the axis, baseline, or trimming had been chosen differently, and why wasn't that shown?"

A defensible analysis — the kind that survives a skeptical stakeholder asking "wait, why does it look like that?" — means being able to answer yes to all of:

The axis range and why it was chosen would survive being stated out loud
The baseline or comparison point is named, not just implied by the metric's label
Any trimming, filtering, or exclusion is disclosed next to the result it affects
Causal language is reserved for claims that actually support causation
A significance result is reported with effect size and sample size, not p-value alone

None of this is about being more honest in some abstract sense. It's about treating every visualization and every summary statistic as an argument with premises — because that's what it is — and being willing to state the premises instead of letting "the data speaks for itself" stand in for them.

This is the discipline behind SophiArch's Statistics for Data Science course, which teaches distributions, hypothesis testing, and inference specifically through the lens of directing and auditing AI-generated analysis — including catching exactly this kind of framing choice before it reaches a stakeholder.

The 3 Kinds of Data Leakage That Make Your Model Lie to You

Jason Lau — Wed, 29 Jul 2026 03:16:55 +0000

You build a churn model. Cross-validation AUC is 0.91. You ship it. Real-world AUC is 0.76.

Nothing changed — same data, same algorithm, same infrastructure. The model just doesn't work as well as you measured it would. If this has happened to you, the most likely cause isn't a bad algorithm choice. It's data leakage: information from outside the training boundary reaching the model during development, producing an evaluation score that collapses the moment it has to generalize to genuinely unseen data.

Leakage is dangerous precisely because it's silent. The code runs. The numbers look good. Nothing throws an exception. The bug only shows up in production, weeks later, as a vague "the model's not performing like we expected" conversation.

There are three distinct patterns, and they are not equally easy to catch — which matters more than ever now that a growing share of preprocessing code is AI-generated or AI-assisted.

1. Fit-on-all: the one AI tools actually catch

This is the classic version, and it's mechanical enough that both static analysis and a decent code-review prompt can flag it: a transformer (scaler, imputer, encoder) gets fit on the entire dataset before the train/test split. The transformer has now learned statistics — mean, variance, category frequencies — from data that's supposed to be unseen. When you evaluate on the "test" set, it's been preprocessed using information from itself.

Here's the effect, measured directly rather than described:

import pandas as pd
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score

df = pd.read_csv("transactions_merged_features.csv")
X = df[["monthly_spend", "support_tickets", "tenure_days", "plan_encoded"]]
y = df["churned"]

# --- The leaked version ---
scaler = StandardScaler()
X_scaled_all = scaler.fit_transform(X)          # fit on ALL data, including test

X_train_l, X_test_l, y_train, y_test = train_test_split(
    X_scaled_all, y, test_size=0.2, random_state=42
)
model = LogisticRegression().fit(X_train_l, y_train)
auc_leaked = roc_auc_score(y_test, model.predict_proba(X_test_l)[:, 1])
print(f"AUC (leaked):  {auc_leaked:.3f}")   # 0.912

# --- The honest version ---
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

scaler_honest = StandardScaler()
X_train_scaled = scaler_honest.fit_transform(X_train)   # fit on train only
X_test_scaled  = scaler_honest.transform(X_test)         # transform only

model_honest = LogisticRegression().fit(X_train_scaled, y_train)
auc_honest = roc_auc_score(y_test, model_honest.predict_proba(X_test_scaled)[:, 1])
print(f"AUC (honest):  {auc_honest:.3f}")   # 0.841

Same data, same model, same random seed. AUC drops from 0.912 to 0.841 — a 7-point gap caused entirely by fitting the scaler before the split. At a business level, that's the difference between a model you'd confidently deploy and one you'd send back for more work.

The reason AI coding assistants can catch this one: it's a pattern-matchable rule — "does fit or fit_transform appear before train_test_split in the same variable's lineage?" Ask any capable AI assistant to review a preprocessing script for this specific issue and it will generally find it, because it's a syntactic property of the code, not a fact about your business.

2. Target leakage: the one that requires knowing your business, not your syntax

This is where AI code review quietly stops being useful, because target leakage isn't a code mistake — it's a feature design problem. The code is syntactically fine. The leakage is in what the column means.

# Feature audit — ask for each column: would I have this at prediction time?
feature_audit = {
    "tenure_days":          "YES — calculated from signup_date, known at any time",
    "monthly_spend":        "YES — last billing cycle is known",
    "support_tickets":      "YES — CRM records exist at prediction time",
    "plan_encoded":         "YES — current plan is known",
    "days_to_first_ticket": "NO — some customers haven't opened a ticket yet",
    "cancellation_flag":    "NO — only exists for customers already mid-cancellation",
}

cancellation_flag is the textbook case. The model "predicts" churn by noticing that churned customers have a cancellation flag set. That's not a prediction, it's a tautology — and it will produce a beautiful AUC in development, because the leaked feature is, definitionally, almost perfectly correlated with the label.

An AI assistant reviewing this code has no way to know that cancellation_flag is only populated after a customer has already initiated cancellation, unless that constraint is written down somewhere it can read — a schema comment, a data dictionary, a docstring. Column names that are suggestive (churn_date, days_since_cancellation) sometimes get flagged. Column names that are business-specific and non-obvious (at_risk_flag, populated by a CS rep's note that may or may not predate the churn event) will not.

3. Temporal leakage: the one that hides in aggregation windows

The third pattern is the hardest to spot in a code diff, because the leaking value is often computed correctly in isolation — the leakage is in the time window the aggregation covers relative to the prediction point.

Example: a 12_month_avg_spend feature used to predict whether a customer churned in month 3. The average is computed over the full 12 months — which includes months 4 through 12, all of which happened after the prediction point. The feature is real, the arithmetic is correct, and it's still leakage, because at the moment you'd actually need this prediction (month 3, for a live customer), months 4–12 haven't happened yet.

This is the one that survives code review most often, because there's no syntax cue at all — just a groupby().mean() that looks completely ordinary. Catching it requires drawing the prediction-point boundary explicitly and checking every feature against it:

Every feature derived from data on the wrong side of the prediction point — regardless of how predictive it looks in training — is leakage.

The one question that catches all three

For every feature, ask: at the moment I make this prediction for a live customer, would this value already exist?

If the answer is "no," or "only sometimes," the feature needs to be dropped or rebuilt using only historically-available data. This question doesn't require a tool — it requires knowing your data's timeline, which is exactly the part an AI assistant wasn't in the room for.

The structural fix for at least one of these

Fit-on-all leakage — pattern #1 — has an actual structural fix, not just a discipline-based one: sklearn.pipeline.Pipeline. Wrapping your scaler, imputer, and model in a single Pipeline makes it impossible to call fit_transform on the full dataset by accident, because the pipeline controls the fit/transform order for you. It doesn't help with target or temporal leakage — those require the feature audit above — but it closes off the one failure mode that's purely mechanical.

If you want the full walkthrough — building the Pipeline, composing ColumnTransformers for mixed-type data, and a systematic protocol for auditing AI-generated preprocessing code specifically — it's the subject of SophiArch's Feature Engineering & Pipelines course, including the lesson this article's timeline diagram and code examples are drawn from.

Your AI's EDA Looks Right. Here's How to Tell When It Isn't.

Jason Lau — Wed, 22 Jul 2026 02:51:22 +0000

Ask an AI coding assistant to run exploratory data analysis on a new dataset and it will produce, in seconds, something that looks like a competent analyst's first pass: .describe(), a correlation matrix, some distribution plots, a groupby or two, and a paragraph of narrative summarizing what it found.

The problem is not that this output is wrong. Often it's correct. The problem is that it looks identical whether it's correct or not — and the failure modes that make it wrong are exactly the ones a quick skim won't catch, because nothing throws an error and nothing looks incomplete.

Here are six patterns that show up constantly in AI-generated EDA, each one silently producing output that reads as clean.

1. Profiling before type conversion

# The AI commonly generates this order — the problem is invisible in the output
print(df.describe())                                    # order_date excluded — it's still a string
df["order_date"] = pd.to_datetime(df["order_date"])     # too late

.describe() silently drops non-numeric columns. If a date column is still sitting as a string object when you profile, it just... isn't in the summary. Nothing errors. You get a clean-looking table with one fewer column than you meant to check, and no indication anything was skipped.

The fix is ordering, not code complexity: type conversions belong in the very first block, before any statistic is computed.

2. Reaching for `.mean()` on a right-skewed column

AI assistants default to .mean() for basically every "typical value" question, because it's the statistically obvious first move. For revenue, spend, session duration — anything with a long right tail — that default quietly overstates what's typical:

df.groupby("channel")["revenue"].mean()   # a handful of large B2B orders pull this up

A groupby that reports mean without also reporting median, count, and std produces a number that's technically correct and practically misleading. The fix is cheap — always pull all four together — but it requires knowing to ask, since the AI won't flag its own choice of statistic as a judgment call.

3. `.dropna()` before you've profiled the missingness

df = df.dropna()          # applied early, "to make analysis cleaner"
# profiling happens on what's left

Profiling exists to characterize how and where values are missing — whether it's random, or concentrated in a specific segment, or correlated with another column. Drop the rows first and that pattern is gone before you ever looked at it. The output afterward looks complete. It's complete for a dataset that no longer represents the one you started with.

4. The silent subset filter

This is the one most likely to change your conclusions without you noticing:

df = df[df["status"] == "delivered"]     # ← added mid-script, nothing downstream is labeled

Every correlation, every groupby, every chart that runs after this line applies to delivered orders only — but nothing in the output says so. A stakeholder reading "42% of orders come from the enterprise channel" has no way to know that's 42% of delivered orders, unless someone happened to scroll up to a filter line with no comment attached to it.

5. Narrative summaries that quietly assert causation

AI-generated EDA often ends with a paragraph of plain-language commentary. That commentary is where causal language creeps in — "unit price drives revenue," "the strong correlation confirms X" — from analysis that only ever established correlation. The numbers above the paragraph are usually fine. The prose interpreting them is where scope creep happens, because narrative generation and statistical rigor are not the same task, even when the same model produces both in one response.

Read the numbers. Treat the narrative paragraph as a first draft to revise, not a finding to cite.

6. Treating "no issues found" as "the data is clean"

If you ask an AI to check for data quality issues and it reports none, that's not confirmation. It means the checks it ran didn't find anything — which says nothing about the checks it didn't run. Cardinality on string columns, structural missingness patterns, multivariate outliers: these don't show up unless something specifically goes looking for them.

All six patterns share the same shape: the output looks complete, and completeness is exactly what a quick review checks for.

Why "just review the code" isn't quite the answer

Reviewing AI-generated code before running it catches some of this — type conversions before statistics, mean vs. median, subset filters — because those are visible in the script itself. What code review alone won't catch is #5 and #6: causal language buried in a narrative summary, and the false confidence of a clean-looking "no issues found." Those require reading the output, not just the code, and holding it against what you already know about the domain.

A defensible EDA — AI-assisted or not — means you can answer yes to all of:

Type conversions happened before any statistic was computed
Missingness was profiled before anything was dropped
Every group summary includes count and spread, not just mean
No subset filter changed scope without being documented
Causal language has been replaced with correlational language where causation wasn't established
"No findings" was treated as "the checks I ran found nothing," not as "the data is clean"

None of this is really about AI. It's the same discipline that's always separated a defensible analysis from a plausible-looking one. What's changed is the speed at which plausible-looking output gets produced — which means the checklist matters more, not less.

This is the framework behind SophiArch's Exploratory Data Analysis course, including a lab where you're handed a full AI-generated EDA notebook and asked to find exactly these kinds of issues before they reach a stakeholder.

DEV Community: Jason Lau

Prompt Engineering Won't Survive — the Skill Underneath It Will

What actually died was a set of tricks tuned to specific models

The instability was already visible in how fragile the tricks were

What was actually being taught the whole time

References

Your RAG Pipeline Doesn't Have an Accuracy Problem - It Has an Evaluation Problem

A wrong answer and a right answer look identical

"RAG fixes hallucinations" is marketing, and there's a measurement to prove it

"Is it accurate?" is two questions wearing one trenchcoat

What an actual evaluation harness looks like

References

Clustering Isn't Discovery - It's a Hypothesis You Still Have to Test

Same data, different "discovery"

Aren't there any methods to decide?

Cluster on demographics may not mean different customer behavior

What is the correct approach to clustering?

References

You Don't Need a Math PhD for Data Science — You Need to Stop Skipping the Boring Step

The Most Dangerous Phrase in Analytics Is "The Data Speaks for Itself"

1. Truncated axis

2. Baseline nobody picked on purpose

3. Outliers that got dropped "for clarity"

4. Comparison that implies causation without claiming it

5. p-value treated as a verdict

Why "just double-check the numbers" isn't the fix

The 3 Kinds of Data Leakage That Make Your Model Lie to You

1. Fit-on-all: the one AI tools actually catch

2. Target leakage: the one that requires knowing your business, not your syntax

3. Temporal leakage: the one that hides in aggregation windows

The one question that catches all three

The structural fix for at least one of these

Your AI's EDA Looks Right. Here's How to Tell When It Isn't.

1. Profiling before type conversion

2. Reaching for .mean() on a right-skewed column

3. .dropna() before you've profiled the missingness

4. The silent subset filter

5. Narrative summaries that quietly assert causation

6. Treating "no issues found" as "the data is clean"

Why "just review the code" isn't quite the answer

2. Reaching for `.mean()` on a right-skewed column

3. `.dropna()` before you've profiled the missingness