From Manual Coding to Agent Orchestration: How the Programmer's Role Is Being Redefined

Software development has gone through several fundamental transformations over the years. What began as manual code writing is, it seems, evolving toward the orchestration of intelligent systems. The programmer's role has been redefined again and again, with consequences for the industry and the economy. We find ourselves at such a moment once more, so we decided to experiment with agent orchestration. But before sharing observations about where and when orchestration can bring value, let's look briefly at the historical context.

Pencil sketch: on the left, a developer writing code at a desk (traditional development); an arrow labelled "becoming agent orchestrator" leads to the right, where the same developer coordinates several agents under an agent orchestration coordinator

From simple editors to intelligent IDEs

Programming has evolved through successive layers of abstraction. IDEs shifted part of the cognitive load through real-time validation and automated refactoring. Frameworks changed the paradigm toward composition-as-product: building quickly through configuration rather than implementing from scratch. Package managers turned development into a supply-chain model, where code becomes modular and reusable.

Each layer democratized access: what once required senior developers became within reach of intermediate practitioners. Yet all of these tools remain passive assistants. The programmer kept full cognitive ownership: the IDE suggested, but the programmer decided and wrote.

Timeline of seven stages: manual coding, smart IDEs, frameworks, package managers, the first wave of AI, co-creation, and agent orchestration, with the developer role shifting from writing all the code to designing orchestration and overseeing execution: from executor to orchestrator

The first AI wave: a conversation with knowledge

ChatGPT democratized natural language as a way to query technical knowledge. Instead of Stack Overflow and keyword search, programmers describe their problems and receive tailored explanations. Studies have shown a 30–50% reduction in time spent on routine problems. Juniors gained access to senior-level explanations, flattening the learning curve.

Still, the workflow remained manual: programmers copied, adapted, tested, and integrated. AI played the role of a more advanced search engine, not a development partner.

Co-creation: real-time collaboration

GitHub Copilot marked the leap from Q&A to real-time co-authoring. Unlike ChatGPT, where the user received answers and copied them over by hand, Copilot generates code directly in the editor, inline, while you work. Initially, the model generated complete implementations from comments: the programmer reviewed the proposals, then accepted or modified them. Development becomes a conversation. The bottleneck shifts from typing speed to the clarity of intent and the quality of the review.

The evolution continued rapidly. The chat feature allowed contextual questions and explanations. Then more complex capabilities appeared:

Adding context by selecting code and including multiple files;
Custom Markdown instructions that guide behavior for specific projects;
Agent mode and plan mode for autonomous task execution;
MCP integrations for access to external tools.

All of this encouraged a new direction for the programmer's role: orchestrating agent workflows.

Agent orchestration workflows

With orchestration, we can coordinate multiple agents working on the same complex problem. This process requires precise granularization, which in turn demands real technical expertise, pragmatism, and thorough up-front analysis.

Why split the work across multiple sub-agents?

Complex problems often exceed the capabilities of a single LLM, leading to hallucination before the problem is successfully solved. LLM performance is not uniform across the entire available context. The "Lost in the Middle" research documented a specific pattern: models perform best when the relevant information sits at the beginning or the end of the context, and degrade significantly when they have to retrieve information from the middle of a long one.

This degradation is called long-context performance degradation, or "context rot" in colloquial terms.

In practice, during long working sessions an agent may ignore a decision made earlier, repeat an approach that already failed, or lose sight of constraints set at the start. Not necessarily because it forgot the information, but because the attention mechanism does not treat everything in the context uniformly. The problem appears even when the information is technically present.

Splitting the work across sub-agents with shorter, well-delimited contexts reduces the surface of this problem: each sub-agent works within a narrower context, where the relevant information is easier to reach. Orchestration does not eliminate the problem, but redistributes it, introducing new risks that we discuss next.

When can orchestration become a problem?

In theory, it is simple to divide a task into N sub-tasks and let multiple agents do the work. In practice, if the workflow is defined incorrectly, errors propagate easily from one agent to the next. Operating in an environment without determinism, preventing errors is harder; not impossible, but more costly.

If context rot hits one of the agents in the workflow, the entire task may be compromised, or the errors the workflow generates may take longer to fix than doing the work without that complex system would have.

The agent harness

To orchestrate agents reliably, each agent must be built with a clearly defined set of capabilities, limits, and operating context. In practice, this framework is called a harness. The harness is the equipment the agent is given: instructions, tools, agent memory, skills, and so on.

Instructions

The instructions in an agent's harness are essentially a set of rules and directives that define its behavior in a given context. They answer a few essential questions: what role the agent has (developer, architect, tester, etc.), what tools it has at its disposal, what it is and isn't allowed to do, in what order it works, and what the output it produces looks like.

Agent skills

Skills are the modular capabilities an agent can use to solve concrete tasks. Each skill encapsulates specialized logic: for example, "write a unit test", "analyze code complexity", or "generate an architecture diagram". What makes skills useful is that they can be combined into more complex flows, for example: write code → test → refactor.

Agent tools

If skills define what the agent knows how to do, tools are how it actually does it. Concretely, we are talking about running bash commands, reading and writing files, API calls, web search, database access, running tests, and much more. A relevant development in this space is MCP (Model Context Protocol), a standard that lets an agent connect to external services (GitHub, Jira, Figma, etc.) in a uniform way, without needing a custom integration for each service.

Memory

An agent's memory refers to how it retains and accesses information over time. It can be in-context (what has been discussed in the current session), external (vector databases, files, or notes that persist between sessions), or procedural (accumulated patterns about how to approach certain types of problems).

In essence, the harness is the operating framework that turns a generic language model into a specialized, controlled agent, ready to be integrated into a multi-agent workflow. That is why it is essential to set this framework up correctly for each agent individually.

The AI model used

The agent is also shaped by the performance of the LLM behind it. Smaller models are faster and cheaper, but can handle less complex tasks. Larger models perform better, but are more expensive and slower. The selection criterion is to choose what fits the agent's role.

A new role in the market: workflow architect?

When agents are configured correctly and the workflow is granularized properly to avoid context rot, orchestration becomes possible. Building and integrating these agents into a system takes specialized expertise. This is where a new responsibility emerges: identifying the contexts in which a workflow is necessary and feasible and, just as important, those in which it is not, where simpler AI solutions deliver a better return. This responsibility involves aligning the project's goals and business with the implementation cost of a workflow that brings real value. So, in our view, it is possible that in the future there will be such a specialized role on the market: agent workflow architect.

Conclusions

Technical expertise remains essential, but not for boilerplate: for complex decisions and design. Programming is becoming a more strategic discipline, and a more demanding one in terms of systems thinking.

The tools have changed, but the fundamental challenge remains: building software systems that solve real problems, reliably and at scale. This time, though, we solve them by:

Thinking in systems, not syntax;
Developing discernment in evaluating AI output;
Cultivating an intuition for when to delegate and when not to.

References

Originally published in Today Software Magazine, issue 166, co-authored with Joelle Danciu: De la scriere manuală de cod la orchestrare de agenți: cum se redefinește rolul programatorului.