The Software Engineer Is Becoming an AI Orchestrator

I joined the industry as a software engineer intern in 2021. Back then, getting better at the job meant one thing to me: getting better at writing code.

A little over five years later, a large part of my day looks different. I describe problems to an AI agent, read what it did, push back on parts of it, and decide whether the result is good enough to ship. My job title hasn't changed much in that time, but the work has.

I want to write down how that happened, mostly because it's easy to miss a change like this while you're in the middle of it. I also want to work out what I actually think about it, because my opinion has changed more than once along the way.

2021: When AI Wasn't Part of My Workflow

My programming fundamentals came from a textbook: Programming in ANSI C by E. Balagurusamy, the book a lot of engineering students learn C from. C is a good first teacher because it doesn't hide much. You declare your types, you manage your memory, and when you get something wrong, the program doesn't always tell you politely. You learn early that the computer does exactly what you said, which isn't always what you meant.

Later I moved toward Node.js and spent most of my time there. That's where I got comfortable building real things: APIs, database queries, async code that behaved strangely until I understood the event loop. Slowly I went from "I hope this works" to "I know why this works", which I think is the most important change in any developer's first few years.

AI was around. GitHub Copilot had a technical preview in mid-2021. But it wasn't part of my day-to-day. My workflow was the same as everyone else's: read the docs, write the code, run it, read the error, search the error, open a few Stack Overflow tabs, find an answer that was close to my problem but not quite the same, adapt it, try again.

That loop was slow, and it was also how I learned. Every bug I fixed taught me something about how the system underneath worked. I didn't think of it as a "workflow" at the time. It was just programming.

Then ChatGPT Changed the Way I Searched for Answers

ChatGPT was released to the public on November 30, 2022. I don't remember a dramatic moment of realizing everything had changed, because for a while it hadn't. What changed first was smaller and more personal: how I looked for help.

I wasn't asking it to build applications. I used it for small things:

• a snippet I knew how to write but didn't want to look up again

• an error message I didn't understand

• a bug I'd been staring at for too long

• "explain what this code is actually doing"

The biggest difference was that I needed Stack Overflow a lot less.

Searching Stack Overflow is really a matching problem. You have a specific problem, and you look for someone else's problem that is close enough. You read the question, check whether their versions match yours, skim the accepted answer, scroll to the answer with more votes that says the accepted one is outdated, and then translate all of that back into your own code.

With ChatGPT I could skip the matching. I could explain my problem, paste my code and error, and ask a follow-up when the first answer didn't fit. It felt less like searching and more like asking a colleague who never got tired of questions.

I wasn't the only one who changed habits. Researchers who studied Stack Overflow after ChatGPT's launch measured a clear drop in posting activity within months.

Less time matching my problem to someone else's, more time just describing mine. (Photo: Unsplash)

It wasn't magic, though. Those early answers could be confidently wrong. They sometimes suggested functions that didn't exist or mixed up library versions. You still had to understand the answer well enough to know whether to trust it. In a way, that kept me honest.

And through all of this, one thing stayed the same: I was still the one writing the code. AI sat next to my editor. It didn't work inside my project. It answered questions, and I did the building.

I Didn't Want AI to Write My Code

When AI tools started to offer more than snippets, when you could ask for a whole feature, I resisted.

I was one of those developers who didn't want Claude, or any model, writing the full implementation. I had a strong feeling that I needed to own the code, and to me, owning it meant writing it. If I didn't personally type most of the implementation, it felt like I wasn't really doing the engineering. I was just supervising.

I still think that instinct came from a reasonable place. Writing code was how I understood code. It was how I learned Node.js in the first place. And there's a practical side too: if something breaks in production, "the AI wrote that part" is not an answer anyone wants to hear. I wanted to understand every line I was responsible for, and writing it myself was the only way I knew to get there.

But looking back, I think part of that belief was built on a mix-up.

When I think about the parts of building software that were actually hard, they were rarely the typing. They were figuring out what the requirement really meant. Choosing a data model I wouldn't regret later. Working out why something was slow. Deciding what not to build. Noticing the edge case nobody mentioned.

Typing the code was the last step of all that thinking. It was the most visible part of my work, so I treated it as the work.

