My first automation was a VBA macro, not a Python script. Five tool generations later, the question I ask before automating anything has not changed.
TL;DR: Automation is not a language choice; it is a decision about what deserves to be formalised. The stack moved from VBA to SAS, R, Python and LLM-assisted systems, but the test never changed: is the work repeated, stable and valuable enough, and is the process understood well enough that automating it makes the outcome safer, faster and more useful? When a business depends on a workflow, reliability — clear inputs, validation, monitoring and ownership — matters more than the automation itself.
Early in my career, a large part of the week disappeared into recurring reporting: updating slides from Excel, refreshing charts, applying the same formatting, and exporting the final document. None of it was difficult. All of it was repeated, and every repetition carried a chance of a stale chart or a missed refresh.
The obvious fix was to automate the steps. The less obvious question was where automation should stop. A macro that saves an afternoon is useful; a workflow a business depends on needs something more than a script that runs when someone remembers to run it.
I automated the reporting loop first, then kept moving the same instinct up the stack as the work changed. Each stage added a different kind of leverage, and each one exposed a new failure mode that automation alone could not fix.
Update slides from Excel, refresh charts, apply formatting, export the report. The value was immediate and local: fewer repeated steps, less copy-paste, more time for the team. This is where I learned to notice manual friction.
With SAS, recurring analysis and data preparation moved onto a schedule. The shift was not only technical — the work stopped depending on someone opening the right program on the right morning.
Analysis, charts and generated reports became scripts and templates. R made statistical work reproducible: the same inputs produced the same output, and a change could be reviewed instead of retyped.
Data sources, feature pipelines, model scoring and forecasting moved into one flow that produced a decision-ready output. Automation now covered the path from raw data to a forecast, not just the document at the end of it.
Extraction, classification and structured drafting became automatable for unstructured input. The boundary moved again, but so did the need for review: the more a system interprets rather than executes, the more its output has to be validated.
At every stage the question was the same: what work is repeated often enough, stable enough and valuable enough to formalise? The answer was never "everything repetitive". It was the work where the process was understood well enough that automating it made the outcome safer, faster and more useful.
VBA taught me to see manual friction. Python taught me that when a business depends on a workflow, automation is only half the job. The other half is reliability: clear inputs, repeatable logic, validation, monitoring, and a named owner for when something fails.
LLM-powered systems add another layer — they can extract information, classify content, draft structured outputs and absorb some repetitive reasoning. The principle does not change. Do not automate something just because it is repetitive. Automate it when the process is understood well enough to make it safer, faster and more useful. The language changed, the abstraction level changed, and the automation mindset stayed.
Design insight: Automation is not a language choice; it is a decision about what deserves to be formalised. The stack moved from VBA to SAS, R, Python and LLM-assisted systems, but the test never changed: is the work repeated, stable and valuable enough, and is the process understood well enough that automating it makes the outcome safer, faster and more useful? When a business depends on a workflow, reliability — clear inputs, validation, monitoring and ownership — matters more than the automation itself.
Automate Maintenance, Keep Judgment → Better Tools, Same Principles → Tools That Last in Data Science → ML Workflow Then vs Now → Preprocessing Pipeline as Source of Truth → Silent Model Failure → AI Automation Levels: Green, Yellow, Red → The AI Replaced the Training Backlog → Data Scientist to AI Engineer: What Transfers →
Automation is not a language choice; it is a decision about what deserves to be formalised. The stack moved from VBA to SAS, R, Python and LLM-assisted systems, but the test never changed: is the work repeated, stable and valuable enough, and is the process understood well enough that automating it makes the outcome safer, faster and more useful? When a business depends on a workflow, reliability — clear inputs, validation, monitoring and ownership — matters more than the automation itself.
This was written by Mahmoud Trigui, Senior Data Scientist. My first automation was VBA, not Python. The instinct survived SAS, R, Python pipelines and LLM systems: automate what is understood well enough.