AI-Assisted Coding Moved the Hard Part of Data Science to Specification
AI-assisted coding did not remove the hard part of data science — it changed where the hard part lives. For data scientists, it moved to specification.
TL;DR: AI-assisted coding did not remove the hard part of data science — it moved it. The bottleneck is no longer writing code from scratch; it is specifying exactly what must be built, validated, and avoided. The typing burden drops. The thinking burden does not.
Visual Summary
The Problem
For many data scientists, the bottleneck used to be: "Can I write this code from scratch?" With AI-assisted coding, that is rarely the hard part anymore. The demanding question has shifted to: "Can I specify exactly what must be built, validated, and avoided?" That is the useful part of what people call vibe coding for serious data work. AI can generate code quickly — but it can only generate what you are able to describe precisely.
The Approach
I let the assistant accelerate the implementation layer — when the request is precise enough to constrain the output:
Optuna objective
Write an Optuna objective for LightGBM with stratified cross-validation, pruning, and early stopping.
Polars feature pipeline
Build a Polars pipeline for grouped rolling features that stays expressive and fast on production data.
FastAPI serving layer
Wrap a scikit-learn pipeline in FastAPI with input validation before it reaches prediction code.
SHAP first pass
Produce a first version of a SHAP analysis or a monitoring check to surface where the model behaves unexpectedly.
Where the assistant stops being useful is judgment. It cannot reliably decide:
Feature validity
Whether a feature is actually available and valid at prediction time, not just in the training data.
Validation design
Whether the validation split reflects how the system will be deployed in production.
Temporal leakage
Whether future information is leaking into the training window and inflating apparent performance.
Business constraints
Which constraints and failure modes the business actually cares about when the model ships.
Output correctness
Whether a plausible-looking output is actually correct — working code is not proof of correct reasoning.
Better prompting is better specification. A vague request such as "build a churn model" leaves the target, split, metrics, and constraints implicit. A useful specification states them: a time-based split, PR-AUC as the objective, post-event features excluded, and calibrated probabilities returned.
Outcome
The shift is not from coding to "just prompting." It is from memorizing syntax to writing better specifications — the data, the constraints, the validation logic, the failure modes, and the expected output. AI makes implementation faster, but judgment still determines whether the implementation deserves to ship. The typing burden drops. The thinking burden does not.
Key Takeaway
Design insight: AI-assisted coding did not remove the hard part of data science — it moved it from typing syntax to writing specifications. The best prompt is a precise statement of data, validation logic, constraints, and expected output. AI accelerates implementation; judgment decides what ships.
FAQ
What is the key takeaway from this post about AI-assisted coding?
AI-assisted coding moves the hard part of data science from typing syntax to writing specifications. AI makes implementation faster, but judgment — feature validity, validation design, temporal leakage, business constraints — still decides whether the result deserves to ship.
How does AI-assisted coding change the data scientist's daily work?
The bottleneck shifts from "can I write this code from scratch?" to "can I specify exactly what must be built, validated, and avoided?" AI accelerates boilerplate, scaffolding, and iteration; the thinking burden does not drop.