Building Prediction Models vs. Data Analysis

In many areas of machine learning we can evaluate our results against something concrete. There is a ground truth. A label.

And we can evaluate how well we are doing with a set of well-defined metrics.

For this type of data science, you may never have to look at the underlying code that builds prediction models, so what’s the point of learning how to code? You may ask.

However, when it comes to data analysis side of data science things are very different.

Because, there is no clear pre-defined answer that we can evaluate against at the end.

You are not verifying result against a particular answer, instead you are building an answer. You are exploring data in order to understand something that was previously unknown.

And this makes a difference between generating code for data analysis side of data science and for building prediction models side of data science.

In fact, the real difficulty in data analysis has always been how you build the answers you can trust, not how to write code.

In order to trust the result, you have to have trust in the process that produced the result. You have to be confident that each data transformation such as filter, calculations, aggregation, combine with other data, cleaning text data, etc. is doing exactly what you intended.

Not approximately.

“Close enough” is not enough in data analysis or building metrics or KPIs, it has to be ‘Exact and Accurate’ because people (or even agents!) will make decisions based on the result.

From Readability to Trust

Before making further discussion, I want to make it clear.

When I say Readability, it is not just about aesthetics or personal preference. It is not about whether code looks “clean” or “elegant.”

It is about whether you can understand what the code is actually doing.

When AI generates code, it is easy to assume that the result is correct. But small details matter. A slightly different grouping, an unintended filter, a silent drop of missing values, any of these can change the outcome in meaningful ways.

If the code is readable, you can pause and inspect it. You can follow the transformation step by step and confirm that it aligns with your intention. The code becomes something you can reason about.

Here’s an example of R code that provides high readability.

sales %>%  
   filter(year >= 2020) %>%  
   group_by(region) %>%  
   summarise(total_sales = sum(sales))

It can be read as:

“Filters data for 2020 or later, and calculate total sales for each group of region.”

It’s readable, and you can understand what it’s trying to do.

If it is not readable, you are left with a different experience. You are not verifying the result, you are just trusting it faithfully. And in data analysis, blind trust is not a viable strategy.

Trust, then, is not something AI gives you.

It is something you build through readability.

From Readability to Reproducibility

But this is only the beginning.

In a business context, data analysis rarely happens only once. Data changes. Questions evolve. The same analysis needs to be run again next week, next month, or with slightly different conditions.

At that point, the question becomes:

“Can you reuse what you already did before?”

If you understand the code, the answer is simple. You run it again. And if needed, you adjust a condition, extend a calculation, etc. The original logic in data transformation and analysis remains intact, and the analysis evolves naturally over time.

If you don’t, it breaks.

You go back to AI. You describe the task again. The AI generates something similar, but may not be identical. Small differences creep in. Over time, you accumulate multiple versions of “the same” analysis that are, in fact, not quite the same.

This is the problem when you don’t have reproducible data analysis pipeline. And if you can’t reproduce you’ll lose trust quickly.

Again, the question is not whether you or AI can write, but it is whether the code, either generated by AI or written by you, is readable enough to be reused with confidence.

From Readability to Interactivity

There is one more dimension, and it is perhaps the most subtle.

Data analysis is not a linear process. It is not a sequence of predefined steps. It is a iterative process, a back-and-forth between you and the data, as if you are having a conversation with data.

You might begin with something simple:

“Show me sales by year.”

But almost immediately, your thinking moves forward.

-> What about monthly trends?

-> What about regional differences?

-> What about repeat customers?

-> Is there a correlation with marketing spend?

Each question generates an answer, which generates a new question, which generates an answer and so on. It’s an iterative process and the center of the process is you as a curious and creative being.

And you want this process to be fast, as fast as the speed of thought.

But when every step requires writing a prompt, waiting for AI to respond, reading the generated code, and then inspecting whether the result is correct, that flow is interrupted. The conversation slows down.

You are no longer exploring, you are coordinating with a tool.

However, something different happens when the code is readable.

You stop relying on prompts for every step. Instead, you begin to adjust the code directly. A grouping changes. A filter is added. A calculation is modified. The feedback loop tightens.

Now, the pace of analysis starts to match the pace of your thinking.

That is what true exploratory data analysis feels like.

It’s interactive and iterative.

The Shift We Often Miss

It is tempting to think that AI reduces the importance of programming.

In reality, it does the opposite.

It shifts the role of programming from writing code to understanding code, at least in a context of data analysis.

And once that shift happens, the most important property of programming language is no longer what it can do.

It is how easily you can read what it does.

Because that is what determines whether you can:

• trust the result
• reproduce the process
• and interact with the data in a meaningful way

And all of that begins in the same place.

Readability.

1. Separation of Logic vs Logistics

Every piece of data analysis code contains two layers:

• Logic → What you want to do
• Logistics → How the computer executes it

For example:

“Calculate total sales by region for 2020 and after”

This is logic.

But implementing it may involve:

• loops
• indexing
• temporary variables
• restructuring outputs

This is logistics.

Example with R (Tidyverse)

Now, here is how you write in order to achieve the above with R (tidyverse).

sales %>%  
   filter(year >= 2020) %>%  
   group_by(region) %>%  
   summarise(total_sales = sum(sales))

This is almost a direct translation of the question:

• filter year >= 2020
• group by region
• summarize total sales

You see only the logic, almost no visible logistics

sales[sales['year'] >= 2020] \
    .groupby('region') \
    .agg(total_sales=('sales', 'sum')) \
    .reset_index()

