DEV Community: Nenad

What Happens When AI Agents Stop Working Alone?

Nenad — Mon, 07 Sep 2026 19:18:31 +0000

Something interesting is happening in AI-assisted software development.

We are getting very good at giving an AI agent a repository and a problem and letting it figure things out. The agent can explore the codebase, understand dependencies, make changes, run tests, interpret failures and continue working until it reaches a result.

That is already changing the role of the developer.

But there is another change happening underneath it that I find even more interesting.

We are beginning to realize that the most capable model does not necessarily need to do all of the work.

A recent approach to AI-assisted development illustrates this well: use a powerful frontier model to understand the problem and create the implementation plan, then let a smaller or local coding model carry out the implementation.

At first, this sounds like a way of reducing inference costs.

It is.

But I think it reveals something much more fundamental about where agentic AI is going.

The problem with asking one agent to do everything

When an AI coding agent receives a request such as “add customer notifications,” it isn't really being asked to write some code.

Before it can write anything meaningful, it has to understand the system around that code.

It needs to discover where customers are represented, how changes are propagated, which messaging infrastructure already exists, where the relevant business logic lives, what persistence mechanisms are being used and what conventions the existing application follows.

Then it has to make decisions.

Should the notification be synchronous or asynchronous? Should it be a new service or part of an existing domain? What happens if delivery fails? How should duplicate events be handled? Which existing abstractions should be reused?

Only after all of that does implementation become relatively straightforward.

This is an important distinction because those activities require very different kinds of capability.

Understanding an unfamiliar architecture is a reasoning problem.

Creating another repository class after the architecture has already been established is mostly an execution problem.

Yet when we use a single autonomous agent, we ask the same model to perform both.

That isn't necessarily wrong. Frontier models are increasingly capable of doing it.

But it is not necessarily the most efficient architecture either.

A plan changes the problem

Imagine that the first agent has already explored the repository and produced a detailed implementation plan.

It has identified the existing customer domain, the event infrastructure and the transaction boundaries. It has decided that the notification capability belongs in an existing bounded context. It has specified which components need to change, which interfaces should remain untouched and what the tests need to prove.

The second agent now receives that plan.

Its job is no longer to figure out what the system should become.

Its job is to make the system become it.

That is a much smaller problem.

And this is where local models become particularly interesting.

A smaller model may struggle when asked to independently understand a large, unfamiliar architecture. But once the problem has been decomposed and the constraints are explicit, the same model may be perfectly capable of implementing the individual changes.

The quality of the overall result no longer depends entirely on the intelligence of the implementation model.

It depends on the quality of the reasoning that happened before implementation.

That gives the plan a new role.

It is no longer just documentation.

It becomes the contract between two different forms of intelligence.

This is how engineering organizations already work

There is nothing particularly new about separating reasoning from execution.

We do it in human engineering teams all the time.

An architect doesn't normally implement every line of a system. A technical lead doesn't personally write every test. A developer doesn't make every architectural decision from scratch for every task.

The organization divides the problem.

People specialize.

Information moves between those specialists in the form of artifacts: architecture decisions, specifications, designs, acceptance criteria, test plans and tickets.

AI agents are beginning to create the same possibility in software.

The difference is that an AI system can potentially make those decisions dynamically.

A task can be analyzed, decomposed and assigned to different agents depending on what is actually required.

A complex architectural decision might go to a frontier reasoning model.

A well-defined coding task might go to a local model.

A database migration might be handled by a deterministic tool.

A security-sensitive change might require another model to review the result.

The interesting part isn't that we have several models.

The interesting part is that something has to coordinate them.

The agent becomes a component

This changes the way I think about AI agents.

We have spent a lot of time treating an agent as if it were an employee: give it a goal, give it tools, and let it get the job done.

That works surprisingly well for small problems.

But as the problems become larger, the agent itself starts looking less like an employee and more like a component in a distributed system.

A business objective becomes a workflow.

The workflow is decomposed into tasks.

Tasks acquire context.

Context is passed to agents.

Agents use models and tools.