I had been confusing typing with engineering.

The Agentic Coding Era

The next change wasn't a better chatbot. The way I worked with these tools changed.

Anthropic released Claude Code as a research preview in February 2025, alongside Claude 3.7 Sonnet, and made it generally available in May 2025 with the Claude 4 models. OpenAI shipped Codex CLI in April 2025 and a cloud-based Codex agent a month later. Cursor and other editors added their own agent modes. The tools differ, but they share one idea: the model doesn't only answer you. It works in a loop with tools.

That loop is what people mean by agentic coding. The model reads files, searches the repository, edits code across several files, runs commands, reads the output, notices that a test failed, and tries again until the task is done or it gets stuck.

Compare two requests:

"Write me a function that validates an email address."

"Users can currently sign up with an invalid email. Find where sign-up validation happens, fix it, add tests, and make sure the existing tests still pass."

The first is a question. The second is a task. With the first, I am still the integration layer. I copy the function, figure out where it goes, wire it up, and test it. With the second, the agent finds the relevant files itself, follows the existing patterns in the codebase, changes whatever needs changing, and runs the test suite to check its own work.

Each new generation of models has been able to handle more context and stay on track for longer. That matters more than it sounds. Early on, these tools fell apart on anything that spanned more than a few files. Now an agent can explore an unfamiliar repository, form a reasonable picture of how it fits together, and make a change that touches the API, the database layer and the tests in one go. If you let it, it can run your deploy too. From the agent's point of view, a deploy is just another command.

An agent works across the whole repository, not one function at a time. (Photo: Unsplash)

This is the point where my resistance stopped making sense to me. The question was never really whether AI would write code. It was whether I would keep doing by hand the part of the job that a machine can now do reasonably well, while the part only I can do got less of my attention.

I Think "Owning the Code" Means Something Different Now

This is the part I've thought about most.

My old definition was simple:

I wrote the code, therefore I own it.

The definition I'm moving toward is:

I understand the system, I made the decisions, I validated the implementation, and I am responsible for the result.

Authorship and responsibility were the same thing for most of software history, because the person who wrote the code was usually the person responsible for it. Agents split those two apart. You can now be fully responsible for code you didn't type, and that's not really new. A tech lead who reviews and merges a teammate's pull request owns that change, even though they didn't write it. Nobody thinks they're doing less engineering for it.

Here's a real example from this blog.

The blog's backend felt slow, so I asked an agent to speed it up. It looked at the setup and found that the biggest problem was boring: the backend Lambda was running in us-east-1, while the MongoDB database was in Mumbai. Every query crossed the world and back, which cost around 200 ms per round trip. Moving the backend to the same region as the database brought that down to about 2 ms. Warm requests went from somewhere between 0.2 and 1.6 seconds to a few milliseconds inside Lambda, and cold starts dropped from about 3.5 seconds to about 1.1. In the same piece of work it consolidated the routes into a single Lambda, added an MCP endpoint so an AI agent can manage posts on this blog, and wrote 19 new tests.

That was a good result, and I'll admit it was faster than I would have managed alone.

It also added an EventBridge schedule that called the Lambda every five minutes to keep it warm.

From a purely technical point of view, that's a standard fix for cold starts. Plenty of production systems do it. But it wasn't what I wanted. For a personal blog, I'd rather have a visitor wait an extra second after a quiet period than have something hitting my infrastructure every five minutes, forever. So I had it removed and accepted the roughly one-second cold start.

The full sequence went like this:

Requirement: "the blog is slow"
  → Agent investigates and implements (region move, single Lambda, warm-up schedule)
  → Tests pass
  → I review what it actually did
  → Correction: remove the scheduled warm-up
  → Deploy

The tests passed with or without the warm-up. Tests check whether code does what it's supposed to do. They can't tell you whether it should do that. That was a judgment call about cost, about how much automation I want running in my personal AWS account, and about what "fast enough" means for this particular site. The agent didn't have that context. I did, and supplying it was the actual work.

