Run your agents like a team.
The popular framing — that AI is replacing engineers — is wrong. It's replacing coders. Engineering moved up a layer of abstraction. The tools haven't caught up, and the work in front of all of us deserves better.
Software engineering has rapidly transformed over the last year or two with the rise of agentic AI. At this point, the productivity gains can’t be argued, and there’s no going back for the industry as a whole.
What’s less well understood is what, exactly, has changed.
The popular framing “AI is replacing engineers” is wrong. It’s replacing coders.
Engineering is still a human job: deciding what to build, how to structure it, what the constraints really mean, what’s safe and what’s risky, how the pieces hold up over time. It’s a more important job than it was a year ago. When engineering decisions get translated into code at high velocity, good ones compound faster. Bad ones do too. The discipline has moved up a layer of abstraction.
Writing code is the part AI has gotten very good at. Many engineers, right now, aren’t writing code by hand at all. In a few years, none of them will be.
Consider knit sweaters. People still knit by hand, for the joy of it, to learn, occasionally because the result is genuinely better than what a machine produces. None of those reasons disappear. What disappeared, decades ago, was the professional case for knitting at scale by hand. No one runs a sweater company on hand-knit inventory. The craft persists. The industry moved on.
We’re about to feel the same way about hand-written code. The craft will persist. The professional case is on its way out.
The engineering isn’t going anywhere. The typing is.
The work has a different shape now.
You spend less time typing and more time deciding. You’re doing more context switching, made possible by the agents doing the line-by-line work. You dispatch an agent against a task, you let it work, you check in when it surfaces a question, you review what it produced. You move between projects in a way that would have been impossible a year ago, when sustained focus on one problem was the only way to make real progress.
The rhythm is different too. The old rhythm was focus, type, debug, repeat. The new rhythm is more like dispatch, observe, decide, hand off. You’re not in flow with the code. You’re in flow with the work.
Some days you barely open the editor at all. You read PRs. You answer the question an agent got stuck on. You decide which of two approaches to take. You spec out the next piece of work. You watch an agent push a commit and think actually, no, do it the other way. The mental work is constant. The hands-on work is occasional.
The first time you have a day like this, it’s exhausting. Not in the way coding for ten hours is exhausting. Something different. You spent the day deciding, evaluating, answering questions you didn’t expect, switching modes on someone else’s schedule. None of it felt like the work you remember, and all of it required your attention in a way that’s hard to recover from. The tired isn’t the kind of tired you’re used to.
The work is genuinely alien at first. Useful, clearly. You can already see what’s possible. But also a different shape of mental load than the one your career trained you for. Constant judgment, no natural rest, interruptions that don’t fit any pattern you’ve learned to manage. This is a skill that has to be learned, not just absorbed. The first few weeks are hard.
It fades. The work was always the engineering. The rest was just how you expressed it. What’s left is what was always the actual job.
The tools haven’t caught up.
The IDE is still the center of most engineers’ setup, even though more and more engineers don’t spend their day inside it anymore. Cursor is a great editor with agent features bolted on. Claude Code is a CLI you run in a terminal. Beautifully, but as one of many terminals. Codex is the same. The result, for anyone doing real work with multiple agents, is a workspace that looks like a workaround: three terminals, two browser tabs, a Slack DM to yourself with notes about which branch is which, an editor open mostly out of habit.
None of these tools were designed for the work the way it actually happens now. They were designed for the work the way it happened five years ago, with AI features added at the edges. That’s not a criticism. It’s how categories evolve. The editor was the right tool for the old shape of work. The CLI is the right tool for running a single agent. Slack is the right tool for talking to humans. Each of them is good at what it was built for. None of them was built for the day you actually have.
What’s missing is the surface that sits between them. The place you go to see what your agents are doing, not the place where they do it. The place you dispatch from, the place that tells you which one needs you, the place that holds the thread of work across multiple parallel runs and hands the finished ones off to the systems already good at the next step. The editor stays. GitHub stays. Linear stays. Slack stays. They’re all still useful. What’s missing is the cockpit.
There’s a temptation, when a category is new, to build a tool that does everything: a single application that tries to be the editor and the dispatcher and the review surface and the project tracker. That’s the wrong move. The existing tools are good at what they do. The new tool’s job is to be good at the new thing: managing the work that the existing tools weren’t designed to hold.
If the new shape of work needs a new tool, two problems have to be solved before that tool is worth anything. Everything else is a feature. These two are the foundation.
The first is parallelization.
A single agent is a productivity boost. Two is awkward. Four is chaos. The cliff between one agent and several agents is steep, and most of what makes it steep has nothing to do with the agents themselves. It’s that agents need somewhere to work, and most engineers don’t have a sustainable way to give them one.
The default today is bad. Two agents working on the same repo, in the same directory, contaminate each other’s state in ways neither one notices. One agent checks out a different branch, and the other agent’s session is suddenly on the wrong branch. One leaves uncommitted changes in the working tree, and the other treats them as part of its own context. One generates build artifacts, and the other commits them. The agents aren’t fighting each other. They’re just unaware they’re sharing a workspace.
Git worktrees are the right answer technically. Each agent gets its own isolated copy of the codebase, on its own branch, without touching the others. But setting up worktrees by hand is clunky enough that most engineers don’t, or they hand-roll a script that mostly works until it doesn’t. The mechanism exists. The ergonomics don’t.
Then there’s the rest of the surrounding mess. The agent you forgot was running. The agent you thought was finished but wasn’t. The agent that quietly stopped twenty minutes ago and is waiting for you to notice. Even with worktrees solved, knowing what each agent is doing across several parallel runs is a real problem on its own.
Solving parallelization isn’t just “more agents at once.” It’s giving each agent a place to work that doesn’t collide with the others, and giving the human a way to hold the whole picture in their head. A good cockpit makes both of those answerable at a glance.
The second is security.
This one is a different and evolving kind of problem. We’re still understanding what kind of threat vector agents actually are, and nobody fully knows yet. The right default, as with most things in software, is zero trust.
Today’s default isn’t zero trust. It’s 100% trust, with agents acting as proxies for their users. Whatever you can reach, the agent can reach.
The honest version of what’s happening: agents today inherit the user’s entire trust footprint. The same shell environment, the same git config, the same access to whatever the user can read. That made sense when “the agent” was a single instance doing a single task under close supervision. It stops making sense when there are six agents running, half of them on branches you’re not actively watching, executing code that came from prompts that might have come from a webpage one of the agents fetched.
The right model is the same one engineering organizations have used for human contractors for decades: give each agent only what it needs for the task at hand. Scoped credentials. Bounded filesystem access. A clear record of what was used and when. You wouldn’t hand a new hire root on the prod database on their first day. There’s no reason to hand it to an agent either.
These two pillars, parallelization and security, define the work. Get them right and everything else (the integrations, the review handoff, the cost tracking) can be layered on top. Get them wrong and no amount of UI polish will save the tool.
Software engineering as we knew it is rapidly being replaced by software engineering as we will come to know it. Most engineers can already feel it. Some are leaning in. Some are still figuring out where all the cards are going to fall. Both will end up in roughly the same place.
This is good news. The part of the job that’s getting automated was never the interesting part. Engineers who loved the craft of writing code will lose something real, and that loss is worth acknowledging. Engineers who loved building things, solving problems, designing systems, deciding what’s worth making, will spend more of their time doing those things.
The bottleneck is no longer how fast you can type. It’s how well you can think.
What that work needs is tools that match its shape. Cockpits instead of editors. Scoped trust instead of inherited access. Handoffs to the systems that already work, not parallel surfaces that try to replace them. The pieces are obvious once you see the shape.
I’m building a tool along these lines, called Skoga.
If you’ve nodded through any of this, you’re already doing the new work. The tools will catch up. The question is which ones.
Andrew · skoga.dev · 2026
