I spent months building automation that removed work I used to do by hand. Each successful run felt like progress. Each deleted checklist felt like clarity. Then a quieter question showed up: if the busywork disappears, what is left for the engineer to own?
This is not a prediction about jobs vanishing overnight. It is a working note from shipping systems that take responsibility for coordination, validation, and repetition. The point is not fear. The point is judgment.
What automation actually removes
Automation is good at the parts of engineering that are already decided. When the path is known, the inputs are structured, and the failure modes are enumerated, a machine can move work farther than a person staring at the same queue every morning.
That is valuable. It is also incomplete. The work that remains is the work that was never fully decided: tradeoffs, incomplete requirements, integration seams, and the moments when the system tells you something you did not ask for.
When teams automate without redesigning ownership, they often delete the visible labor and leave the invisible judgment unassigned. The dashboard looks quieter. The decisions do not.
The engineer is not the queue
A useful distinction: the engineer is not the queue of tickets. The engineer is the person responsible for whether the queue means anything.
Automation can clear a queue. It cannot decide whether the queue is the right representation of the problem. It cannot decide when a green check is lying. It cannot decide when a retry loop is papering over a broken contract.
Those calls still require someone who understands the system as a whole. If that person is missing, automation does not free the team. It hides the cost until production explains it later.
What I still have to do by hand
On the platform I was building, the durable work looked less like typing and more like responsibility:
- Naming the real source of record when three tools disagreed
- Choosing fail-closed behavior when a partial write would corrupt state
- Deciding which signals were evidence and which were noise
- Writing the test that proved a path would not create duplicates
- Explaining the system so another engineer could change it safely
None of that disappeared when scripts started running. Some of it became more important because the scripts made the consequences arrive faster.
Automating yourself out of the wrong job
There is a version of this question that is self-flattering: "Will AI replace me?" There is a better version: "Which parts of my job were never the job?"
If your value was moving the same data between the same screens, then yes, automation will push that work away from you. That is not a tragedy. That is the system doing what you asked.
If your value is deciding what should be true when the tools disagree, automation will not replace you. It will expose whether you were doing that work or merely looking busy next to it.
Production is the remaining curriculum
The systems that hold up in production are still designed by people who can hold competing constraints at once: correctness, operability, cost, clarity, and the social reality of who will maintain the thing at 2 a.m.
Automation is part of that craft. It is not a substitute for it. The engineers I trust most use automation to remove repetition so they can spend more time on the decisions that cannot be scripted yet.
So no, I do not think I automated myself out of a job. I automated myself out of the parts of the job that were never supposed to be the point. What remains is the work that makes the automation trustworthy.
That work is still engineering. It still requires taste, accountability, and the willingness to own outcomes when the script cannot.
If the busywork disappears, the engineer who remains is the one who can still answer for the system.
Where judgment shows up in practice
Judgment shows up when an integration returns a 200 and the payload is still wrong. It shows up when a retry succeeds for the wrong reason. It shows up when two sources of truth disagree and somebody has to choose which one the product will believe tomorrow morning.
Those moments do not look dramatic in a sprint board. They look like quiet engineering: reading logs, tracing ownership, writing the smallest guard that prevents the next silent failure. Automation can execute the guard. It cannot invent the guard from a vague feeling that something is off.
I have watched teams celebrate a green pipeline while a business process was still held together by one person's memory. The pipeline was honest about what it checked. It was silent about what nobody had encoded yet.
Coordination is not a side quest
A surprising amount of production software is coordination work wearing an engineering costume. Status updates, handoffs, approvals, and ownership problems dominate real systems long before algorithmic novelty does.
Automating coordination without clarifying ownership creates a faster mess. The events move. The accountability does not. Someone still has to decide what done means when three systems each claim progress.
That is why I care about application-owned state, explicit health checks, and idempotent paths. Those are not fashion preferences. They are mechanisms for keeping coordination inspectable when people are busy or unavailable.
Taste still matters
Taste is not decoration. Taste is the habit of refusing a design that will be expensive to operate, even when it is easy to demo. Taste is deleting a feature that creates support debt. Taste is naming things so the next engineer can find the decision without a meeting.
Automation without taste accelerates whatever design already exists, including the bad parts. That is why the engineer remaining after the busywork leaves is not a prompt operator. It is a steward of constraints.
What I tell myself when the script wins
When a script removes an hour of work, I ask three questions:
- Did we remove labor, or did we remove visibility?
- Can another engineer explain the failure modes without me?
- If this runs twice, does the system stay honest?
If the answers are weak, the automation is incomplete. If the answers are strong, the automation earned its place and I can spend the recovered hour on harder problems.
That is the bargain I want with tools: they take the repetition, I keep the responsibility.
Closing the loop
The fear of being automated out of a job usually assumes the job was typing. For senior engineering work, the job is deciding what should be true and proving it under pressure. Tools will keep getting better at execution. The need for accountable judgment will not vanish because a workflow ran cleanly once.
I am still here because the system still needs someone who can answer for it. That is not nostalgia. That is the job.