Results are validated.

Failures create new tasks or trigger replanning.

The system maintains state throughout the process.

Once you look at AI this way, model selection becomes only one part of the problem.

The bigger challenge is coordinating the entire execution.

And this matters much more in an enterprise

This distinction becomes unavoidable when AI moves into large organizations.

An autonomous agent operating against a developer's personal repository is one thing.

An agent operating against a bank's production environment is something entirely different.

The organization needs to know what the agent is allowed to see and what it is allowed to do. It needs to control which tools are available, where sensitive information can be processed and which actions require human approval.

It needs to understand what happened when something goes wrong.
It needs an audit trail.
It needs policies.
It needs observability.

And it needs the freedom to change the underlying AI models without rebuilding the entire automation layer.

These requirements have little to do with whether Claude, GPT, Llama or another model is currently the best model.

They are properties of the system surrounding the models.

That system is the orchestration layer.

Local AI makes the architecture more interesting

The rapid improvement of local models adds another dimension.

A company can potentially keep its source code and sensitive data inside its own environment while using local models for implementation and routine execution.

At the same time, it can use a much stronger model for problems where deeper reasoning is worth the additional cost or where local models are not yet capable enough.

There is no reason these have to be competing architectures.

They can be different workers in the same workflow.

That means the decision is no longer simply “cloud AI or local AI.”

It becomes a routing decision.

Where does this particular task belong?

Which model has the capability required to solve it?

What information does it need?

What is the cost of using it?

How sensitive is the information?

How much autonomy should it have?

Those decisions can themselves become part of the orchestration.

And once that happens, the AI system starts to behave less like a chatbot and more like an operating environment for intelligent work.

This is where Archy fits

This is also the thinking behind Archy.

We started from a very practical problem: how do you make AI agents useful when the work itself is complex, interconnected and continuously changing?

It is tempting to solve that by building a better agent.

We believe the more interesting problem is building the environment in which agents work.

Archy provides that environment.

A goal can be turned into a structured workflow. The workflow can be broken into tasks and dependencies. Agents can be assigned to those tasks. Different models and tools can be used where they make the most sense. Context can be provided at the point where it is needed rather than indiscriminately passed to every agent. Execution can be observed and validated, and the workflow can react when reality differs from the original plan.

That is why Jira is a use case for Archy rather than its definition.

A Jira backlog happens to be a very useful representation of work. It contains objectives, dependencies, priorities and acceptance criteria, making it a natural environment for demonstrating agentic orchestration.

But the same underlying architecture can be applied to much more than software delivery.

An enterprise migration.
A regulatory change.
A customer onboarding process.
A technology modernization program.
A complex operational procedure.

In each case, the problem is essentially the same: take an objective, understand what needs to happen, coordinate the necessary intelligence and tools, and bring the work to a controlled outcome.

The model shouldn't be the architecture

This is probably the most important conclusion I take from the recent experiments with frontier models and local coding models.

We are entering a period where models will change incredibly quickly.

Today's best reasoning model will eventually be replaced. Today's impressive local coding model will become ordinary. New specialized models will appear for tasks we haven't even considered yet.

If the architecture of an AI system is built around one particular model, every improvement in the model landscape becomes an architectural disruption.

If the architecture is built around goals, workflows, tasks, capabilities, context and policies, the models become replaceable components.

That is a much more sustainable way to build enterprise AI.

The question stops being which model should run the whole process.

Instead, the system can decide which intelligence is appropriate for each part of the process.

A frontier model can reason about the architecture.
A local model can implement it.
A deterministic tool can execute a migration.
Another agent can test the result.
A human can approve the decision that matters.
And the orchestration layer keeps the whole thing coherent.

From agents to systems

I think this is the transition we are beginning to see.

The first generation of AI applications was largely about putting a model behind an interface.

The next generation is about giving models tools.

The next step is more consequential: coordinating multiple agents, models and tools around an outcome.

That requires state.
It requires context.
It requires planning.
It requires routing.
It requires governance.

And it requires a way to recover when the plan meets reality.

