The model can detect patterns, summarize trends, or produce plausible explanations. Sometimes, surprisingly well. But the part of the work that really matters still lives somewhere else.
It lives in the why.
That may sound obvious. It isn’t. Because when a tool is fluent, fast, and confident, it becomes very tempting to believe it also understands our intent. And that is where things start to derail.
The experiment
I used a specialized data assistant to look at a table with several groups of data distributed across three months. I am intentionally keeping the example generic because the specific business topic does not matter for the point I want to make. The assistant presented the totals and inferred a trend for each group. So far, so good.
Because I found raw numbers complicated to read at a glance, I asked the assistant to add percentages by month and by column. It did that. But then it also changed the trends, even though the underlying data had not changed. That could make sense if it were now calculating trends based on percentages rather than raw counts. Still, it apparently did so by comparing only January and March, without using the intermediate month.
Fine. But then I realized that, for what I wanted, the relative increase of the percentage was more meaningful. If something goes from 2.0% to 2.5%, should the delta be 0.5 percentage points, or 25% relative growth? In light of that choice, I (we?) got a third set of trends.
More? In that version of the table, the legend stated that moves above 5% in absolute value were significant enough to deserve an icon. Yet two groups were beyond that threshold and still marked as stable.
My suspicion was that this happened because the middle month changed direction, so the overall change and the month-by-month path were telling slightly different stories. I asked the assistant about it. Unsurprisingly, it replied “you’re absolutely right” and generated yet another table.
The conclusion: the importance of the why
This experiment reminded me of a conversation that later turned into a post: agents do not need exhaustive specs because they can fill in the gaps from a prototype, the codebase, or an evaluation set. But what they cannot infer on their own is the reason we need what we’re trying to do. The why.
It sounds trivial, but it isn’t. The “trend” is different depending on what you want it for, because the purpose forces intermediate analytical decisions. A good part of the why may also live in the database and its documentation. But databases are often multipurpose. And that means they are also multi-why. So when we use AI, it is crucial to resist the temptation to be overly laconic. That’d equate to thinking the model already knows what we are trying to do.
Nothing radically new under the sun, of course. Just a reminder that we need to focus on the problem before getting hypnotized by the elegance of the answer.
Leave a Reply