Can Coding Agents Do Data Mining?
If you’d asked me a few months ago, “Can a Coding Agent do data mining?”, I would have said no. Data mining takes business intuition, statistical grounding, and the kind of feel you only get from getting burned a few times. However strong the model, it’s still just a tool.
A few real projects in recent months gave me pause. Two specific ones below.
Churn Diagnosis
The first was a churn diagnosis on lapsed members. The analyst team had already done a round.
They picked 5 typical churned users and went deep. The story looked clean: former active VIPs, listening to history and finance content in the months before leaving, all narrowing down to “just a few favorite hosts” right before they churned. The conclusion almost wrote itself: churned members are knowledge-type users, and the platform’s knowledge supply isn’t keeping up.
Was the conclusion right?
We had the Agent rerun it. It wasn’t starting from scratch. Over the past year we’d wrapped a few CLIs around the data platform and distilled out 5 skills:
- query: natural language in, structured results out, handles table selection, SQL generation, query execution
- segmentation: from a natural-language description, generates segmentation criteria (tags + behavior + time window), returns the matching user set, supports stratified sampling
- user profile: given a user_id, returns the tag set, long-term and short-term memory, and an AI-generated summary
- user behavior: given a user_id and time window, returns the full event sequence
- A/B test evaluation: given an experiment id, returns a full report and diagnostic conclusion
The Agent calls these skills directly to pull structured data. No SQL writing, no job scheduling, no dirty-data wrangling. All its attention goes to “looking at the data.”
Round one: 20 people, stratified, 10 knowledge-type + 10 entertainment-type. Pure knowledge-type came in at 10%. Round two: 100 people, stratified by region × activity level × payment history. Knowledge-type share dropped to between 2% and 7%.
When the 100-person sample came out, the first number that surprised me was 45%. Of these “churned” members, 45% were still monthly active 1 to 2 days. They hadn’t left the platform. They just stopped paying.
The second surprise was 3.5 years. We’d pictured churn as a matter of weeks or months. Nobody had stretched the view past 3 years. When the Agent ran the lifecycle chart, it pulled 10 years of history along the way, and the 3.5-year pattern surfaced on its own.
With those two numbers on the table, the “all knowledge-type” finding from the 5-person round was clearly sampling bias. Thinking back, if we’d stopped at the 5-person round (which we very likely would have), the entire recall strategy would have rested on a wrong premise. The Agent didn’t keep us from making that mistake. What it did was drive the cost of expanding the sample to near zero, which made “try one more round” a cheap choice.
Kids Business
The second project was a diagnosis on the kids business. The team wanted to know whether the product should change, and in which direction.
By default, an analyst would pull behavior data and look at what users are listening to. Most likely result: nursery rhymes, stories, Baby Bus, Mi Xiao Quan, Peppa Pig. A “what users are listening to” report. The business team politely says “thanks” and walks away not knowing what to do with it.
We let the Agent run with no constraint on where to start. Its first move was to pull playback distribution by hour. An analyst would do that too, but the Agent went further. For each hour, it pulled playback count, completion rate, session length, whether sessions got switched, whether searches happened.
One thing came out of that I didn’t understand at first. From 20:00 to 23:00, playback hit 35% of the day’s volume, the daily peak. But completion rate in that window was very low, while individual session length was very long (30 to 60 minutes).
Peak, long sessions, low completion. Each number alone reads fine. Together they don’t. The Agent put them next to each other in the report, and I sat with it for a moment before it clicked: users were falling asleep mid-playback. This isn’t a “content consumption” scenario. It’s a “sleep aid” scenario.
Once that thread was pulled, independent evidence stacked up. 42.7% of user profiles had tags like “sleep,” “putting to sleep,” “bedtime story.” Top search terms had “bedtime story” in the top five. App store reviews kept showing “play it for the kid every night.” All pointed to bedtime.
The original thinking: build a content app kids love using. After the diagnosis: build a sleep tool parents can use smoothly at their kid’s bedtime. Product form, interaction, content arrangement, all different.
Same project, another thing I hadn’t seen coming. I almost skipped past it in the report. In the search-behavior section, the Agent had spent a paragraph on misspellings like “Peppa Pig” written wrong. I thought it had gone off track. Reading on, it was actually chasing a hypothesis: a misspelling is a signal that the kid is operating the account directly, because parents don’t typo a well-known IP name like that. That signal can be used inside shared accounts to separate “parent operating” from “kid operating.” Since 86% of kids accounts are shared parent-and-kid usage, you need to split the behavior to optimize each side.
“Misspelling = kid signal” is the kind of hypothesis an analyst probably wouldn’t actively run, because the ROI looks bad. The Agent has no such concern. It runs cheap, so unreliable angles get a pass too. No signal, drop it. Signal, escalate.
Looking Back
After two projects, I started asking where the Agent does better than traditional mining. A few things came out.
One is sample size. Analysts who’ve been at it a while develop a reflex: “look at 5 first, then talk.” That’s reasonable, because human cost is high. The Agent drives that cost to near zero. You can just run 100 people, or 1,000. A lot of mining-side bias traces back to small samples. Small samples trace back to time pressure. Time pressure traces back to engineering overhead eating the budget. Untangle that chain and the floor of the work lifts.
One is hypothesis density. Analysts write code slowly, so they only run high-confidence hypotheses. Take “misspelling = kid signal”. Even when it crosses an analyst’s mind, they shut it down because the math doesn’t work. The Agent runs cheap, so it runs those too. Most produce nothing, get dropped. A few produce something, get escalated.
One is cross-metric combinations. An analyst who’s spent years on one business has a familiar toolkit (churn analysis, funnel, cohort, retention matrix). The templates aren’t wrong, but they narrow attention. The Agent doesn’t carry that baggage. It pairs and triples metrics more randomly. The kids “peak + long session + low completion” combination came out of that. Not in any standard template. Once it surfaced, the whole business positioning flipped.
The last one is not being trapped by business priors. An analyst who’s worked one business for years knows the common sense well, but common sense can be baggage. In the churn project, the business’s prior was “churn = leaving.” If the analyst takes that for granted, they might never look at churned users’ free-content data. The Agent doesn’t carry that prior. It runs on whatever it’s given. The 45% finding came out of that exact opening.
Cost
The Agent can run hypotheses in batches. Verification has to scale with it, otherwise we just push the cost of misjudgment downstream. The Agent runs dozens of hypotheses a day, and some are bound to look like signal but actually be noise. Right now we lean on multiple evidence sources cross-checking each other (profile tags, search terms, reviews each independently landing on the same conclusion), and rerunning on different samples and time windows holds up. But actually setting aside an independent sample for backtest, that step hasn’t been built into a skill yet.
Edges
The Agent doesn’t solve everything. Seeing the edges clearly is what makes it usable.
Scenarios first. Agent-driven mining fits complex, long-arc, cause-unclear problems. Churn and kids both qualify. Simple metric monitoring (where did the 3% DAU drop go?) is faster with traditional BI. If the data foundation is too thin (behavior logs and profiles incomplete), the Agent can’t pull from skills, and no matter how strong the model, there’s nothing to work with.
Even in a fitting scenario, several things still need a human.
Defining the business question still needs a human. “What’s going on with our members?” is vague when the business team says it. It takes the analyst and the business team together to translate it into a target the Agent can run on.
Interpreting the final conclusion still needs a human. The Agent surfaces 45% still listening, 35% in bedtime mode. What those numbers mean, whether to change the product based on them, what to change to: the Agent doesn’t know.
Lastly, the sedimentation of business knowhow still needs a human. Take the “everyone knows but nobody wrote down” kind of thing. If it doesn’t get deposited somewhere the Agent can reach (Context), the hypotheses it runs are stuck at common sense visible in public data.
Roles like data mining engineer, senior analyst, data scientist aren’t disappearing, but the work content is shifting. Writing scripts, looking at distributions, applying templates: skills + Agent handle those more fluently now. The human’s time moves toward setting direction, judging anomalies, finding cross-domain combinations.