A long lightning lesson, led by Shane with both co-founders on the call, arguing that Claude Code with Claude Opus 4.6 can now run most of an analyst's mechanical work end to end: framing, SQL, validation, charts, narrative and deck. The condition is that it is built as a system of agents, skills and stored knowledge that its owner teaches like a new hire. The lesson ends on a method and a career claim. Point the system at your own domain, where you can validate its output in seconds, correct it until its mistakes stop recurring, and spend the time you earn on thinking rather than mechanics. Because only you can validate your own work that fast, Shane argues, only you can automate yourself.
Why now. Shane says the session was moved up about a month after the three co-founders took time off their day jobs to test Opus 4.6 in person and found it well beyond earlier models. He frames the goal against layoff headlines: replace tasks, not people. A poll on what share of a team's questions get answered with validated numbers drew answers from 20% to 80%, none at 100%. He puts the typical split of analysis time at 80% mechanics and 20% thinking. Companies that use AI only to multiply mechanics, or to shrink headcount at the old ratio, he says, are getting it wrong; the aim is 80% thinking. Through the previous year, he says, Claude Code worked like "a really fast intern who needed constant supervision": a three-day question might take one day, but with a person in the loop throughout. The change he claims for Opus 4.6 is that it can carry the whole workflow and recover from errors. It still picks a wrong column or misreads a business rule, but these are the mistakes of a new analyst's first weeks, and they are cheap to document so they do not recur.
How Claude Code differs from chat. Chat has a brain, Shane says, and Claude Code also has hands: it reads files, writes and runs Python and SQL, sees the output and decides what to do next. The central artifact is the CLAUDE.md file, an onboarding doc that tells it who it is and what the data looks like, reread at the start of every session. He prefers Claude Code over alternatives for its subagents, while conceding he has not tested competitors recently. He says the analytical habits come from training it on the team's five-week course repo — dozens of hours of framing, metrics and storytelling material — restructured into agents and skills, and that nothing of this comes out of the box.
The demo. On a synthetic Amazon-like e-commerce dataset of 50k users, 13 tables and a year of data, Shane first asked Claude to summarize the repo and draw its workflow, then to describe the dataset. It volunteered gotchas: use sessions rather than the large events table, and cast float columns to integers before joins. It also suggested next questions. Overall NPS came back at +42.3; Shane had it explain the metric and its sources, a check he says he always runs. Broken down by segment, Plus members scored +54 and free users +30. Asked to explain detractors and validate against other data, it cross-checked the support-tickets table, and it also noted that half the "detractor" comments were positive because the synthetic comments were randomly assigned. A time view found a payment-ticket spike in late May and early June. Asked what to do next, it recommended finding the cause. Parallel subagents checked hypotheses, ruled out an experiment, and found iOS app v2.3, deployed June 1, behind 465 tickets, with 100% of v2.3 payment tickets coming from iOS. A chart-reviewer agent caught an annotation colliding with a subtitle and fixed it, which Shane attributes to building the Storytelling with Data principles into its skills. The deck-creator agent and a presentation-theme skill then produced a deck. It ran from context, through a 24-point structural NPS gap and a fourfold spike from one release, to three actions: a postmortem, automated payment-flow alerting (the incident ran three weeks), and investigation of wider free-tier friction. He also showed an overnight run on why conversion fell four points from Q1 to Q2. It took about 45 minutes and concluded that most of the decline was a mix shift from user-base growth, a Simpson's paradox, not a broken funnel. Shane cautions that he would not pass on every recommendation, and that every number must be validated before anything is sent.
The architecture. The full pipeline frames the question and explores data in parallel, converts questions into hypotheses, checkpoints with the user (skippable on "just do it"), and then runs descriptive analysis, root-cause investigation, validation, opportunity sizing, storyboarding, charting and the deck. Validation covers structural checks, business rules and Simpson's paradox. Failures raise warnings and blockers and loop back rather than producing a wrong answer with a caveat. Questions are routed by level, from a one-number lookup up to an hour-long deep dive, because "not every question deserves a deck". Shane's four transferable patterns are: write the CLAUDE.md for your domain; add skills that enforce standards automatically; log corrections so they are checked before the next query; and make validation a pipeline step. The design principle is to make a non-deterministic system as deterministic as possible, with the model reasoning and code doing every calculation. He builds agents in an "architect mode": Claude spawns several personas that each plan separately, debate, revise and agree a single master plan for him to review. Asked to rebuild itself, the system compressed about 40,000 lines into a 1,500-line markdown "seed", which rebuilt it on a separate machine.
Owning the automation. Shane's central claim is that you are the only person who can validate your own domain's output at speed, so self-automation is feasible and automating someone else's domain is not without their sustained feedback. He compares the ramp to onboarding a junior analyst, corrected heavily in week one and catching errors he had missed within the first week. He says correction rates fall by the third or fourth analysis on a dataset. The gains come from running analyses you were doing anyway, so the time invested is repaid at once. He warns that companies will misuse this by sending people to automate others' domains. The recommended start is a CSV or query with known answers, correcting each error and re-asking.
Q&A. On careers, Shane is openly uncertain. He predicts near-term work building agentic systems, cleaning data foundations and validating, possibly more data-science hiring for validation, and later roles as "solvers", translators and change leaders. He thinks the next six months of leaning in could shape a decade. A co-host likens analytical fundamentals to multiplication tables, and tools such as SQL to driving a stick shift. On stakeholders, Shane treats the system like a calculator: he remains accountable and keeps his agent away from stakeholders, though he had released his work to his organization only that Monday. A third co-founder says MCP servers to BI tools such as Databricks will let these workflows replace dashboards. Practical answers covered markdown checkpoints to avoid full reruns, PPTX output for manual edits, golden datasets and semantic views drafted as requirements for analytics engineers, bootstrapping knowledge from 30 days of query history, and connecting warehouses through a connect-data skill. He also covered security: zero data retention, Snowflake Cortex or SageMaker instead of local files, and demos on non-sensitive data while buy-in is sought. A co-host adds that red tape scales with company size. Shane keeps the system to product analytics and away from modeling and causal inference, which he says demand more human judgment to validate.