Am I Automating Myself Out of a Job?
What building automation systems taught me about how the role of a software engineer is actually changing
The uncomfortable thought
At some point while building WorkAnt, I caught myself asking a question I didn’t expect to feel so personal: am I automating myself out of a job? Not in the abstract “AI is coming for everyone” sense, but in a very real way. The kind where you watch tasks you’ve done for years quietly turn into a button click.
I didn’t start building WorkAnt to replace developers. I started building it because I was tired of wasting developer time. Tickets drifting out of sync. Manual project updates. Status meetings that existed only because the tools couldn’t talk to each other. These were the kinds of problems that always felt beneath the level of work senior engineers were supposed to be doing, yet somehow kept consuming their days.
As WorkAnt began to take shape, something unexpected happened. The more effectively it automated those pieces, the more it forced me to confront an uncomfortable thought: if this works the way I intend it to, what happens to the person who used to do all of this?
That question wasn’t rooted in fear of AI. It was rooted in identity. When you remove enough friction, busywork, and manual glue from a system, you are left with a harder question than “will this replace me?” You are left asking what your role actually is when the noise is gone.
This didn’t start with AI
Looking back, this tendency didn’t start with AI, or even with my career. When I was a kid in school, my teachers used to tell my mom that I was always looking for the easiest way to solve a problem. It was never meant as a compliment. What they saw was avoidance. What I felt was efficiency.
If there was a way to solve the entire problem once instead of solving pieces of it over and over again, that was the path I gravitated toward. Even then, I wasn’t trying to do less work. I was trying to eliminate unnecessary work.
The first time I can clearly remember applying that instinct was with Excel. I built a gradebook that didn’t just store scores, but calculated them, organized them, and generated a printable report card automatically. Instead of manually tracking numbers and rewriting the same information, the system handled it. Once it was set up, the work didn’t disappear. It changed. The effort moved from repetition to design.
That pattern followed me into my career as a developer. Long before AI was part of the conversation, I was drawn to automating process rather than just code. Project boards that updated themselves. Workflows that didn’t require constant human babysitting. Systems that reflected reality instead of relying on someone to remember to keep them accurate.
By the time COVID hit, this mindset was already baked into how I worked. I wasn’t trying to replace people or roles. I was trying to remove fragile, manual steps that always broke under pressure. Every automation I built came from the same place: if something has to be done more than once, there is probably a better way.
What’s different now isn’t the instinct. It’s the scale. AI didn’t create my interest in automation. It simply gave that instinct more leverage.
Where WorkAnt actually came from
WorkAnt didn’t start as a standalone product. It started as part of my portfolio build. As I began using AI more heavily to architect systems, something interesting happened. My ability to think in terms of automation evolved alongside my ability to build it.
AI wasn’t just helping me write code faster. It was helping me recognize patterns sooner. Repetitive steps. Fragile handoffs. Places where context was lost because a human had to remember to do something at exactly the right time, every time.
That’s where WorkAnt began to take shape.
Take code reviews as a simple example. We all know AI is good at them. Not perfect, but consistently strong at a first pass. So the question stopped being “should AI review code?” and became “why is this still a manual step at all?” If a pull request is opened, why shouldn’t an automation trigger a review automatically, leave structured feedback, and create a clear communication paper trail?
Once you frame the problem that way, the rest starts to fall into place. The value isn’t just the AI review itself. It’s the orchestration around it. When it runs. How it reports. Where feedback lives. How decisions are documented. That isn’t replacing judgment. It’s supporting it.
As I built more of these automations, the pattern became obvious. WorkAnt wasn’t automating engineering. It was automating the connective tissue around engineering. The work that needs to happen, but doesn’t require a senior engineer’s full attention to happen correctly.
This is the point where the original question returned, louder than before. If I can automate this much of the workflow, what exactly am I still responsible for?
And the answer wasn’t “less.” It was “different.”
What’s actually being automated away
As my portfolio build evolved and more of these automations came together, the fear I originally felt began to shift. It stopped being about whether automation would replace me and became about what it was actually replacing.
What kept disappearing wasn’t thinking. It wasn’t judgment. It wasn’t experience. What disappeared was friction. Manual coordination. The constant need for someone to act as glue between systems that should have been talking to each other in the first place.
The uncomfortable truth is that some roles are built almost entirely around that glue. Moving things along. Keeping tools in sync. Chasing updates. Translating status from one place to another. When those responsibilities get automated, it can feel like the role itself is being erased.
But that doesn’t mean engineering is being automated away. It means a certain version of it is.
The kind of engineering most at risk isn’t creative or strategic. It’s the kind that confuses motion with progress. The kind that relies on manual steps because “that’s how we’ve always done it.” Automation doesn’t eliminate those engineers overnight, but it does quietly remove the justification for staying the same.
What becomes more valuable in its place is harder to define, but easier to recognize. The ability to see systems instead of tasks. To design workflows that don’t break under scale. To reason about tradeoffs, failure modes, and human behavior. Those things don’t disappear as automation improves. They become the work.
By the time I reached this point, the original question felt almost backward. I wasn’t automating myself out of relevance. I was removing the parts of the job that never should have defined it in the first place.
From writing code to shaping outcomes
Over the last couple of years, my role as an engineer has changed more than it did in the decade before it. I used to measure progress by how much code I wrote. How many problems I personally solved line by line. Being hands-on meant being deep in the implementation every day.
That’s no longer the best use of my time.
As automation became more central to how I work, I shifted from constantly writing code to supervising how code gets produced. Not in a detached or managerial sense, and not by stepping away from the work itself. I remain deeply involved in the decisions. The difference is where the effort goes.
By automating repetitive tasks, reviews, and coordination, I freed up space to focus on architecture, system design, and quality. Instead of spending energy on mechanical steps, I can reason about structure, tradeoffs, and long-term impact. The work didn’t become less technical. It became more deliberate.
This isn’t about being hands-off. It’s about being hands-off with repetition while staying fully hands-on with experience. Automation didn’t remove my judgment from the process. It amplified it. The systems I design now carry forward decisions I once had to repeat manually.
That shift raises a new question, one that feels more important than the original fear of obsolescence. If my value no longer comes from producing code directly, but from shaping how code is produced, what comes next?
That question doesn’t have a neat answer yet. But it does point in a direction. The future role of an engineer looks less like an individual contributor racing to keep up, and more like someone designing leverage. Someone responsible not just for what gets built, but for how reliably, sustainably, and thoughtfully it gets built.
The question that matters now
I don’t think the right question anymore is whether automation will make engineers obsolete. That framing assumes the role is static, that what we’ve always done is what we are supposed to keep doing.
What building WorkAnt and my portfolio work forced me to confront is something simpler, and harder. If automation continues removing the repetitive parts of the job, we are left with the parts that actually require experience. Judgment. Taste. Systems thinking. Responsibility.
That shift can feel unsettling, especially if your identity has been tied to being the person who writes the code. It certainly was for me. But looking back, the discomfort wasn’t a warning sign. It was a transition.
I don’t know exactly what the engineer role looks like five years from now. I do know that resisting automation isn’t how you stay relevant. Designing it thoughtfully, understanding its limits, and knowing where human judgment still matters feels like a better path forward.
So maybe the real question isn’t whether I’m automating myself out of a job. Maybe it’s whether I’m willing to evolve along with the tools I’m building, and let my role change as the work changes.
For now, that question is enough to keep me building.
