Analytics as Code: Why AI Stops Guessing With Data

Episode Summary

Data work is supposed to be the source of truth, which is why a model that hallucinates one percent of the time was unusable for it. Chris Parmer, co-founder of Plotly, explains what changed: AI got remarkably good at writing code, and Plotly’s customers were already doing analytics in code rather than in point-and-click tools. That shifts the question from whether you trust the answer to whether you can read the code that produced it. He covers who inside the enterprise picks this up first, why organizations end up with tens of thousands of dashboards, and what he has learned running proof of concepts with customers on technology this new.

Key takeaways

  • The hallucination objection changes shape when AI writes code rather than answers. Data work has to be accurate, and a model wrong one percent of the time cannot support decisions, but code can be read and verified

  • Analytics as code is not new. Quantitative finance, bioinformatics, and classical engineering have worked this way for years, in Python, Jupyter, Spark, and SQL. What is new is that AI can now write it

  • Organizations accumulate thousands or tens of thousands of dashboards because a new one gets built for every question, and only the trained BI person can build them. Natural language removes that bottleneck

  • The people adopting fastest are the stakeholders who used to wait on a data scientist, in quantitative finance, trading, portfolio management, energy, and utilities

  • Parmer’s rule of thumb for switching tools: it has to be at least one and a half times more productive before people jump ship. Much of AI clears that bar easily, taking weeks to days and days to hours

  • A blank prompt box is paralyzing rather than freeing. Auto-generating several ways to look at the data beats asking the user what they want

About Chris Parmer

Chris Parmer is co-founder and Chief Product Officer of Plotly, the company behind the Plotly graphing libraries and Dash, the framework for building analytic and data applications in Python. His work centers on making sophisticated data analysis available to people who are not professional data scientists, and on analytics as code: doing analysis by writing code rather than clicking through a business intelligence tool. He writes regularly on building products on top of AI.

 

In this episode

00:42 Welcome and guest introduction
01:33 The hallucination problem in data work
01:58 What changed when AI got good at writing code
04:07 Where analytics as code is actually used
05:41 What this means for executives who are not building products
06:17 The career path for analysts leveling up
07:04 Why companies end up with tens of thousands of dashboards
08:14 The executive who keeps asking for another cut of the data
10:10 Prompting, and why a blank slate is paralyzing
12:31 The audience that arrived once the barrier dropped
14:52 Where adoption is concentrated in the enterprise
16:26 Continuous monitoring and real-time dashboards
17:29 Sales and marketing use cases
18:00 Product analytics, done internally
20:01 Tracking engineering velocity from GitHub data
20:39 The organizational side of adoption
21:28 Letting people try any tool
22:19 Why it has to be 1.5 times better before anyone switches
22:43 Culture change comes from the conversation, not the tool
23:35 Three-month proofs of concept, and staying close to the vendor
24:28 Where AI changes the enterprise next
25:47 Guidance for executives early in adoption
26:14 Resources
27:01 Leadership skill: experimentation
28:22 The one thing to remember
28:59 Wrap-up

In Chris’words

“Data work is meant to be accurate. It’s meant to be the source of truth. If an AI model hallucinates 1 percent of the time, you can’t make decisions off of that.”

— Chris Parmer   (01:58)

“You end up with companies that have thousands or tens of thousands of dashboards, because there’s a new one created for every single question.”

— Chris Parmer   (07:04)

“A lot of product experiences show you a blank slate, and it’s what do you want? You can have anything. That maybe is freeing, but it’s also a little paralyzing.”

— Chris Parmer   (10:10)

“I have this theory that it’s gotta be at least one and a half times more productive for people to really jump ship.”

— Chris Parmer   (21:40)

“Being very comfortable with throwing away work and throwing away approaches, and not getting tied too early to things.”

— Chris Parmer   (27:20)

 

Resources

Chris Parmer and Plotly

•    Plotly: plotly.com. The graphing libraries and Dash, the framework for building analytic and data applications

•    The Plotly blog: plotly.com/blog. Where Chris writes frequently on building products on top of AI

•    Plotly on LinkedIn: linkedin.com/company/plotly

What Chris reads

•    Simon Willison’s blog: simonwillison.net. He reads it almost every day for what is coming next on the technology side

Tools and technologies discussed

•    Dash: dash.plotly.com. Plotly’s framework for data applications, and the thing stakeholders used to wait on a data scientist to build

•    Jupyter: jupyter.org. Named as a long-standing home for exploratory analysis in code

•    Apache Spark: spark.apache.org. Another example of analytics done as code

•    Excel, Power BI, Tableau: The point-and-click tools he contrasts with the code-based approach

Related AI Realized episodes and events

•    Agentic AI and Revenue Work: What Actually Pays Off: Christopher Penn of Trust Insights on agentic AI, measurement, and proving lift.

•    Connecting AI Agents to Live Enterprise Data: Deepti Srivastava of Snow Leopard on the gap between AI agents and dependable structured data.

•    Artifact-Scoped Agents: Stop Mimicking Job Titles: Chris Butler of GitHub on scoping agents to what they produce, and where the human belongs.

 

Frequently Asked Questions

 
 
 
 
 
 
 
 
 
 
 
Previous
Previous

Connecting AI Agents to Live Enterprise Data

Next
Next

From Firefighting to Fire Prevention in IT Operations