Having a Data Scientist Write Code Is Like Having a Novelist Chisel Hieroglyphs Into a Cave Wall

The story still gets told. It just takes fifty times longer, and the chiseling was never the point.

At a $20 billion company, hand-authored code costs $31 million a year, about the entire data science payroll, and three quarters of that is business problems nobody got to. It costs each data scientist sixteen years of a thirty-year career.

The claim

A data scientist should hand-author no more than roughly ten percent of the code that carries their name. The remaining ninety percent should be generated, and the data scientist’s contribution to it should be specification and verification rather than authorship.

This is a claim about one activity, not about the discipline. Nothing here argues that data science should be automated. The opposite is closer to the truth: the rest of the work (deciding what question is worth asking, determining whether the data can answer it, choosing an identification strategy, detecting leakage, judging whether an effect is real or an artifact of the sampling frame, deciding what a result licenses a business to actually do) is too fractured, too context-dependent, and too consequential to delegate. That work is where a data scientist earns their loaded cost. Code authorship is not.

The argument is narrow and it is economic. Typing implementations of well-understood operations is the single most substitutable activity in the data science week, it consumes a share of that week that is indefensible on any accounting, and the substitute is now good enough that continuing to do it by hand is a discretionary expense that most organizations have not recognized as one.

What “coding” means here

The word is doing too much work in most discussions of this topic, so it is worth partitioning before modeling.

Code labor in a data science context decomposes into roughly four activities:

Authorship. Producing the implementation. The groupby with the right key set, the window function, the reshape, the merge with the correct join semantics, the cross-validation loop, the plotting call with the axis formatting the stakeholder asked for, the retry wrapper around the API pull. This is the target of the argument.

Debugging. Resolving the gap between what was written and what was meant. Shape mismatches, dtype coercion, silent index misalignment, off-by-one in a time window, the categorical that became an object column three transformations ago.

Environment and tooling labor. Dependency resolution, kernel restarts, package version conflicts, path handling, containerization, the ceremony of making an analysis run somewhere other than the machine it was written on.

Rework. Rewriting an implementation because the question changed, the source schema changed, or the first version was structurally wrong.

None of these four is analysis. All four are translation: moving an already-formed intent into a syntax a machine will accept. The intent is the valuable object. The syntax is a commodity, and it has been a commodity for some time; what changed is that a substitute finally exists.

Against this sits the work the argument explicitly protects: problem formulation, data provenance judgment, identification and design, feature semantics, validation, error analysis, calibration and decision-threshold selection, and communication of uncertainty to people who will act on it. None of that is code labor. Some of it is expressed through code, which is exactly the confusion this piece is trying to dissolve. Expressing a judgment through code does not make the typing the judgment.

Why data science is the special case

The general argument for delegating code authorship has a well-known counterweight: generated code must be verified, verification is a different and often slower cognitive activity than authorship, and the verification burden can exceed the authorship savings. This is a real mechanism and it is the reason the software engineering case is genuinely contested.

Data science is the domain where that counterweight is weakest, for a structural reason: the verification step already existed.

A software engineer who accepts a generated function acquires a new obligation. They must now read code they did not write, build a mental model of it, and satisfy themselves it is correct, work they would not have performed on their own code, because writing it was how they came to trust it. The verification cost is genuinely marginal. It is added.

A data scientist is in a different position. The correctness of a data science artifact is not established by reading it. It is established by interrogating its output. Did the join change the row count. Does the feature distribution match the source. Is the class balance what the query implied. Does the effect survive the placebo test. Are there timestamps after the prediction date sitting in the training set. Is the metric computed on the population the stakeholder means. A competent data scientist performs every one of these checks on code they wrote themselves, by hand, from scratch, because hand-authorship confers no protection against any of these failure modes. Writing a leaky feature yourself does not make it less leaky.

The verification apparatus is therefore already built, already staffed, and already a mandatory line item. Delegating authorship does not add a validation obligation to a data science workflow. It adds, at most, a modest increment to an obligation that was always there.

This is the pivot the whole argument rests on, and it is worth stating in its sharpest form: in software engineering, AI-generated code creates verification debt; in data science, verification was already the job. The marginal cost of trusting a generated implementation is therefore far lower in data science than the general discourse implies, because the baseline was never trust in the first place.

