"Do I need to learn to code?"
I've been hearing versions of that question a lot.
One person sees me build a tool and says that it looks useful, but assumes their company would need to hire a programmer.
Another asks whether AI is doing all the coding for me.
Someone else understands what the automation could do but says the whole thing still feels too technical.
A client recently put the confusion particularly well. He wasn't sure whether the questions he was asking me were AI questions or automation questions.
That's the distinction I've been thinking about.
I think we're missing a useful category.
Automation literacy.
AI literacy and automation literacy are different
AI literacy is about working well with an AI system.
You need to understand things like context, prompting, uncertainty, privacy, models, tools and when to check the answer.
Automation literacy is about something different:
How do I turn work I understand into a repeatable system?
That means asking questions such as:
- What starts this work?
- What information goes in?
- What actually happens to it?
- Which parts are fixed rules or calculations?
- Where is judgement needed?
- What comes out?
- What can the system change?
- What happens when something goes wrong?
- How do I know it worked?
You can be good at AI and bad at automation.
You can also build useful automations with no AI involved at all.
The two skill sets are becoming more valuable together because AI can now help us design and build systems that previously required much more technical implementation.
Zapier was an early clue
Think about someone who learned Zapier ten years ago.
They didn't have to become a programmer.
But they did have to learn some technical ideas.
A Zap has a trigger.
It has actions.
Data needs to move from one system to another.
You have filters, mappings, connections and errors.
You test the workflow.
That person was learning how software systems fit together without learning how to write the underlying integrations.
AI coding agents take that idea further.
Zapier gives you a box of pre-built pieces.
An AI coding agent can sometimes help make a missing piece.
That is a big change.
It does not make the technical part disappear.
It means a domain expert can participate much more directly in creating the system.
A simple example from my bookkeeping
I hate bookkeeping.
So I have gradually built a collection of small tools to do a lot of the repetitive work for me.
The interesting part is that I don't want AI doing every calculation.
If I need a bank statement converted into the exact format my accounting system expects, I can create a software tool to do that conversion consistently.
If I need balances checked, I can use a deterministic reconciliation tool.
If I already know that a particular supplier always belongs in a particular category, I can encode that as a rule.
Then I can use AI as the flexible layer around those tools.
I can say something close to:
Take the latest statement, ingest it, reconcile the transactions and make sure it balances.
The AI can work out which file I mean, identify its format, call the relevant conversion and reconciliation tools, inspect the output and explain what happened.
If the software reaches a transaction it has never seen before, that's where AI can become useful.
It can say:
I don't have a rule for this. I think it probably belongs in this category. What do you want to do?
I make the decision.
Then we can add a rule so the next occurrence does not need the same AI judgement.
I sometimes describe this as rules before guesses.
If I already know the rule, I don't need to pay a language model to rediscover it every time.
AI can help build an automation without being part of the automation
This is one of the ideas that causes confusion.
There are at least four possibilities:
- You build a normal automation without AI.
- AI is one component inside the automation.
- AI helps you build an automation that is mostly ordinary software.
- AI helps you build an automation that contains other AI steps.
Those are different architectures.
The existence of Claude Code or another coding agent doesn't mean every finished system should be one giant AI agent.
Sometimes the smartest use of AI is to help create a boring little calculator, converter or validator that does the same thing correctly every time.
So do you need to learn programming?
Maybe a little.
It depends how far you want to go.
I don't think the useful goal for most professionals is to become a software engineer.
I do think it is useful to become a little more technical.
If you want to automate more of your own work, concepts such as these become useful:
- files and formats;
- triggers;
- APIs and connectors;
- permissions;
- rules;
- tests;
- logs;
- where the automation runs.
That's not the same as learning Python.
Think about the Zapier user again.
They needed enough technical literacy to build and maintain a Zap.
They didn't need to know how Zapier's servers worked.
AI coding tools move that boundary.
You may be able to describe the tool you need in normal language and have AI implement most of it.
You still need enough understanding to answer three questions:
What did I ask it to build?
How will I know whether it works?
What happens if it is wrong?
I prefer the term "automation owner"
You do not have to personally implement every technical detail.
You can still own the automation.
An automation owner knows:
- why it exists;
- what starts it;
- what information it uses;
- what it is allowed to change;
- what rules it follows;
- where AI judgement is involved;
- where a person must approve something;
- how the result is checked;
- who is responsible when it fails.
Some automation owners will build the whole thing themselves.
Some will use Zapier or Power Automate.
Some will use an AI coding agent.
Some will hand a specification to IT or a developer.
All of those can be good outcomes.
There is a useful way to think about the work
I've been using seven steps.
Find
Choose work worth automating.
Map
Understand what actually happens now.
Split
Separate stable rules, flexible interpretation and human authority.
Design
Define the trigger, inputs, transformation, outputs, permissions, exceptions and verification.
Build
Choose the simplest appropriate implementation.
Prove
Test it against known cases, including failures.
Own
Give it a home, an owner and a maintenance path.
Notice that coding is only one possible piece inside "Build".
Most of the thinking happens before that.
When should you bring in a specialist?
Earlier than your ego would like and later than you may currently assume.
A small file-conversion utility with clear inputs, outputs and tests may be a perfectly reasonable project to build with an AI coding agent.
A payroll system that changes employee records, submits statutory information and initiates payments has a very different consequence profile.
I would want much more professional oversight there.
The same is true when:
- sensitive data is involved;
- permissions are complicated;
- failures are hard to reverse;
- many people depend on the system;
- the automation becomes business-critical.
Knowing when to stop is part of automation literacy.
This is the skill I think more professionals need
AI literacy matters.
Prompting matters.
But once you start asking AI to do repeated work across files, systems and business processes, another skill appears.
You need to think about the work as a system.
You need to understand enough about that system to design it, test it and own it.
The implementation barrier is falling quickly.
That makes domain expertise more valuable, not less.
If you know the work, know the exceptions, know what "correct" looks like and can describe it clearly, AI can increasingly help with the technical implementation.
You don't have to become a software engineer.
But learning automation literacy may dramatically expand what you can do.
Free Automation Literacy resources
HumanSpark has a set of practical resources to help you start:
- Automation Literacy Self-Assessment
- Automation Opportunity Canvas
- Build or Brief? Decision Guide
- Automation Literacy Glossary
Use them with one real workflow rather than trying to automate everything at once.