By Hiran de Silva
There is an interesting problem when we try to take a solution designed for a small, local problem and scale it into something global.
Very often, the obstacle is not technology.
It is conceptual understanding.
Suppose somebody solves a problem with a sophisticated dynamic-array formula, a LAMBDA function, or some other clever piece of Excel engineering.
The formula might work beautifully.
But look at it.
Does it tell you the principle behind the solution?
Usually, no.
You can break a LAMBDA function into its constituent parts. You can explain each function. You can explain what each variable does. You can walk through the calculation step by step.
But even after doing all of that, somebody may understand how the formula works without understanding why the solution was designed that way.
And that distinction becomes extremely important when you want to scale.
Compare That With GET and PUT
Now compare this with the hub-and-spoke methodology I use in what I call Basic Excel.
The technical principle can be expressed in two words:
GET and PUT.
What information do I want to GET?
Where do I want to GET it from?
What information do I want to PUT?
Where do I want to PUT it?
And where on the spreadsheet does that information come from?
These are extraordinarily simple concepts.
The clever part isn’t the Excel.
The clever part is deciding what the system should actually do.
That requires something rather different from technical expertise.
It requires lateral thinking.
The Clever Bit Isn’t the Code
Take the particular problem I have been demonstrating.
One of the conceptual breakthroughs is double-entry bookkeeping.
To somebody with an accounting background, the underlying principle is almost embarrassingly simple.
A ledger is essentially a table to which transactions are posted.
We append transactions.
Of course, there are important rules. The accounts need to exist. The correct accounts need to be posted. The transaction must balance to zero. And the postings must correctly represent the economic transaction taking place.
You therefore need some understanding of bookkeeping and accounting to design it correctly.
But in this particular example, we’re hardly dealing with exotic financial engineering.
We’re recording debts between people.
People have been doing that for centuries.
Shylock could have understood the principle.
The computer implementation is almost incidental.
Append some rows to a table.
That’s it.
But to realise that this is the appropriate solution, you first have to recognise the problem as a bookkeeping problem.
That is the lateral-thinking step.
Three Tiny Pieces of Knowledge
So think about what somebody actually needs to understand before they can understand this solution.
First, the principle of double-entry bookkeeping.
Second, the principle of posting transactions to a ledger.
Third, GET and PUT — including the simple connectivity required to move information between Excel and the central data store.
None of these concepts is particularly difficult.
In fact, the essential principles could probably be explained in five minutes.
But those five minutes completely change how you see the problem.
And that brings us to AI.
Now Give the Problem to AI
This creates what I think could be a fascinating live experiment.
Before I demonstrate my solution, I give everybody the original problem.
Then I say:
Go to your favourite AI.
ChatGPT. Claude. Whatever you use.
Copy and paste the problem exactly as I’ve described it.
Or improve the prompt yourself if you like. Prompt it however you think appropriate.
Then ask AI to solve it.
What I suspect will happen is very interesting.
The answers will probably vary in detail, but they are likely to share broadly similar assumptions.
AI will reach for the kinds of solutions normally associated with this kind of problem.
Perhaps formulas.
Perhaps Power Query.
Perhaps VBA.
Perhaps Power Automate.
Perhaps SharePoint.
Perhaps an app.
Perhaps a database application.
Perhaps a collection of technologies connected together.
And some of those answers may be perfectly reasonable.
But then we put those solutions beside the one I’ve just demonstrated.
And ask a much more interesting question:
Why didn’t AI suggest this?
AI Knows All of This Already
This is where the experiment becomes particularly revealing.
There is nothing in my solution that AI doesn’t know.
Ask AI about double-entry bookkeeping. It knows it.
Ask AI how a ledger works. It knows it.
Ask AI whether Excel can communicate with a relational database. It knows it.
Ask AI about SELECT and INSERT. It knows them.
Ask AI about client-server architecture. It knows that too.
Ask it whether many Excel workbooks can act as clients to a common database.
Again, it knows.
So all the ingredients are already there.
And yet, when presented with the original problem, AI may not assemble those ingredients into this solution.
Why?
Because AI has an enormous body of knowledge.
But possessing knowledge is not the same thing as choosing the right conceptual model.
You Have to Tell AI Not to Do What It Would Normally Do
And that leads to the rather wonderful paradox.
To get AI to produce the unconventional solution, you may have to tell AI not to do what it would normally do.
You might have to say:
Don’t assume that each spreadsheet should solve the whole problem locally.
Don’t assume that the answer lies in a more sophisticated formula.
Don’t assume that Power Query is the natural architecture.
Don’t assume that spreadsheets need to pass information between themselves.
Instead:
Treat Excel as the client.
Treat the central database as the shared ledger.
Use double-entry bookkeeping to represent the transactions.
Use PUT to post transactions.
Use GET to retrieve the information each person needs.
Suddenly, AI becomes extremely useful.
It can probably build much of the solution for you.
But notice what happened.
AI didn’t provide the breakthrough.
You provided the breakthrough.
You supplied the conceptual model.
AI supplied the implementation assistance.
That Changes the Meaning of AI Expertise
This raises an important question about what it means to be good at using AI.
We hear enormous amounts about prompting.
How do I write a better prompt?
How do I give AI clearer instructions?
How do I get better output?
Those things matter.
But perhaps there is another skill that matters much more.
Knowing what to tell AI to think about.
Because if you don’t possess the underlying conceptual knowledge yourself, you may simply accept the first technically impressive solution AI gives you.
And AI may reinforce precisely the same conventional thinking that already dominates the subject.
The danger is therefore not that AI doesn’t know enough.
It may know vastly more than any of us.
The problem is that it doesn’t necessarily know which piece of its enormous knowledge base you need it to apply differently.
That may still require human judgement.
From Local Thinking to Global Thinking
This is particularly important when moving from local-scale spreadsheet solutions to global-scale systems.
At local scale, complexity can masquerade as sophistication.
A clever formula can be impressive.
A highly automated workbook can be impressive.
A complicated Power Query process can be impressive.
But global scale demands something else.
It demands architecture.
It demands separation of data from presentation.
It demands shared truth.
It demands simple, repeatable interactions between clients and a central source.
In my terminology, it demands the Digital Librarian.
And once you understand that architecture, the Excel itself can become surprisingly simple.
That is the irony.
The global solution can actually be conceptually simpler than the local solution.
The Five-Minute Advantage
Perhaps this is therefore one of the most important lessons I can give somebody before handing them an AI assistant.
Don’t spend six months learning every possible Excel function.
Learn the principles that allow you to recognise the problem differently.
Learn what a database is.
Learn GET and PUT.
Learn the elementary principles of a ledger.
Learn client-server architecture.
Learn to distinguish data from presentation.
And, above all, learn to ask:
What kind of problem is this really?
Because once you’ve answered that question correctly, AI can become astonishingly powerful.
Without that conceptual understanding, AI may simply make conventional thinking faster.
With it, AI can help you implement something completely different.
And that gives us a wonderfully counterintuitive lesson for the AI age:
Sometimes, the most important instruction you can give artificial intelligence is this:
Don’t do what you would normally do.
Add comment