There is a second, less comfortable observation supporting the same conclusion. The premise that hand-written data science code is reliable does not survive contact with the evidence. A large-scale study of 1.4 million Jupyter notebooks on GitHub found roughly a quarter executed without error, and around four percent reproduced their own recorded outputs. A separate analysis of published notebooks that were executable in principle found that 73 percent could not be reproduced without a human guessing at the original cell execution order, and that the overwhelming majority did not state their dependencies at all. This is the artifact base produced by hand, by trained practitioners, under professional conditions. The standard that generated code is being held to is not the standard hand-written code meets.

The time model

The model that follows is transparent, parameterized, and easy to disagree with, which is the intent. Every number is an assumption and each one is stated.

Setup

Let a delegated coding task cost, as a fraction of the time the same task would take under hand-authorship:

T_ai / T_manual = σ + ρ + p·r

where

σ: specification cost. The time to state the task precisely enough to be executed: schema, semantics, edge cases, output contract. This rises under delegation, and should.
ρ: marginal verification cost, expressed as a fraction of manual authorship time. The critical modeling choice, following directly from the previous section: ρ counts only verification above what the workflow already required. In software engineering ρ is large because the baseline is near zero. In data science the baseline is already high, so ρ is small.
p·r: expected repair cost. Probability the generated implementation is wrong in a way the checks catch, times the cost of correction.

Delegation pays when σ + ρ + p·r < 1.

Let α be the share of code tasks that are delegatable at all, and C the share of the working week consumed by code labor.

Reclaimed share of week = C · α · (1 − σ − ρ − p·r)

Parameters

C = 0.55. Code labor at 55 percent of a productive week. This is a synthesis rather than a measurement, and it is deliberately mid-range. Anaconda’s time-allocation survey put data preparation at roughly 45 percent of the week with cleaning and organizing alone above 26 percent; earlier CrowdFlower figures ran to 60 percent on cleaning and organizing and around 80 percent when collection and labeling were included; Kaggle’s narrower definition produced figures near 15 percent. The honest range across definitions is 25 to 80 percent. Adding implementation, debugging, environment labor, and rework to the preparation figure and landing at 55 percent is a defensible center. Substitute your own; the model is linear in C.

α = 0.90. Nine in ten code tasks in a data science workflow are delegatable. This is high because the distribution is heavily weighted toward operations that are standard in form and specific only in their parameters: reshapes, joins, aggregations, resampling, splits, encodings, plotting, metric computation. The residual tenth covers genuinely novel algorithmic work, performance-critical inner loops, and code whose structure is itself the research contribution.

σ = 0.15, ρ = 0.30, p·r = 0.10. Central case. Specification costs 15 percent of what authorship would have; marginal verification 30 percent; expected repair 10 percent. Total ratio 0.55, implying a 45 percent time reduction per delegated task.

Loaded cost $176/productive hour. A senior data scientist at $180,000 base loads to roughly $300,000 at the standard 1.65× multiplier, against approximately 1,700 productive hours per year. Recruiting-inclusive first-year loaded cost for mid-to-senior US hires is estimated at $190,000 to $370,000, and a Bay Area staff scientist with equity clears $400,000. At $300,000 loaded, an hour of that person’s time costs the company $176. The model scales linearly: substitute $118/hour for a $200,000 generalist or $235/hour for a $400,000 staff hire.

λ = 2 to 5. The value multiplier on a reclaimed hour, discussed in its own section below. This is the least certain parameter in the model and is reported as a range rather than a point estimate.

Results

Gross exposure first. Before any reduction is applied, a ten-person team at $300,000 loaded spends 22 hours per person per week, 9,350 team-hours annually, and $1,650,000 per year on code labor. That is the number on the table. Everything below is a question of how much of it is recoverable.

Under the conservative case (σ=0.25, ρ=0.50, p·r=0.20, α=0.70), code labor falls only 3.5 percent: 0.8 hours a week, $58,000 a year across the team. Under the central case, it falls 40.5 percent: 8.9 hours per person per week, 3,787 team-hours, $668,000 recovered, the equivalent of 2.2 additional data scientists. Under the aggressive case (σ=0.10, ρ=0.20, p·r=0.05, α=0.95), 61.7 percent: 13.6 hours a week and $1,019,000.

