Automation in Computer Programming: The Real Stack

Automation in computer programming means two different things, and conflating them causes most of the confusion. There's automation you write — scripts that do a job for someone else. And there's automation inside the work of programming itself — the formatting, testing, building, and deploying that happens around your code whether you think about it or not. This article is about the second one, because it's the layer that decides how fast a team actually ships.

The stack, bottom to top:

Add them in that order. Teams that jump to the top of the table before the bottom is solid end up generating code faster than they can verify it, which is a worse position than writing it by hand.

Layer one and two: the cheapest wins in software

Formatting automation ends a category of argument permanently. A formatter runs, the code looks the same everywhere, and nobody debates brace placement in a code review again. Setup is typically under an hour, and the payoff is every review from then on.

Linting is the same mechanism aimed at correctness rather than style — unused variables, unreachable branches, a promise nobody awaited. Most of what a linter catches is not a bug today but a bug in six months when someone edits nearby code.

Wire both into a pre-commit hook so they run before code leaves a machine. The alternative — catching it in CI — works, but it turns a two-second fix into a five-minute round trip.

Testing is where the cost curve gets steeper and the argument gets real. A useful heuristic: automate the test if you'd otherwise run it manually more than three times. Login flows, calculation logic, anything touching money. Skip it for code you're about to throw away, and be honest about which is which.

Layer three and four: CI/CD, and what actually breaks

Continuous integration and continuous delivery automate the path from a commit to a running system. The concept is old and the tooling is commoditised — Jenkins if you self-host, GitHub Actions if you're already on GitHub, and a dozen hosted alternatives that work fine.

What breaks is rarely the pipeline itself:

• Environment drift. The build passes in CI and fails on the server, because the two environments diverged. Containerising the build is the standard fix and it works.
• Slow suites. A 40-minute pipeline stops being a safety net and becomes a thing people route around. Parallelise, or split fast checks from slow ones and gate merges on the fast ones.
• Flaky tests. One test that fails 5% of the time teaches an entire team to re-run red builds without reading them. That habit costs more than the flaky test ever did. Quarantine it the same day.
• Secrets sprawl. Credentials in a pipeline config, then in a fork, then in a log. Use your CI system's secret storage from day one; retrofitting is miserable.

The failure mode is consistent: automation that's slow or unreliable gets ignored, and ignored automation is worse than none, because it provides the appearance of a safety net without the substance.

Layer five: AI code generation, and where it actually helps

This is the layer that changed most recently, and where the claims run furthest ahead of the practice.

AI coding automation is genuinely good at:

• Boilerplate with a known shape — a data class from a schema, a client from an API spec, a test scaffold
• Mechanical translation — a config format to another, a function between languages
• The first 80% of a function you can describe precisely
• Explaining unfamiliar code, which is underrated and low-risk

It's unreliable at:

• Anything depending on context that isn't in the files it can see
• Architectural decisions, where a plausible answer and a good answer diverge sharply
• Debugging subtle behaviour, as opposed to obvious errors
• Anything you can't quickly check — which brings back the same rule that governs the rest of the stack

Terminal-based tools like Claude Code sit closer to the automation stack than editor autocomplete does, because they can run the tests and read the failures themselves. That loop — generate, run, read the error, fix — is what makes the difference between a suggestion engine and something that finishes a task.

The prerequisite is layers one through four. AI generation is only safe at speed when something else is checking the output automatically. Without tests, a code generator is a way to accumulate unverified code faster. Our post on coding agents covers where they hold up and where they break in more detail.

A sensible order to add this to an existing project

1. Formatter and linter, in a pre-commit hook. One hour, no downside.
2. Tests for whatever broke most recently in production. Not full coverage — the specific thing that hurt.
3. CI running format, lint, and tests on every pull request. Now the checks are enforced rather than optional.
4. Automated deployment on merge to your main branch. Manual deploys are where release-day mistakes live.
5. AI generation, once 1–4 are reliable. By this point you have a system that catches what it gets wrong.

Skipping to step 5 is the common mistake, and it's more tempting than ever. The result is a codebase growing faster than anyone's ability to verify it.

If you're coming at this from the scripting side rather than the software-engineering side, Python for automation covers the other meaning of the term — writing automation as the product rather than around it. And how to install Claude Code walks through getting a terminal agent running if that's the layer you're missing.

For people who keep hitting the setup wall before reaching any of this, Taku mirrors a working AI setup into a desktop workspace and runs it there, so a development workflow someone else configured becomes usable without reproducing their environment. Taku is in Beta, and the Mac app is available now.

Key points

• Programming automation has five layers: formatting, testing, build, deployment, and code generation.
• Add them bottom-up; generation without testing produces unverified code faster.
• Formatting and linting are the cheapest wins available and take about an hour.
• Slow or flaky pipelines get routed around, which is worse than having no pipeline.
• AI generation works on well-specified, checkable work and fails on architecture and undocumented context.

FAQ

What is automation in computer programming?

Two things: writing programs that automate a task, and automating the work of programming itself — formatting, testing, building, deploying, and generating code. The second is what determines a team's shipping speed.

Is automation coding the same as scripting?

Scripting is one form of it — writing a small program to handle a repetitive task. The broader term includes the pipeline infrastructure that runs around your code automatically, which usually isn't scripting at all.

Should I automate testing before or after setting up CI?

Write the tests first. CI without tests only checks that the code compiles. Even a handful of tests covering your riskiest paths makes a pipeline worth having.

Can AI replace the rest of the automation stack?

No, and it's the layer that most depends on the others. AI generation produces code that needs verifying; formatters, linters, and tests are what verify it. The stack becomes more valuable as generation speeds up, not less.

How much automation is too much for a small project?

If maintaining the pipeline costs more than the errors it prevents, you've overshot. For a solo project, a formatter and tests on the risky parts is usually the right stopping point until something breaks in production.