Agent-Orchestrated Development: the next software development model

Over the last two years, hundreds of articles have appeared about how Artificial Intelligence is changing software development. Most revolve around a familiar idea: the developer uses an AI tool to write code faster, generate documentation, or accelerate repetitive tasks. It is a reality that is already part of the daily routine for many teams.

But after several months of incorporating AI tools into real projects, at Suris we believe something more interesting is beginning to happen. The conversation has shifted from focusing solely on intelligent assistants and has begun to revolve around how we coordinate multiple capabilities working at the same time.

This is a first-hand reflection on what we are observing in real projects, and on the questions we still cannot answer. Do not expect an implementation guide or a rigid framework: the field is too new for that. And we are not the only ones who see it. A recent analysis by Forrester on agentic software development in 2026 describes this very transition and points to it as the turning point of the year.

The model we already know: AI-assisted development

The first stage of adoption was simple. A developer incorporated AI tools into their usual workflow. The dynamic remained familiar. What is starting to appear now is a second stage, where the unit of work ceases to be one person with a tool and becomes one person coordinating several.

Stage 1 · Already familiar — AI-assisted development

• One person, one task, one interaction

• AI as the developer's assistant

• Code generation and documentation

• Accelerated testing and technical analysis

• The professional remains at the center of the process

Stage 2 · Emerging — Agent-Orchestrated Development

• One person coordinates multiple agents

• Parallel, non-sequential processes

• Multiple simultaneous workflows

• Coordination determines quality

• Responsibility remains human

For many teams, the first stage is still a huge opportunity for improvement. There is no need to rush to leap to the next one if the foundation is not consolidated. But it is worth understanding where the field is moving to make better decisions today.

What we are starting to observe

In some projects, we no longer see just a developer interacting with a tool. We see multiple processes occurring in parallel. The person makes an architectural decision while different capabilities work simultaneously: one researches alternatives, another generates tests, another reviews code, another documents changes, another compiles information.

Work stops being completely sequential and begins to look like an orchestration. The central question changes.

It is no longer "how does this tool help me?". It becomes "how do I coordinate multiple capabilities to better solve this problem?". This shift in the question is, in itself, a sign that something structural is changing.

— Ezequiel Sansón, Chief AI Officer · Suris Code

Agent-Orchestrated Development: what it means

There is still no universal definition for this concept, and that is partly what makes it interesting to explore. In simple terms, it is a model where one person coordinates specialized capabilities that collaborate in different stages of the development cycle.

Forrester describes this moment as the transition from TuringBots (AI assistants integrated into individual tools) to agents that collaborate throughout the entire development lifecycle. Instead of asking a tool to generate code, teams delegate an intent ("build this feature") while agents break down the work, generate artifacts, run tests, and prepare releases. People remain responsible. What changes is how much of the execution can be distributed.

Three things do not change in this model, and it is worth stating clearly:

• Responsibility remains human. The person is answerable for the result, not the automated process.

• Decisions remain human. Architecture, technical criteria, judgment on what to build and what not to: all of this requires experience and context that no agent possesses.

• Business understanding remains human. An agent can generate correct code for a misunderstood requirement. The person is the one who knows if the requirement is properly framed.

What changes is the scale of the work that can be executed simultaneously. For years, we valued professionals capable of participating in multiple projects at once. Today, another equally valuable capability is starting to emerge: managing multiple parallel workflows within the same project.

The new unit of measure: from "lines of code per hour" to "workflows coordinated per person"

Productivity in an orchestration environment is not measured the same way as in an assistance environment. Someone who manages five parallel processes well can produce in one day what previously took much longer. The "code per hour" metric no longer captures that, and this gap between what we measure and what generates value is one of the most urgent problems we have to solve.

What changes for teams and talent

When multiple processes are working simultaneously, the most valuable skills begin to shift. Some technical capabilities remain important; others quickly take center stage.

Relatively lose prominence: speed of writing code, memorizing APIs and syntax, boilerplate generation, searching and synthesizing documentation, repetitive manual testing.