The central case reclaims 8.9 hours per person per week, better than a full working day, every week, from every member of the team, equal to 2.2 additional data scientists at zero marginal headcount cost. At current first-year loaded hiring costs of $190,000 to $370,000 per head, that capacity would cost between $420,000 and $815,000 to buy in the market, assuming the candidates exist.

The opportunity layer

The table above understates the loss, and it understates it in the direction that matters most.

It values a reclaimed hour at $176, which is what the hour costs. That is cost avoidance, and cost avoidance is the least interesting thing happening here. The premise of the data scientist role is that certain hours produce value substantially above their cost, and the entire justification for paying $300,000 rather than $90,000 is the expectation that those hours will be spent on judgment rather than transcription. When they are spent on transcription instead, the company does not merely waste $176. It forgoes the return that hour was purchased to generate.

Two independent anchors bound the size of that gap.

The substitution price. Code labor has an observable market clearing price, and it is not $176 an hour. Offshore data talent bills at $15 to $40 per hour. US freelance junior data practitioners bill $60 to $90. The gap between the analyst and data scientist base salary, roughly $86,000 against $128,000, is the market’s own estimate of what the judgment component is worth, and it is not paid for the ability to write a groupby. On the substitution anchor alone, before any value argument is made, an organization is paying a two-to-four times premium for hours of work that clear far below what it is paying.

The value differential. Let λ be the ratio of value produced per hour of high-leverage work to value produced per hour of code labor. Code labor produces value at approximately its substitution cost, because it is substitutable; that is what substitutable means. Problem formulation, identification strategy, leakage detection, and the judgment of whether a result licenses a decision have no substitute at any price, which is why the role is compensated the way it is. λ between 2 and 5 is the defensible range. It is the softest number in this model and it is reported as a range for that reason.

For the central scenario’s 3,787 reclaimed team-hours:

At λ=2, the redeployed hours are worth $1,337,000, of which $668,000 is opportunity gain above simple cost recovery. At λ=3, $2,005,000 and $1,337,000. At λ=5, $3,341,000 and $2,673,000.

At λ=3, the annual cost of hand-authorship to a ten-person team is $2.0 million: a $1.65 million gross line item, of which $668,000 is directly recoverable and roughly $1.34 million is forgone return on hours that were bought for something else.

This is the number that should be in front of an executive, and it is worth being explicit that the salary arithmetic is the small half of it.

Throughput

The same result restated as capacity. If code labor is 55 percent of the cost of producing an analysis and it falls by 40.5 percent, the cost per analysis falls to 0.78× baseline, and analytical throughput rises to 1.29× at constant headcount. Under the aggressive case, 1.51×.

For an organization whose analytics function is a decision bottleneck, this is the number that matters more than either the salary arithmetic or the opportunity layer. A 29 percent increase in experiments run, hypotheses tested, and questions answered per quarter compounds. A compensation line item does not.

The personal cost

The same model, run against a career rather than a fiscal year.

Code labor at 55 percent of the working week is 16.5 years of a 30-year career spent converting intent into syntax. The delegatable portion, the 22.3 percent of the week the central case reclaims, is 6.7 years. Not six point seven years of tedium distributed thinly enough to ignore, but the equivalent of six and a half continuous years at a keyboard, performing an operation with a known substitute, by someone hired for something else.

For an individual practitioner this is the more persuasive form of the argument, and it does not depend on the employer capturing any of the value.

Cost of the substitute

Per-seat pricing for the relevant tools runs from roughly $20 to $200 per user per month. For ten seats, against the central case:

At $100 per seat per month, or $12,000 a year for ten people, the return is 56× on direct cost recovery alone, and 167× including the opportunity layer. At $200 a seat, 28× and 84×. At $500 a seat, well above current market, still 11× and 33×.

Even at $500 per seat per month, well above current market, and even counting only direct cost recovery while ignoring the opportunity layer entirely, the return is eleven to one. Tooling cost does not meaningfully participate in this decision. Organizations treating per-seat license approval as the primary control point are optimizing a rounding error against a seven-figure line.