result = {}

for row in sales:    
    if row['year'] >= 2020:        
       region = row['region']   
       if region not in result:     
           result[region] = 0  
       result[region] += row['sales']

2. Built-in Vectorization

Now let’s go one level deeper.

Even if you separate logic from logistics, you still need a way to apply that logic to data.

This is where vectorization comes in.

With vectorization, you can apply an operation to an entire column at once, instead of looping row by row.

Let’s say you want to make a simple calculation like “multiple sales by 1.1”.

With R, you can write something like this.

sales * 1.1

This applies to all values in the sales column (or variable).

No loop. No special function. Just the logic.

But in Python, you must iterate explicitly.

[s * 1.1 for s in sales]

With the pandas or the NumPy library it could be close to R.

df['sales'] * 1.1

In Python, vectorization is not part of the language itself unlike R. Instead, it is outsourced to libraries. Therefore, you need to deal with the difference among the libraries:

• Python lists → not vectorized
• NumPy arrays → vectorized
• pandas Series → vectorized (differently)
• Polars Series → vectorized (again differently)

Each has:

• different APIs
• different behaviors
• different edge cases

So you end up writing with the numpy package:

import numpy as np

sales = np.array(sales)
sales * 1.1

Or, with the panda package:

pd.Series(sales) * 1.1

And this gets worse when you want to calculate conditionally.

Let’s say if you want to calculate something like this.

“If sales > 100, apply 10% discount”

In the case of R, it’s pretty simple.

ifelse(sales > 100, sales * 0.9, sales)

You have the following three.

• condition
• calculation
• fallback

But in the case of Python, it becomes convoluted.

[s * 0.9 if s > 100 else s for s in sales]

Now:

• explicit iteration
• inline conditional logic
• more cognitive load

Even with pandas package,

df['sales'] = np.where(df['sales'] > 100, df['sales'] * 0.9, df['sales'])

It’s better, but still:

• referencing columns repeatedly
• using external function (np.where)
• mixing libraries (pandas + NumPy)

3. Non-Standard Evaluation (NSE)

Now we reach the most important layer.

Even if you can think in logic and can operate on vectors, you still need a way to express your idea naturally.

This is where NSE (Non-Standard Evaluation) comes in.

df %>%
  mutate(profit = sales - cost)

df['profit'] = df['sales'] - df['cost']

df %>%
  group_by(region) %>%
  summarise(avg_sales = mean(sales))

df.groupby('region')['sales'].mean().reset_index(name='avg_sales')

df %>%
  arrange(cos(sales))

import numpy as np

df.assign(
    cos_sales=lambda d: np.cos(d['sales'])
).sort_values('cos_sales') \ 
 .drop(columns=['cos_sales'])

Bringing It All Together

These three principles are not independent. They reinforce each other.

When all three are present,

• You express logic, not logistics
• You operate on data as a whole
• You write expressions, not instructions

The result is the code that reads like the question you are asking.

Pick the Language That Gives You Readability

If your goal is to work effectively with AI-generated code, you need a language where:

• the code reflects the logic directly
• transformations are easy to follow
• small changes can be made without friction

This is where R, especially with the tidyverse, stands out.

Not because it can do something others cannot.

But because it expresses ideas in a way that is intuitively understandable.

When AI generates R code, what you see is not machinery, you see intent.

And that makes all the difference.

What is the bottleneck for data analysis today?

10 years later, things have changed dramatically.

It is now 2026, and we are deep in the era of AI and LLM (large language models). Writing code is no longer the hard part. AI can write R, Python, SQL - almost instantly and entirely.

And this begs a question.

If writing code is no longer the bottleneck, then what is?

We started asking our customers,

What is the bottleneck for data analysis today in the era of AI?

And the answers were surprisingly consistent.

The bottlenecks were:

Reliability and Reproducibility.

This brings us back to the core idea of this post.

If reliability and reproducibility are the problems, then how can we solve?

And the answer, as we’ve seen, is readability that is supported by the right interface - AI prompt and UI.

This is where Exploratory fits in, especially in the AI era.

Data Analysis in Exploratory

In Exploratory, you can type in how you want to transform and prepare data in the prompt UI, then AI generates R (tidyverse) code. Not as something hidden behind the scenes, but as something you can see, read, and understand.

You can read the code with a help of the code description to see what it does and what you can expect from it.

But it doesn’t disappear into somewhere it’s hard to find like Excel where the calculations and transformations are spread across a bunch of cells.

It becomes part of a visible, inspectable data wrangling step.

Each step is preserved as part of a pipeline - a sequence of data transformations that you can revisit, modify (such as changing the data source files or underlying SQL queries, updating calculations, changing the data filter conditions, etc.), and rerun at any time.

You can see the updated data visualized by Summary view where each column shows its summary information with automatically generated chart and metrics.

Or, simply use Chart view where you can visualize the data with various chart types and chart features with point-and-click.

This makes a powerful data exploratory experience, which is highly visual, iterative, and interactive.

Over time, this changes how you work.

You are no longer repeatedly asking AI to regenerate the same logic. You are refining and evolving an analysis that you understand.

When new data arrives, you don’t start over. You update the source step and rerun the process.

When a new question emerges, you don’t need to start from scratch. You add a new step and continue the flow.

At this point, your analysis becomes:

• Reliable, because you can verify every step
• Reproducible, because the process is preserved
• Interactive, because you can move at the speed of your thinking

And this is not simply because AI is generating code.

It is because that code is readable, and because the environment is designed to support that readability.