Everyone keeps telling me my job is about to be automated. Cool. Let me walk you through what I actually did yesterday, and you tell me which agent handles it.
I’m a tech lead. Small team, three engineers, one super senior and two mid-level folks doing most of the implementation. We sit inside a company with over a thousand people. We write a decent amount of code, but we also own our platform and our infrastructure, because we live by the AWS rule: you build it, you run it. That means when it pages at 3am, it pages us. Not some ops team three floors down.
And here’s the thing that keeps getting left out of every „software engineering is dead“ thread on X: coding is the part of my job I spend the least time on. By a mile. The agents got scary good at exactly the slice of my week that was already the smallest slice.
Let me actually show you the day instead of arguing about it in the abstract.
8:30am, pull requests
I open the review queue. My engineers wrote these with agents. Not sloppily. They ran the thing, they read the diff, they caught the obvious bugs themselves, they fixed them before I ever saw it. So what lands on my desk is already high quality. That part is genuinely better than it was two years ago, and anyone telling you otherwise hasn’t used the tools seriously.
So what am I doing for the next hour or two?
I’m looking for the stuff that only shows up when you know where this system is going in six months. Is this interface going to survive the next feature we already have on the roadmap? Did we just leak a domain concept into a place it doesn’t belong? Is this abstraction going to be the thing we’re cursing at during an incident next spring? Is there a flaw that passes every test because the test asserts the same wrong assumption the code makes?
The agent wrote code that works. I’m reviewing for code that keeps working while three other teams build on top of it. Those are not the same review.
One or two hours a day, and I’ll happily spend it. This is the cheapest insurance in the whole org. The classic sign of a bad engineering team is 10 comments on a 10 line PR and 0 comments on a 1,000 line one. I’d rather be the annoying guy on the interface design than the guy explaining the rewrite next year.
Still zero lines of code from me.
Then: other people’s documents
Next up, RFCs and architecture decision records from other teams. Not mine. Theirs.
Why do I care? Because if the platform team changes how identity propagates between services and I find out when it ships, my team eats a sprint. So I read their doc, I map it against where we’re going, and I flag the collision before it becomes a collision.
We run these review circles where every domain has a representative, and a substitute for when that person is out, because „we forgot to invite the data domain“ is how you get a design that has to be redone. So every meaningful decision gets multiple passes with multiple people from multiple angles.
Is it slow? Yes. Getting a document merged and accepted takes ages, and then implementing it takes even longer. Anyone who’s worked in a big org is nodding right now.
Here’s the part I want you to sit with. That slowness isn’t a process failure you can automate away. It’s the cost of a thousand people with different incentives arriving at one decision they’ll all actually honor. You cannot prompt your way to organizational consensus. The bottleneck was never typing speed.
The meetings, yes, the meetings
Daily scrum, thirty minutes. Fifteen on tickets and clarity, fifteen on what blew up yesterday and how we unblock it. That second half is my actual job: someone is stuck on an access request, someone is waiting on another team, someone hit a regulatory question nobody has an answer for. I go make those disappear.
Then planning. Then retro. Then the meetings that appear out of nowhere because a priority moved.
Sprint planning is where I earn my keep. I’m holding a long-term objective in my head and cutting it into pieces small enough that the team can ship something valuable every two weeks without losing the thread. Tickets are missing, so I write them. Priority changed on Tuesday, so I reshuffle and make sure the overarching goal still lands. Scope creeps in sideways, so I push it out.
Nobody wrote code. Value was created anyway. The team knew what to build, why it mattered, and in what order. That’s not overhead. That IS the product decision.
The part that’s actually the job
Now the interesting bit. I have to find problems in the organization that nobody has named yet, then drive the fix.
Real example. People on my team and neighboring teams keep complaining that our regulatory obligations are painful. Not the rules themselves, the evidence. Screenshotting things. Filling in documents by hand. Proving to an auditor that a control existed on a Tuesday in March. It’s simple work and it’s soul destroying and it eats hours that should go into the product.
The engineering answer is obvious to me: stop producing evidence by hand, generate it from the systems that already know the truth. Automate the obligation instead of documenting it.
But knowing the answer is maybe 5% of the work. Now I write the RFC. I get compliance to agree the automated artifact satisfies the actual legal requirement, which is a conversation about risk appetite, not code. I get the platform team to agree to own a piece of it. I find the budget. I find people. I get sign-off from folks who have their own roadmaps and their own bonuses attached to entirely different outcomes. I convince them that this is worth their quarter.
Show me the agent that walks into a room where six departments disagree, understands that two of them are actually fighting about something political from last year, and gets a decision out of it that survives contact with legal.
And if there’s time after all that, maybe I get to build it.
Sometimes I get to write code
Sometimes. I’ll grab a ticket, ship it, open a PR. It’s rare and I won’t pretend otherwise. It’s a few percent of my day.
I keep doing it on purpose. The moment you stop touching the code, your architecture opinions start drifting into fantasy. You become the person who says „just add a feature flag“ to a system where feature flags cost three days. Staying hands-on is how I keep my reviews honest.
But let’s be precise about what this means. The single thing AI has fully transformed is the smallest fraction of my week.
The uncomfortable math
Here’s the harshest reality I think a lot of y’all haven’t internalized: the coding was never the hard part at scale.
If you’re five people in a room, ignore everything I just said. You have no communication overhead, you have no review circles, your compliance story is a spreadsheet, and you can ship whatever you want on a Friday. AI agents are a genuine superpower for you and you should be running as fast as you can.
But somewhere north of thirty people, the physics change. Coordination cost shows up and it never leaves. And the brutal part is you can’t opt out, because scaling the organization is how you serve more customers, ship more features, and make more money. You grow because growth is the point. The overhead is the tax on the thing you wanted.
Meanwhile, none of the old rules got repealed. We still need maintainable code, because someone is on call for it. We still need real rollout processes, because a bad deploy in a regulated environment isn’t a rollback, it’s an incident report. We still need tests, and honestly, our customers ask for the test results. They want to see them. Try vibe coding your way through that conversation.
Agents made writing code dramatically easier. They did not make software engineering easy. Those were always different problems, and we just spent two years pretending they were the same one because one of them finally got solved.
So what actually changes
I’m not going to sit here and tell you nothing changes. That’s the other dumb position.
What I think happens is the roles start collapsing into each other. The line between software engineer, product manager, and product owner is getting blurry, and I don’t think it survives this decade. When implementation gets cheap, the scarce thing becomes deciding what to implement, and defending that decision, and threading it through an organization that has opinions. That’s a product skill. That’s a political skill. That’s a communication skill.
The engineers who thrive won’t be the ones who type fastest. They’ll be the ones who can walk into a room full of stakeholders, understand what everyone actually wants under what they say they want, and leave with a decision. Then go implement it with an agent in an afternoon.
So no, we’re not close to automating software engineers. We got very good at automating the one part of the job that was already the easiest to explain to your non-technical cousin. Everything else, the alignment, the judgment, the sitting in a review circle for the fourth time, the knowing which battle to fight this quarter, is still stubbornly, expensively human.
Yesterday I wrote zero lines of code, and my team shipped. That’s not a bug in how I spend my time. That’s the job.
Peace, nerds.