The enterprise case: the unit cost of a typing data scientist

The team-level model prices the hours. It does not price what the hours were supposed to produce, and at enterprise scale that is the entire question. A data scientist heads-down on the implementation of one model is not merely an expensive typist. They are a decision the company is not making, a business problem that stays unsolved for another quarter, and a draw from a heavy-tailed distribution that never gets taken.

The unit

The loss attaches to the data scientist, not to the balance sheet. Revenue determines how invisible the number is; headcount determines how large it is. So the model is built per person and multiplied out.

Capacity is the operative quantity. One data scientist is one FTE-year. A substantive analytical project (a demand forecasting rebuild, a pricing model, a churn intervention, a fraud detection system, a supply chain optimization) consumes on the order of 1.5 FTE-years of data science time from framing through deployment. Reclaiming 22.3 percent of the week under the central case multiplies effective capacity by 1.287, which is 0.19 additional analytical projects per data scientist per year.

What a project is worth

This is the load-bearing assumption, and the distribution matters more than the mean, because analytical project value is savagely heavy-tailed. Most projects produce nothing. A minority produce moderate recurring value. A small number change a P&L line.

Three quarters of attempts are never deployed or produce no measurable lift. Twenty percent deliver a moderate process improvement worth roughly $1.5 million in recurring annual value. Five percent are transformational (a repricing, a change to the cost structure, a genuinely new capability) worth on the order of $20 million a year.

Expected value per attempt: $1,300,000.

The 75 percent failure share is deliberately conservative and is roughly consistent with the widely cited claim that 85 to 90 percent of machine learning models never reach production, a figure that circulates far more confidently than its provenance supports, tracing largely to a 2019 trade-press estimate and subsequent analyst commentary rather than to a controlled study. Treating three quarters of attempts as worthless is the defensible version of that claim, and it is the conservative direction: a higher deployment rate raises every number below.

The moderate and transformational values are calibrated to enterprise scale and hold reasonably across the $10 billion to $100 billion revenue band. At $20 billion, a $20 million recurring outcome is one tenth of one percent of the top line: a single point of margin on a mid-sized product line, or a two percent improvement in inventory carrying cost. These are not heroic figures. They are ordinary outcomes for a deployed enterprise model.

The unit cost

Per data scientist, per year: $66,825 in directly recoverable code labor, plus $248,376 in value forgone on 0.19 unattempted projects. Total: $315,201, or 105 percent of fully loaded cost.

Every data scientist a company employs costs it roughly $315,000 a year in hand-authored code, slightly more than their entire loaded salary, in work they never got to.

That is the portable form of the argument. Multiply by headcount. The opportunity cost runs 3.7 times the direct cost recovery, which means the payroll waste, the number most organizations would reach for if asked to price this, is the smaller half by a wide margin. Companies are paying for their analytics function twice: once in salaries, and a second time in the work those salaries were meant to produce and did not.

Worked at scale

A company at $20 billion in revenue, roughly 40,000 employees at typical revenue-per-head, with 100 data scientists at $300,000 fully loaded:

Data science payroll runs $30 million, of which $16.5 million is code labor. Direct cost recovery is $6.68 million. Nineteen projects go unattempted, worth $24.84 million. Total annual cost of hand-authorship: $31.52 million.

Why it is invisible

$31.5 million against $20 billion is 0.158 percent of revenue. That is the entire explanation for why this persists. It never appears as a variance, never triggers a review, never shows up in any line item anyone owns. Nothing in a standard financial reporting structure has a field for projects not attempted. The loss is real, it is large in absolute terms, and it is structurally invisible to every instrument the company points at itself.

Scaling revenue does not change this, which is the point. Because the loss tracks headcount and headcount tracks revenue, a $100 billion company with 500 data scientists loses $158 million a year, and the same 0.158 percent. The number grows without ever becoming visible.

What does move it is data science density, and this is where an organization can locate itself:

At the top of that range the loss approaches two thirds of a percent of revenue, which is the threshold where it would begin to show up in a margin analysis. That range also describes, not coincidentally, exactly the organizations that adopted delegation first.

