Sure, everything in this article is true, but the whole premise is wrong. Throwing giant reams of data and numbers at them and ever expecting sense from the prediction is madness.
They are great at writing code however, and that code can be used to do the analysis. Most of the AI services we have now like Cursor, Claude code etc, have tool usage or MCP access so they can do more than predict text. With access to extra tools and chain-of-thought reasoning, there is emergent behaviour beyond the "stochastic parrot" which looks and smells a lot like understanding.
With an MCP to Google Sheets, the LLM can write the cell formula, or the appscript to prepare the data. With an MCP to a database, it can write the SQL, it can write the python and pandas analysis, it can write the jupyter notebook, or create the streamlit ior observable or other interactive data-viz story for you. It won't ever do the data analysis directly, but all of this coordination is going to end up behind the scenes so for the regular user, it's going to look exactly like it's the LLM doing it. Nevermind it's an API with some decision systems and routing to RAG and a bunch of tools. The end user doesn't care.
It's the same with how amazing the latest OpenAI models are with images. It's not because the transformer or diffusion model suddenly got so much better, it's because it has access to photoshop-like tools. Crop, frame, remove background, scale, rotate, colour, skew. These are all just regular software tools that when orchestrated by the AI and strung together are effectively one system. The fact that you know there's transformer architecture and text prediction going on is besides the point. It's now one small cog in the wheel. Pretty world-changing cog, but just one, and one of very many.
Absolutely agree with you, you can use LLMs to help you write the code to do data analysis, but my premise was not use the LLM - as it is - to do data analysis. Most people are just there dumping shit into chat interfaces and expect causal impact or deep inferences lol. Everything you wrote I agree 100% and this is what I covered in a previous article that the most popular and useful and less disrupted wrapper in the market is the code assistant/copilot wrapper.
Additionally, as I mentioned above and what the latest research proved too, the only way an LLM will "work" in a data analysis context is if its a hybrid approach + code, pandas, and other variations of wrappers. Thank you so much for the thoughtful comment and for giving my article a read!
I want to qualify one thing I said about the LLM writing SQL. This is funnily enough one of the things it struggles more than other languages especially in the context of big cloud databases like snowflake, bigquery, redshift, databricks etc. I think this is because they mostly don't support constraints like primary & foreign keys, or if they do they don't enforce them (for sensible reasons) but then people don't bother creating them. Database metadata, the set of table/view names, column names and their data types, is not enough context for an LLM (nor any brand new human data analyst being onboarded) to understand the business use cases and the semantic meaning of the data model.
If you also have good docs or dbt models or lookerML config or similar high quality information describing the business meaning and relationships in the data model, it is much more likely to succeed at then generating the SQL to enable ad hoc reporting.
If you get past that hurdle, they are pretty quick at generating jupyter notebooks, streamlit or observable dataviz and similar interactive tools. Makes the need for big tools like Tableau or Looker feel less valuable, beyond the enterprisey things they offer like auth and SSO.
Sure, everything in this article is true, but the whole premise is wrong. Throwing giant reams of data and numbers at them and ever expecting sense from the prediction is madness.
They are great at writing code however, and that code can be used to do the analysis. Most of the AI services we have now like Cursor, Claude code etc, have tool usage or MCP access so they can do more than predict text. With access to extra tools and chain-of-thought reasoning, there is emergent behaviour beyond the "stochastic parrot" which looks and smells a lot like understanding.
With an MCP to Google Sheets, the LLM can write the cell formula, or the appscript to prepare the data. With an MCP to a database, it can write the SQL, it can write the python and pandas analysis, it can write the jupyter notebook, or create the streamlit ior observable or other interactive data-viz story for you. It won't ever do the data analysis directly, but all of this coordination is going to end up behind the scenes so for the regular user, it's going to look exactly like it's the LLM doing it. Nevermind it's an API with some decision systems and routing to RAG and a bunch of tools. The end user doesn't care.
It's the same with how amazing the latest OpenAI models are with images. It's not because the transformer or diffusion model suddenly got so much better, it's because it has access to photoshop-like tools. Crop, frame, remove background, scale, rotate, colour, skew. These are all just regular software tools that when orchestrated by the AI and strung together are effectively one system. The fact that you know there's transformer architecture and text prediction going on is besides the point. It's now one small cog in the wheel. Pretty world-changing cog, but just one, and one of very many.
Absolutely agree with you, you can use LLMs to help you write the code to do data analysis, but my premise was not use the LLM - as it is - to do data analysis. Most people are just there dumping shit into chat interfaces and expect causal impact or deep inferences lol. Everything you wrote I agree 100% and this is what I covered in a previous article that the most popular and useful and less disrupted wrapper in the market is the code assistant/copilot wrapper.
Additionally, as I mentioned above and what the latest research proved too, the only way an LLM will "work" in a data analysis context is if its a hybrid approach + code, pandas, and other variations of wrappers. Thank you so much for the thoughtful comment and for giving my article a read!
I vigorously agree with you!
I want to qualify one thing I said about the LLM writing SQL. This is funnily enough one of the things it struggles more than other languages especially in the context of big cloud databases like snowflake, bigquery, redshift, databricks etc. I think this is because they mostly don't support constraints like primary & foreign keys, or if they do they don't enforce them (for sensible reasons) but then people don't bother creating them. Database metadata, the set of table/view names, column names and their data types, is not enough context for an LLM (nor any brand new human data analyst being onboarded) to understand the business use cases and the semantic meaning of the data model.
If you also have good docs or dbt models or lookerML config or similar high quality information describing the business meaning and relationships in the data model, it is much more likely to succeed at then generating the SQL to enable ad hoc reporting.
If you get past that hurdle, they are pretty quick at generating jupyter notebooks, streamlit or observable dataviz and similar interactive tools. Makes the need for big tools like Tableau or Looker feel less valuable, beyond the enterprisey things they offer like auth and SSO.