That's why accepting generated code without reading it is still dangerous, and possibly more dangerous than before. A wrong snippet from ChatGPT in 2023 usually failed loudly. Code from an agent in 2026 usually works. It compiles, the tests pass, and it may still be the wrong decision for your situation. A schedule you didn't know about, a permission broader than it needs to be, a dependency you wouldn't have chosen, a caching layer that hides a bug. These things don't show up as red text in your terminal.

I'm not the only one uneasy about this. In Stack Overflow's 2025 Developer Survey, 84% of respondents said they use or plan to use AI tools, yet more of them distrusted the accuracy of those tools (46%) than trusted it (33%). Developers use these tools more and trust them less. I don't think that's a contradiction. I think it's the correct attitude.

From Coder to AI Orchestrator?

If the engineer isn't mainly the person producing every line, then what are they?

The best word I've found is orchestrator. I don't mean someone who throws prompts at a model and hopes for the best. I mean someone who coordinates a lot of capable but context-blind work toward an outcome they're responsible for.

In practice, a feature might go something like this:

Product requirement
        ↓
Engineer understands the problem (and what's not being said)
        ↓
Breaks it into tasks small enough to verify
        ↓
Gives the agent context: constraints, conventions, what not to touch
        ↓
Agent explores the codebase
        ↓
Agent proposes or implements a solution
        ↓
Engineer reviews: design, security, cost, edge cases
        ↓
Agent fixes the issues raised
        ↓
Tests + validation (including the things tests can't check)
        ↓
Engineer makes the final decisions
        ↓
Deployment

The agent does a lot of the work in that flow. But every arrow that involves judgment goes through a person. The engineer decides what the problem is, what good looks like, which approach to take, and whether the result is acceptable.

A conductor doesn't play every instrument, but is still responsible for how the whole piece sounds. (Photo: Unsplash)

The orchestrator role, as I see it, involves:

• understanding the problem well enough to explain it to someone with no context

• breaking it down into pieces that can be checked one at a time

• giving the agent the right context, because an agent with bad context will make confident, consistent mistakes

• choosing between approaches, and knowing why

• reading the implementation critically instead of skimming the diff

• testing assumptions, not only code

• thinking about security, cost and failure modes

• connecting systems the agent can't see, like the billing dashboard, the on-call rotation, or the product decision made in a meeting last week

• knowing when to stop the agent and do it yourself

• taking responsibility for whatever ships

None of this means engineers stop writing code. I still write code, sometimes because it's faster than explaining what I want, and sometimes because I need to understand something properly. What changes is that writing code is no longer the only way, or even the main way, that my engineering judgment turns into working software.

But Here Is the Part That Makes Me Uncomfortable

Everything I just described depends on one thing: the engineer being able to tell good code from bad code, and good decisions from bad ones.

Where did I get that ability? From writing a lot of code. From the C book. From Node.js bugs that took a whole afternoon. From being wrong many, many times while the feedback was slow enough that I had to understand why I was wrong.

So the question that bothers me is this: if an agent can do in minutes the implementation work that used to take a junior developer hours, how do junior developers build the experience that makes someone senior?

Reviewing an agent's work well requires instincts that, for most of us, were built by doing exactly the work that's now being automated. It's a bit like being asked to check a translation in a language you never really learned to write.

Could we end up with developers who are very good at asking AI to build things, but who don't understand how those things actually work? Who can produce a working system but can't debug it when the agent is stuck? Who don't recognize that a region mismatch between a function and its database is a 200 ms problem, because they never had to find one themselves?

I don't know. Maybe new ways of learning will appear: using agents as patient tutors rather than ghostwriters, deliberately building some things by hand, or treating every agent diff as something to understand before accepting it. Maybe the skills juniors need will simply be different from the ones I needed. Or maybe we'll find out in a few years that we skipped a step.

I'm not making a prediction here. I just think this is the question our industry should be arguing about, and I don't hear it argued enough.

What Happens to Software Engineering Roles?

I want to be careful here and keep two things apart: what's already happening, and what I think might happen.

What's already happening:

• Agentic coding tools are mainstream. Claude Code, Codex, Cursor and others are normal parts of many teams' workflows, not experiments.

• Engineers are running more than one agent at a time. Codex was built to work on multiple tasks in parallel, and Claude Code can hand work to subagents. Managing several streams of AI work at once is now a skill people are actively developing.

• Usage is going up while trust is going down, as the Stack Overflow numbers above show.

• Reviewing, verifying and giving context take up a larger share of the work than they used to.

What I think might happen, without any certainty:

• Teams could get smaller for the same amount of output. Or they could stay the same size and build much more. I can imagine both.

• Engineers may spend more of their time on architecture, product understanding and talking to the people who use what they build, because that's where the decisions come from.

• New specialisations could grow into proper roles: evaluating AI systems, building agent infrastructure, AI security (prompt injection is a real attack surface once an agent can run commands), and governance around what agents are allowed to do.

• The work that's easiest to delegate may keep shrinking as a share of a human's job: boilerplate, CRUD endpoints, test scaffolding, dependency upgrades, migrations that follow a clear pattern.

What seems hardest to automate is the stuff that needs context, judgment, communication and accountability. Deciding what to build. Pushing back on a requirement that doesn't make sense. Explaining a trade-off to someone who doesn't care about the technology but does care about the outcome. Being the person who gets the call when it breaks.

Systems are getting easier to build and no easier to understand. (Photo: Unsplash)

I'm not going to say any specific job will disappear. I've watched predictions about this industry age badly, and the honest answer is that nobody knows. What I'm fairly sure of is that "software engineer" will mean something different in five years than it did when I started, the same way it already means something different today.

What Should Software Engineers Learn Now?

The default advice is "learn AI". I don't think that's wrong, but I think it misses the point. Learning to use the tools takes a few weeks. What makes you good with them takes years.

If AI makes producing code cheaper, the value moves to everything around the code. These are the areas I think become more valuable, not less:

• Problem solving. Agents are good at solving the problem you describe. Making sure it's the right problem is still on you.

• System design. An agent can implement a design. Whether that design survives contact with real traffic, real data and real teammates is a different question.

• Databases. Indexes, query plans, transactions, data modelling. Bad data decisions are the hardest kind to undo.

• Networking and cloud infrastructure. The most valuable fix in my blog example was understanding that data crossing continents costs time. That's networking, not syntax.

• Distributed systems. Retries, timeouts, idempotency, consistency. Agents write code that works on the happy path very convincingly.

• Debugging. When the agent is stuck, or confidently going in circles, someone has to actually understand what's happening.

• Security. Generated code can be secure. It can also give a function far more permissions than it needs, and do it very neatly.

• Communication and understanding the business. The context an agent is missing usually lives in people's heads, not in the repository.

• Reviewing and validating AI output. Reading a diff critically is a skill. So is designing a test that would actually catch the mistake you're worried about.

• Knowing when not to trust the AI. This may be the most important one, and it only comes from understanding the fundamentals well enough to notice when something is off.

The pattern is simple. AI may reduce the value of manually producing code, while it increases the value of understanding systems. The C textbook, the Node.js debugging sessions and the afternoons lost to a single bug don't feel wasted to me. They're where my ability to judge an agent's work came from.

I Don't Think Software Engineering Is Going Away

When I look at the last few years together, the speed of the change still surprises me.

• 2021: an intern, with C fundamentals from a textbook, learning Node.js and living in Stack Overflow tabs.

• 2022 onward: ChatGPT next to my editor, answering questions, while I still wrote all the code.

• Then: a stretch of refusing to let AI write my implementations, because I believed owning code meant typing it.

• Then: agents that could read my whole repository, make changes across it, and run its tests.

• Now: a lot of my work is deciding what should be built, explaining it well, and checking that what came back is actually right.

That's not a long career. It's a few years. Some people have spent their entire working lives with one stable idea of what programming is. I've had several ideas of it in the time it took to stop feeling like a junior.

I don't think this ends with software engineering going away. The parts that were always the real job are still here: understanding problems, making decisions, and being responsible for the result. If anything, there's more of that work now, because the implementation keeps getting cheaper and faster.

When I started, I was trying to get better at writing code. These days I spend more time thinking about how to get an AI system to produce the right software, and how to tell when it hasn't. I don't know exactly what this job will look like in five years.

What I keep wondering is this: if the next generation of engineers spends far less time writing code than I did, where will their judgment come from, and will it turn out to be better than ours?