The tail is the real argument

The expected-value calculation understates the case, because it averages over a distribution whose importance is concentrated in its tail.

At 67 attempts per year with a 5 percent transformational rate, a hundred-person organization expects 3.3 transformational outcomes annually. At 86 attempts, 4.3. The delegation decision is worth roughly one additional transformational project per year, approximately $19 million in expected recurring value from that tier alone.

The framing that matters to an executive is not that nineteen average projects were lost. It is that the company reduced the number of draws it takes from a distribution where the whole return lives in the tail. Analytical portfolios are venture portfolios. Reducing attempts by 22 percent does not reduce returns by 22 percent; it reduces the probability of holding the outcome that justifies the entire function.

Cycle time

A secondary effect, one-time but material. Compressing 22.3 percent of the work out of a project timeline moves an 18-month initiative to 14 months and a 12-month initiative to 9.3. Across roughly 17 deployed projects a year at an average recurring value of $5.2 million, four months of earlier realization is on the order of $29 million pulled forward in the transition period. In a competitive market where a pricing or forecasting advantage is contested, arriving four months earlier is not merely a discounting benefit.

Sensitivity

The expected value per attempt is the parameter to argue with, and the one where reasonable people will differ by a factor of five.

At a pessimistic $500,000 expected value per attempt, the loss is $162,000 per data scientist, $16.2 million at a hundred, 0.081 percent of revenue. At the central $1.3 million: $315,000, $31.5 million, 0.158 percent. At an optimistic $3 million: $640,000, $64.0 million, 0.320 percent.

Across the full parameter range, the annual cost of hand-authorship runs between roughly $160,000 and $640,000 per data scientist per year. At every point in that range it exceeds the direct payroll recovery by a multiple, and at every point it stays small enough as a share of revenue to go unnoticed indefinitely.

Break-even: what would have to be true

The model’s honest content is in its failure region. Delegation is a net loss when σ + ρ + p·r exceeds 1. Holding expected repair at 0.10:

The surface is overwhelmingly positive. Delegation fails only where specification cost is very high and marginal verification approaches or exceeds half of authorship time. That combination describes a specific and identifiable regime: novel algorithmic work in a codebase with implicit conventions the specification cannot economically convey, where correctness cannot be established from output. It is a real regime. It is also, by any reasonable estimate, the small minority of data science code, which is the quantitative content of the ten percent figure.

The practical implication is directional. The lever with the highest return is not tool selection but σ, the cost of specification. An organization whose data is documented, whose schemas are discoverable, whose metric definitions are written down, and whose conventions are explicit operates at low σ and captures most of the surface. An organization where the semantics of a column exist only in a senior analyst’s memory operates at high σ and will conclude, correctly for its own circumstances, that delegation does not work. This is a data governance finding wearing a productivity costume, and it explains most of the variance in reported outcomes.

The tool landscape

The category has bifurcated, and the distinction that matters for this argument is not feature-level. It is where the code goes and who owns it afterward. A tool that produces inspectable, version-controllable, re-runnable code supports the thesis. A tool that produces an answer without a durable artifact does not; it substitutes for the analysis rather than for the authorship, which is a different proposition and not the one being argued here.

Agentic code environments

Claude Code, OpenAI Codex, and Cursor operate over a repository or working directory with file-system access, multi-step execution, and test-and-iterate loops. For data science, the relevant capability is not autocomplete but the ability to take a specification, write a script, run it, read the traceback, and correct, which is precisely the debugging quadrant of code labor. GitHub Copilot remains the broadest-deployed IDE assistant and has moved toward agentic operation. All four produce ordinary files under version control, which is the correct default for anything that will be maintained.

Notebook-native assistants

Google’s Data Science Agent in Colab generates a full notebook (cleaning, exploration, plotting, baseline modeling) from a dataset and a stated objective. Deepnote and Hex embed generation directly in a collaborative notebook surface; Hex’s Magic produces SQL and Python inline and its notebook-to-app publication path removes a category of downstream engineering labor entirely. MLJAR Studio is notable as the practical option for fully local operation where no code or data may leave the environment.

