Three months ago I did something that felt either very smart or very self-defeating depending on the day: I sat down and systematically automated every repetitive part of my own engineering workflow. CRUD scaffolding, test generation, PR descriptions, code review checklists, standup summaries — all of it. Gone. Handed off to the same agentic tooling I build for clients.
Here is what I expected: more time, more output, same job but easier.
Here is what actually happened: something considerably weirder.
The Part That Went As Expected
The time savings were real and immediate. I was spending — and this was genuinely embarrassing to calculate — roughly 70-75% of my active coding time on work that required no actual thought. Boilerplate that follows known patterns. Tests for functions I already understood completely. PR descriptions that were just structured summaries of diffs I’d already reviewed. Mechanical work dressed up as skilled labour.
Automating it was straightforward because it was straightforward. Pattern-matching tasks with clear inputs and outputs are precisely what LLM agents are good at. Within two weeks the scaffolding was running autonomously, my test coverage went up because writing tests became zero-friction, and my PRs became better documented because the agent doesn’t get bored halfway through a description.
Good. Fine. Expected.
The Part Nobody Warns You About
What I did not expect was the psychological discomfort of suddenly having time to think.
This sounds absurd. Everyone claims to want more time. But there is a specific comfort in busyness — particularly in busyness that looks like productivity. Writing boilerplate feels like working. It produces visible output. Lines of code accumulate. The progress bar moves.
Thinking produces nothing visible for extended periods. It produces questions, dead ends, diagrams that get thrown away, and eventually — sometimes — a significantly better architecture than the one you would have built if you’d just started coding immediately.
Sitting with a blank document and actually reasoning about system design, tradeoffs, failure modes, and long-term maintainability feels, in the short term, like doing nothing. The output is invisible. The discomfort is real. Most engineers — myself included, more than I’d like to admit — default to building over thinking because building feels more productive, even when thinking would produce better results.
Removing the boilerplate removed the escape hatch.
A significant portion of what I thought was “deep work” was actually structured procrastination. Writing tests I already knew would pass. Scaffolding I’d written a hundred times before. It felt like work because it produced code. It wasn’t work. The automation just made that obvious.
What Changed About the Job
The role didn’t disappear. It shifted, which is the more interesting outcome. The things that remained after automation were exactly the things that were always actually hard:
- Understanding ambiguous requirements well enough to ask the right clarifying questions
- Making architectural decisions that will matter in two years
- Reviewing the agent’s output critically rather than accepting it at face value
- Knowing when the automated approach is wrong and why
These are not things a current LLM agent can do reliably. They require domain knowledge, contextual judgment, and the ability to reason about systems that don’t exist yet. They are also, not coincidentally, the things that clients actually pay for.
The Axon Parallel
This is exactly why I built Axon the way I built it. Axon handles the implementation — ticket to PR, code written, tests run. What it explicitly does not do is decide what to build, question whether the ticket is the right solution, or flag architectural concerns that aren’t captured in the requirements.
Those things still require a human. Specifically, they require a human who isn’t spending 75% of their time writing boilerplate.
The honest answer to “did you automate yourself out of a job” is: no. I automated myself out of the boring parts of my job, and in doing so discovered that the interesting parts take considerably more energy than I’d been giving them — because the boring parts had been consuming the energy that should have gone to the interesting parts.
If you’re an engineer and that doesn’t sound familiar, I’d ask you to track your time honestly for one week. Not what you think you spend time on. What you actually do, hour by hour.
The number will be uncomfortable. That discomfort is the beginning of something useful.