Working with AI on analysis · 2/7
I used to choose Python because it was fast, convenient, and flexible. After AI joined my analysis workflow, I started reconsidering that choice for exactly the same reasons.
I used Jupyter; the agent used bash
A common workflow I encountered was to load data with Python, write calculations with pandas and NumPy, execute a .py file, and inspect the results. There is nothing inherently wrong with that. It was how I worked too, except I used Jupyter and the agent used bash.
It is hard to resist doing several things in one script: cleaning a few dataframes, calculating metrics, and writing several outputs.
When I worked alone, I mostly knew which outputs could be overwritten, which needed to be kept, how the dataframes depended on one another, and what order to run them in. Occasionally I ran the wrong cell and quietly reached for Restart & Run All.
The workflow depended on something missing from requirements.txt: the execution state in the analyst’s head.
“Sorry, I should not have overwritten your file”
With an agent, scripts multiply, change quickly, and run repeatedly. One script may update several datasets. Suddenly there is more to track:
- Did this change only adjust a calculation, or did it rerun the cleaning too?
- Which intermediate output has already been overwritten?
- Is the downstream report still using the data I just reviewed?
More comments do not necessarily make those dependencies or execution states easier to follow. Git often tracks the code in a local analysis environment, while versions of each data output require a separate arrangement. Recovering the previous .py file does not recover its previous results.
Previously, I combined Python’s flexibility with a supposedly reliable operator: myself. Now I had an agent saying, “You’re right, I should not have overwritten that file. It won’t happen again.” The assets I used to manage in my head became harder to follow and easier to damage.
AI had made writing code cheaper. Could I accept less flexibility in exchange for work that was easier to understand, review, and continue?
My choice: SQL-first, with the workspace managing the rest
My answer was SQL-first. This is a choice about the analysis workflow. SQL itself does not provide read-only access, dependency management, or data versioning; the query environment and workspace must implement those controls.
Two properties made it useful for me:
- A more manageable boundary: let the agent analyze through controlled read-only queries, while the workspace manages how results are saved and updated.
- More explicit outputs: a
SELECTproduces a result set that can be named, reviewed, and connected to dependencies. It also makes a useful calculation contract in a Plan.
SQL is not a cure-all. Long queries can be difficult to read. Python is still more convenient for statistics, machine learning, and many specialized transformations.
I therefore use SQL as the base and add workspace capabilities where needed:
- A unified query layer for analysis across data sources.
- Caching for reusable intermediate outputs that downstream queries can reference.
- DAG execution to expose dependencies and the order of reruns.
- Statistical tools, with Python still available where it is useful.
These modules do not automatically give every dataset a version history. They do make dependencies that once lived inside scripts and my memory visible as manageable analysis assets.
There is some overhead compared with letting the agent immediately run Python for everything. After getting lost in enough oceans of agent-generated .py files, that difference matters much less to me.
What I care about is the total time from producing a result to understanding it, validating it, and using it in a decision.
Further reading
Try this way of working in Lantide Data: Download Lantide Data.
Previous：AI Can Do the Analysis. Who Will Defend It in the Meeting? · Next：Why Does AI Still Use the Wrong Definition After I Save an Analysis as a Skill?