These fit the exploratory phase well, where the artifact is disposable by design and the verification loop is tight and visual. They fit production poorly, for the reasons the reproducibility literature has documented for a decade.

Warehouse-native

Databricks Assistant and Genie, and Snowflake Cortex Analyst and Cortex Agents, generate against the catalog where the data already sits. The structural advantage is σ: schema, types, and lineage are available to the generator without being restated, and the governance perimeter does not move. For organizations where data movement is the compliance constraint, this is the only category that clears it without self-hosting.

Conversational analysis

Julius, ChatGPT with code execution, and Claude’s analysis capability accept a file and a question and return an answer with code behind it. Lowest barrier, genuinely useful for ad hoc work, and the category where the artifact question bites hardest: an answer without a re-runnable, reviewed artifact is not an analysis a business should act on, however correct it happens to be.

Reading the category honestly

Two calibrations are worth carrying into any procurement conversation.

First, vendor use of the word agent spans a wide range, from natural-language-to-SQL translation to genuinely autonomous multi-step investigation, and Gartner’s 2026 guidance on agentic analytics flags the gap between marketing and behavior as the central evaluation problem in the category. Evaluate on artifacts produced, not on the noun in the datasheet.

Second, autonomous end-to-end analytical capability remains materially behind autonomous implementation capability. On DABStep, a set of 450-plus multi-step analysis tasks drawn from a real financial analytics operation, leading agents scored under 15 percent on the hard split at publication, with subsequent frontier models reaching roughly the high thirties. That gap is the empirical form of this article’s boundary: these systems write the code well and cannot yet be trusted to decide what the code should establish. Which is the division of labor being proposed.

Operating discipline

The thesis is a resource allocation claim, and resource allocation claims fail in implementation more often than in principle. Four practices separate teams that capture the model’s central case from teams that land in the conservative column.

Specify the contract, not the code. The unit of delegation is a stated output contract: input schema, output schema, join cardinality, null semantics, expected row count, invariants that must hold. Teams that prompt with a description of the desired code get code. Teams that prompt with a description of the acceptable region get correctness they can check. This is the σ term, and it is the highest-leverage habit in the set.

Make the checks executable and cheap. The model’s ρ term collapses when verification is automated. Row-count assertions after joins, schema contracts on every boundary, distribution comparisons against source, a leakage check on temporal features, a seeded fixture that must reproduce. Every one of these is itself delegatable, and building them is the highest-return use of the first hours reclaimed.

Never delegate the question. The specification, the identification strategy, and the interpretation stay with the data scientist. This is the ten percent, and it is not a residual; it is the entire justification for the role. A generated implementation of the wrong analysis is worse than a hand-written one, because it arrived faster and looks more finished.

Keep the artifact. Generated code goes into version control, gets reviewed, and runs from a clean environment. Reviewed generated code is a better asset than unreviewed hand-written code, and the reproducibility literature is unambiguous about which of those the field has been producing.

The recommendation

Data science teams should target hand-authorship at ten percent of code produced and should treat any figure materially above that as a measurable, priced inefficiency rather than as craft.

The evidence for the position is not that generation is flawless. It is that the alternative is worse than its reputation, that the verification apparatus data science requires was built long before generation existed and does not need rebuilding, and that the arithmetic is not close. A ten-person team spends on the order of $1.65 million a year converting intent into syntax, of which roughly $668,000 is directly recoverable at a tooling cost under $25,000. Per data scientist, the practice costs approximately $315,000 a year, slightly more than a fully loaded salary, of which three quarters is not payroll waste at all but business problems that went unsolved because the people hired to solve them were writing implementations by hand. At a hundred data scientists that is $31.5 million annually, and it scales with headcount without ever rising above a fifth of a percent of revenue, which is precisely why it has survived unexamined. The recovered capacity flows back into the parts of the discipline that are too fractured and too consequential to hand to anything else.

The organizations that will not capture this are identifiable in advance, and their obstacle is not the tooling. It is that their data has no documented semantics, so specification is expensive, so delegation genuinely does not pay. That is a diagnosis worth having on its own terms. It is also a much older problem than this one.

References

Anaconda. State of Data Science. Time-allocation figures, 2020 edition.

