From AI-Assisted to AI-Orchestrated: A Software Engineer's Reluctant Evolution

Last week I shared how an AI-first estimation challenge pushed me to rethink how I work. What started as a reflection on estimation turned into something much bigger — a shift in how I think about the future of software engineering itself.

Here's what happened next.

The tool that wasn't enough

After that estimation challenge, I was drowning in context. Multiple LLM context windows, terminals, browser tabs, different branches for different features — and on top of it all, the usual triage issues, Slack discussions, and meetings that don't stop just because you're deep in a complex task.

So I built a tool. A small platform to bring some organization to the chaos of managing all those parallel LLM sessions while working across branches and responding to the day-to-day.

It worked. I finished that ambitious project — a few days later than the challenged estimation dictated, but still way earlier than the traditional process would allow. I call it a success.

I was quite proud of it, for a couple of days.

The click

Then I sat down to write my manager a message explaining what I'd achieved, how the tool worked, how my life was now easier — and something clicked.

I had seen other people building similar things. But the essence of what I'd built was managing windows. And managing windows doesn't scale.

Here's what the average developer's day looks like right now: you sit in a single LLM context window, ask it something, and wait for a response. The response takes a bit, and that gap creates an opening for attention dispersion. So you do what any professional software engineer would do — you open another context window and start working on something else.

Then the first one replies. An incident happens. A Slack thread lights up. Maybe a meeting in the middle. By the end of the day, you have many things half-done and a vague sense that the day slipped through your fingers.

My tool helped me organize all of that. It gave me context when I returned to an abandoned session. But LLM conversations would still sit idle for hours while I dealt with something else, and picking them back up — even with more context — was still cognitively expensive. The work wasn't getting done while I was away. It was just… waiting.

The uncomfortable realization

Meanwhile, as I've been doing, I kept following what's happening in the world. The layoffs. The market shifts. The speed is ever-increasing.

And I started having this philosophical debate with myself — the one everyone is having — about the future of software engineering as a profession.

We're already past the discussion of paying someone to write code by hand. That's settled. But here's what I started thinking: will companies be able to keep paying someone to eyeball every line of code change?

The economics don't match.

I think the answer is no. I think our codebases must become something more organic. And I suspect that's the way it has to be to compete in the market that's forming.

This is uncomfortable for engineers like me. Good, proud professionals — and I consider myself one — take pride in the lines of code they push out. They care about style, test coverage, and clean processes. While working on that AI-first project, I found that keeping up with the LLM required roughly the same cognitive effort as writing the changes myself, in a much denser amount of time. It's still way, way faster than the traditional approach — I'm not debating that. But if you deeply care about understanding what you're pushing out, and you must with traditional processes, it's still quite a cognitive overburden. I was exhausted by the end of it.

The question that changed everything

So the real question became: how can we keep governance over what we produce without eyeballing and fully understanding every single line of code?

I'm not suggesting full YOLO mode. That's still concerning. But I see the need to evolve into something closer to a high-level architectural overview — less dedicated line-by-line scrutiny, more structural governance.

And that's when I realized: I was the bottleneck.

My tool helped me manage multiple LLM sessions, but I was still in the middle of everything. Still too much manual eyeballing. Still too many manual approval steps in the loop.

The old machine

I'm not crazy enough to give an LLM free reign on my main machine with all my secrets and credentials on it. But I had an old computer sitting around. So I formatted it and gave an LLM complete and full control.

Then I started a conversation with it about how to solve this problem.

What emerged was an orchestration system. A company of agents, per se.

There is a base system that orchestrates the whole thing. A web application with a dashboard where I get notifications, start work, and see feedback. When a task is inserted, agents collaborate with each other to get it done (the collab part still needs work).

The processes I put in place resemble what a real team actually does. There's a discovery phase where we figure out what to build. I dispatch different agents to work on different parts of the codebase, even on the same task. Development work runs autonomously. And at the end, I get a PR to review.

I also built an internal GitHub-like tool where my agents push their code. I review and approve there, or ask for changes — just like a normal team would. When I'm satisfied, I push the resulting changes to the real, public-facing company repositories.

It's rough around the edges, but it mostly works. And it looks a lot like where this industry is heading. At least, in my eyes.

I'm not claiming innovation, I saw a few people talking about doing the same thing, and there are a few tools around to build similar orchestration, but eih, this is my story.

The real debate

The debate is no longer whether to use AI in development. In my mind, that's settled. The real question is: how do we govern this?

We no longer have static codebases where we need to change every detail with the care of someone defusing a bomb. Instead, we're moving toward something organic — because it's cheap enough to just go and redo.

And the philosophical core of the discussion is now about gating. How to keep the system from burning your entire application. How to keep it from causing harm to users. How to ensure it produces quality results without regressions.

The good news: we already have the answers to many of these questions.

My answers so far:

• Isolated environments with carefully managed secrets and access. The LLM runs on a clean, dedicated machine — not my daily drive.
• Agents PR their own code — just like a real team member would. They don't push directly to production.
• Traditional quality control still applies. Linting, unit tests, integration tests — all of it still runs on everything. These processes were already in place. They just needed to be adapted.
• I still review. And I've also started putting together automated review processes for the code my peers submit, augmented by the same tooling.

But my internal debate is now around that last point — how to build an orchestration system safe enough to review at an architectural level, not line-by-line.

What this means

We already have the practices that make this safe. We just need to adapt them to a world where code is generated, not handcrafted. Cover your code with good unit and integration tests. Lint. Do thoughtful PR reviews. Build isolated development environments. Manage secrets with care. It's not a revolution in process — it's an evolution in who (or what) executes within those processes.

I got bitten by the AI bug, but I think we should evolve our discussions beyond the "should we use LLMs" question. That's no longer up for debate. What we need to be discussing now is how to govern the slop — how to make the transition safe, incremental, and sustainable.

We already know how. We just need to do it.

Fun times ahead. I'll need a few more tokens to figure it all out.