AI is not going anywhere in our working lives. As many areas as AI touches, that is how many ways there are to use it sensibly and effectively. So what I share here is neither right, nor is it an attempt — as is the custom on LinkedIn these days — to put myself on stage and show off which AI buzzwords I happen to know. My logs are therefore deliberately kept at surface level, without a technical deep dive.

These logs are simply a snapshot. They document a past approach, specific to my own work, for dealing with the ever-accelerating development of AI in software engineering and integrating it into my working day as an actually performant tool.

What I hope for is an exchange: the chance to hear about other approaches, and to learn from one another. Learning and staying current has never been as relevant as it is now.

The outdated approach: a specialised multi-agent pipeline

Over the past months I experimented a lot, like everyone else. In larger projects, growing complexity and the resulting loss of context became the core problem: models hallucinated, wrote syntactically valid but functionally wrong tests for faulty code, produced poor software architecture — all while telling us, for the umpteenth time, that they had now grasped the full picture.

To counter that, I built a structured orchestration pipeline of specialised agents: a complete dev team of agents with firmly assigned roles, working semi-autonomously on real tasks. Its modules break down roughly as follows.

Triage and data cleaning

Jira tickets were connected and read through MCP (Model Context Protocol) interfaces. An upstream triage agent analysed and cleaned the raw data — filtering out irrelevant comments, formatting debris and historical baggage — and assessed complexity, rough target areas, dependencies and the domains affected (frontend, backend, security).

I always compare this agent to the reception desk in an emergency room: the patient arrives with a bleeding, broken leg, reception filters and documents the problems and sends them to the department that fits.

Model routing in a DAG pipeline

The workflow was modelled as a directed acyclic graph, effectively a state machine. Depending on the sub-task — specification, test authoring, implementation — and its complexity, dynamic routing assigned the appropriate LLM: leaner, faster models for standard work, flagship models only where deep reasoning was genuinely required.

My experience is that hardly any task truly needs the most expensive flagship models, provided the groundwork has been done.

Specification-driven test development

A specialised test agent derived concrete test suites from the acceptance criteria. The downstream developer agent received both those tests and the cleaned functional requirements — to prevent pure overfitting to isolated assertions and to ensure that the domain logic was satisfied, not merely the test suite.

Automated feedback loops before review

Before any code reached a human, the output went through an automated checking loop: static type analysis, linters, test runs. Error messages went straight back to the developer agent for self-correction. That way the human in the loop did not have to act as a debugger for syntax errors and could concentrate purely on architectural and functional code review.

Why I scrapped it anyway

At first glance this sounds genuinely good, and it was in fact alarming how well and how reliably the system worked. But as token costs rose and experience accumulated, the problems grew with them.

The core problem only became truly visible once token costs climbed: exploding token overhead and context drift. Every handover between agents required serialising and passing along the previous system state. Endless markdown protocols, uncompressed terminal output (yarn test, stack traces, compiler logs) and redundant file snapshots inflated the context window exponentially. Important earlier instructions were effectively lost to context drift — and the cost per actual delivered change rose at the same rate.

A second issue was cascading latency. A workflow of four to six sequential agent steps quickly adds up to several minutes of waiting per ticket. If a detail was missing at an early stage, the error propagated through the entire chain.

But the decisive point that made me rethink the approach was above all the feeling of building an ever more fragile house of cards out of dependencies, costs and coordination.

The takeaway

The most important lesson of the past months was to try things even more aggressively — and, above all, to discard them just as aggressively. "Trial and error on steroids", because that is exactly what AI enables.

That approach led me to my current one (as of September 2026), which I call control-layer orchestration. At its core it consists of two parts: a deterministic control layer — plain deterministic code that decides when something is allowed to run — and a stochastic data layer that defines interchangeable specialised units through schemas. I will document the new approach in detail in a follow-up article.

Summary

Lots of communication between lots of agents is a wonderful way to reach your goal while simultaneously burning an enormous amount of money.

If you have taken similar architectural detours: write to me, let us talk.