Anthropic. Economic Index report series, 2025–2026. Directive task delegation rising from 27% to 39%. https://www.anthropic.com/research/anthropic-economic-index-january-2026-report

Adyen and Hugging Face. DABstep: Data Agent Benchmark for Multi-step Reasoning. arXiv:2506.23719. https://arxiv.org/abs/2506.23719

dbt Labs. State of Analytics Engineering, 2024 and 2025 editions. Data quality as most prevalent practitioner problem, 57% and 56%.

Gartner. Market Guide for Agentic Analytics, 2026.

Gartner / VentureBeat. Widely circulated estimates that 85–90% of machine learning models never reach production. Provenance is weak; the figure traces largely to a 2019 trade-press estimate and subsequent analyst commentary rather than a controlled study, and is used here only as a directional check on a conservative assumption.

RAND Corporation. Research on root causes of AI project failure, cited alongside Gartner in the 80–85% failure range.

Google Cloud / DORA. 2025 State of AI-assisted Software Development. 90% adoption; 80%+ perceived productivity gain; 30% reporting little or no trust in generated code; AI associated with increased throughput and increased delivery instability. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

KORE1. Cost to Hire a Data Scientist, 2026. First-year loaded cost $190,000–$370,000 for mid-to-senior hires.

Pimentel, J.F. et al. A Large-Scale Study About Quality and Reproducibility of Jupyter Notebooks. MSR 2019. 1.4M notebooks; 24% executed without error; ~4% reproduced original results.

Wang, J., Li, L., Zeller, A. Assessing and Restoring Reproducibility of Jupyter Notebooks. ASE 2020. 936 executable notebooks; 73% not reproducible without inferring execution order. https://ieeexplore.ieee.org/document/9286024

Wang, J., Li, L., Zeller, A. Restoring Execution Environments of Jupyter Notebooks. ICSE 2021. ~94% of notebooks do not document dependencies. https://arxiv.org/pdf/2103.02959

US Bureau of Labor Statistics, Occupational Employment and Wage Statistics. Data scientist median wage, $112,590 (May 2024 OES).

Built In / KORE1. Data analyst vs. data scientist average base compensation, approximately $86,000 against $128,000. https://www.kore1.com/data-scientist-salary-guide/

Second Talent. Freelance Data Scientist Hourly Rate, United States, 2026. US freelance range $60–$500/hr; offshore comparison rates. https://www.secondtalent.com/resources/freelance-data-scientist-hourly-rate-us/

Cadence. Data Scientist Salary 2026. Fully-loaded cost at approximately 1.65× base in the US. https://cadence.withremote.ai/blog/data-scientist-salary-2026

About the Author

Brian Curry is a Kansas City–based AI Strategist, Marketing Economist, and Applied Researcher. He drives Vector1, a personal open-source research initiative advancing marketing economics, causal inference, cognitive AI architectures, and the economics of intelligent automation.

He has led advanced data science and analytics initiatives across major enterprises including Koch Industries, Tractor Supply, Hallmark, Garmin, and AT&T. His work applies economic thinking and causal inference to connect marketing investment to outcomes, operational decisions to economic value, and AI adoption to competitive advantage.

Key Research & Open-Source Projects (GitHub: @Bodhi8):

PyCausalSim — A Python framework for causal discovery and inference through simulation. Enables testing of counterfactual scenarios to identify true structural drivers.
Papilon — A complex system and causal discovery library for Media Mix Modeling (MMM) and adaptive systems.
Regimecast — Applied research and tooling for time-series regime detection and forecasting.
CarryNet — Open-source research and modeling focused on commodity carry trade analysis.
Foodmesh-ml — Machine learning, optimization, and simulation framework for modeling distributed food systems.
Memory-Node Encapsulation (MNE) — A cognitive AI architecture and novel data structure for artificial episodic memory.
The Autonomy Economy — A macroeconomic framework projecting the dual impacts of massive productivity growth and extreme price deflation in an AI-automated world.
Meaning-Flow — Research focused on semantic content modeling and automated coverage gap analysis.

Contact: brian at vector1.ai | Vector1 | GitHub | LinkedIn

This article may be shared with attribution under Creative Commons Attribution 4.0 International (CC BY 4.0).