In other words, it requires architecture.

The exciting part isn't that we can now make an AI agent write code using another AI model.

The exciting part is that we are beginning to build systems in which different forms of intelligence can work together.

That is a much bigger opportunity.

The future of AI may not belong to the single smartest agent.

It may belong to the platform that knows which intelligence to use, when to use it, and how to make all of it work together.

That is the problem Archy is being built to solve.

AI Doesn’t Replace Agile. It Makes Good Agile More Important.

Nenad — Sat, 11 Jul 2026 21:02:58 +0000

AI Doesn’t Replace Agile. It Makes Good Agile More Important.

The discussion around AI replacing Agile is becoming increasingly common. The argument usually goes something like this:

Information is now instantly accessible.
Code can be generated in hours instead of weeks.
Documentation is no longer expensive to produce.
Communication overhead is dramatically reduced.

If all of that is true, do we still need Agile?

I believe the answer is yes—but perhaps not in the way we practice it today.

The mistake is assuming Agile is defined by stand-ups, sprint planning, retrospectives, or two-week iterations. Those are practices, not principles.

The real purpose of Agile has always been much simpler:

Deliver customer value incrementally while maintaining enough structure to ensure quality, accountability, and continuous learning.

That objective hasn’t disappeared because AI became faster.

AI Changes Execution, Not Responsibility

Large language models can generate code, documentation, tests, infrastructure, and even architecture proposals.

What they don’t generate is accountability.

In enterprise environments—especially regulated industries—the question is rarely “Who wrote this code?”

The real questions are:

Who owns this decision?
Why was this solution selected?
Can we trace how we arrived here?
Can we audit the process?
Who is responsible when something fails?

Without clear ownership and controlled handoffs, AI can produce enormous amounts of output that become increasingly difficult to understand, validate, or maintain.

Speed without governance simply creates technical debt faster.

Coordination Isn’t Going Away

Many people assume AI eliminates the need for coordination.

I would argue the opposite.

As AI agents begin collaborating with humans—and eventually with other AI agents—the need for explicit coordination actually increases.

Someone still needs to define:

objectives,
responsibilities,
interfaces,
quality gates,
acceptance criteria,
governance,
and success metrics.

Those aren’t limitations of Agile.

They’re requirements of building reliable systems.

Whether the work is performed by developers, AI coding agents, or autonomous software engineering teams, coordination remains essential.

What Will Change?

Quite a lot.

Planning cycles will become shorter.

Ceremonies will become lighter.

Backlog refinement may become largely automated.

Documentation may be generated continuously.

Testing, reviews, and implementation will increasingly happen in parallel.

Entire development loops that previously required weeks may compress into hours.

But shortening the cycle is not the same as eliminating the cycle.

There is still a need to validate assumptions, integrate work, gather customer feedback, measure outcomes, and decide what happens next.

That’s iterative delivery.

That’s Agile.

Towards Agentic Agile

Rather than abandoning Agile, I think we’re moving toward something new—what I would call Agentic Agile.

A delivery model where humans define intent, priorities, architecture, governance, and business outcomes, while AI agents execute much of the implementation work autonomously.

The ceremonies may evolve.

The artifacts may evolve.

Even team structures may evolve.

But the underlying principles remain remarkably resilient:

Deliver customer value continuously.
Reduce risk through iteration.
Maintain transparency and ownership.
Ensure traceability and accountability.
Learn and adapt quickly.

Those principles are arguably more important in an AI-first world than they were before.

The Real Shift

AI doesn’t eliminate Agile.

It removes much of the friction that Agile was originally designed to manage.

What remains is the essence: coordinating people, agents, decisions, and accountability to consistently deliver customer value.

The future may indeed have fewer meetings, fewer manual handoffs, and dramatically faster delivery cycles.

But it won’t have less responsibility.

If anything, as autonomous AI systems become more capable, the importance of governance, ownership, and iterative value delivery will only increase.

The future isn’t post-Agile.

It’s AI-native Agile—where speed is amplified by AI, but trust is still earned through discipline.