Gain prominence: formulating better questions and prompts, validating results and detecting inconsistencies, deciding with abundant information, prioritizing and maintaining context, managing complexity and coordinating workflows, communicating technical decisions clearly.

This shift has direct implications on how we train professionals and how we evaluate talent. The difference between two developers with access to the same tools is rarely in the tool. It is in how they use it: in the quality of the questions they ask, in how fast they detect that an output is wrong, and in whether they can maintain coherence in a distributed process.

What this changes in how we hire at Suris

In selecting technical talent, we use AI-assisted analysis for initial screening. But what we care most about evaluating in interviews is no longer just accumulated technical knowledge. We care about curiosity, learning capacity, adaptation to change, and, increasingly, the ability to manage context and coordinate multiple tasks with judgment.

Technical knowledge matters, just as always. The thing is, when tools amplify execution, what differentiates the best professionals is precisely what the tool cannot do for them.

The adaptation process: where the new focuses lie

None of this happens overnight. The most interesting part of these months was realizing that the focus of the work shifted, rather than just the speed we gained. Coordinating several agents at once is akin to leading a team, and that requires paying attention to different things than programming alone did.

Three new focuses we have been discovering in real projects.

From writing to coordinating. A good developer writing code is not automatically good at coordinating five processes in parallel. It is another skill: distributing work, holding the context of each flow, deciding what to look at first. It is a learning curve, and it is worth naming instead of assuming it is learned on its own.

The review became the center of attention. When multiple agents finish almost at the same time, the quality of the result is decided in the review. Generation has become fast; reviewing well still requires human judgment, and that is where we learned we need to put time and thought. If one focuses only on producing and neglects the review, the result suffers.

Maintaining the coherence of the whole. With work distributed across multiple flows, each part may be correct but the whole might not fit together. Keeping an eye on the big picture while building in parallel is a focus that sequential work previously resolved almost on its own.

What we have been adjusting

None of these focuses has a settled formula yet. What we have are adjustments we made as we understood better where to look:

• How many flows a person orchestrates at once is measured by what that person can review well.

• Review was included in the planning, with its own allocated time. It stopped being the step done in a rush at the end.

• We staggered the output of the agents so they do not all land at once, and we added a first review between agents before a human looks at it.

• We treat orchestration as a skill to be trained, just as we trained prompt engineering in its time.

• When the foundation is not solid, we stick to sequential work. Not every project benefits from orchestration, and forcing it too early adds noise.

We share this because this part, the learning part, is what almost no one publishes. And because the way to move forward in something new is to discover where to put the focus as you go along.

The questions that still have no answer

We are in a very early stage. It would be dishonest to present this as a settled framework when most relevant questions remain open. Some we are addressing with the adjustments mentioned above. Others we still do not know how to answer, and those are the ones that occupy us the most:

• How is productivity measured when part of the work is executed by parallel automated processes?

• Which traditional metrics no longer make sense and what do we replace them with?

• How does the role of the senior developer change when execution is distributed?

• What skills should professionals who are just starting their careers develop in this context?

• How do we govern an environment where the surface of automated decisions grows all the time?

None has a definitive answer yet, and I distrust anyone who says they do. What we have are hypotheses that we are testing in real projects. When we have more solid data, we will share them.

Our vision

At Suris, we think of AI as one more tool in a familiar historical line: the compiler, the framework, the cloud, and now agents executing in parallel. Each expanded what a person could do. None replaced the judgment of the user.

What changes now is the scale. For the first time, we work in environments where multiple capabilities can act in parallel on the same problem. The developer does not lose importance; the type of work they do changes.

Understanding how to design, coordinate, and govern those environments is going to be one of the most interesting challenges of the coming years. We do not have all the answers. But we do have the conviction that it is worth asking the right questions now, while the field is still being defined.

This conversation is just beginning. And the companies that participate in it, rather than waiting for others to solve it, will be better positioned for what is to come.