DEV Community: Dominik

AI coding agents in a German company: the layer everyone forgets

Dominik — Thu, 30 Jul 2026 21:42:07 +0000

TL;DR. Bringing AI coding agents into a German operation is not only a technical decision. The moment they meet real systems and real teams, they also meet three things that international AI content almost never mentions: a data processing agreement, the works council, and the question of who owns the generated code. None of this is a footnote. It decides whether your AI project reaches production or stalls in legal review. Here is the layer most vendors forget, and the fast order to clear it.

Why this layer is invisible from outside Germany
Most content about AI coding agents comes from a world where a developer tries a tool and starts shipping. In a German company with a works council, GDPR, and a legal department reading along, the path to production looks different. Not harder, but with stops that nobody skips without regretting it later.

This is not a brake. It is the actual difference between an impressive demo and something your company is allowed to run. And it is exactly the layer that reveals whether a vendor has ever delivered in Germany or is only demonstrating a tool.

The three stops

The data processing agreement: who is processing whose data?
As soon as personal data is processed on your behalf, Article 28 GDPR requires a data processing agreement with the processor (in German, an Auftragsverarbeitungsvertrag, or AVV). With AI coding agents the decisive question is not "are we using AI" but what does the agent actually touch. Does it run over a codebase that contains customer data? Does it send fragments to a third-party model provider? Who in that chain is the controller, and who is the processor?

This is answerable, and it belongs settled before the first access, not after. A clean setup often limits, at the technical level, what data an agent can even see, which makes the data-protection question smaller and the answer simpler.

The works council: codetermination over systems that can monitor
This is the stop most often missed from outside Germany, because many countries have nothing like it. A works council (Betriebsrat) is an elected employee body, and under the Works Constitution Act it has a real codetermination right over introducing technical systems that are capable of monitoring employee behavior or performance. The key word is "capable": what matters is not whether you intend to monitor, but whether the system could.

An agentic development system that logs who triggered which task, and when, can fall into this category. The instinct to hide or skip past that is the most expensive mistake here: a works council that was bypassed can bring a finished project to a halt. The fast path is the open one. Involve the works council early, and be able to tell them precisely what the system records and what it does not.

This is where it helps to look at the Oversight Ladder, our model of the five autonomy levels of AI coding agents. Where a system sits on that ladder is closely tied to what data about people's work it generates at all. A team that can name its own level clearly can give the works council a clear answer instead of floundering. Clarity about the level is clarity in the codetermination conversation.

Intellectual property: who owns the code?
When an AI generates code, ownership is not answered automatically, and it belongs in the contract. The rule is simple and should be stated explicitly: everything built for you, including AI-generated code, is your property and yours to use without restriction. A vendor who dodges this question, or wants to keep rights to "their" AI output, has just told you the most important thing about the partnership. Settle it up front, and it is never an issue.

The fast order
The whole layer only feels like a brake when you leave it to the end. Put up front, it is done in a few days and never in the way again. A simple order, before the first agent touches anything:

Define data access. What may the agent reach, and what not? That answers half the data-protection question before it is asked.
Settle the data processing agreement. Who processes what, and is the agreement in place? With your data protection people, not after the fact.
Involve the works council. Early, openly, with a clear description of what the system records. Do not ask permission at the end.
Fix IP in the contract. All deliverables are yours. One sentence that saves a lot of trouble later.
Then build. At a deliberately chosen level of the Oversight Ladder, with guardrails that match that level.
This is not bureaucracy for its own sake. It is the order in which an AI project actually reaches production in Germany, instead of dissolving into a loop of follow-up questions.

The question that exposes a vendor
If someone offers to build software for you with AI, ask them a German question: how do you handle the data processing agreement, the works council, and the IP question? A good answer is concrete and sounds like experience: data access is scoped, an agreement is in place or will be provided, the works council is involved early, and all deliverables are yours. A bad answer is a blank look or a "we will sort that out later." The first is a partner who has delivered in Germany. The second is a tool with an invoice.

_(Note: this article informs, it does not replace legal advice. Whether an AVV is required, when codetermination applies, and how to draft the contract all depend on the specific case. Confirm your actual situation with your data protection officer, your works council, and your legal counsel.)

We build production AI software, including inside German companies with a works council and GDPR. This layer is part of the craft for us, not a surprise at the end. If you want to know how it applies to a specific project, that is what a first conversation is for._

AI coding agents in a German company: the layer everyone forgets | DDD

If you bring AI coding agents into a German operation, you meet data-processing agreements, the works council, and codetermination. The compliance and labor layer most vendors ignore, and how to clear it fast.

ddd.consulting

From loops to graphs: how AI agents are growing up

Dominik — Tue, 28 Jul 2026 09:45:09 +0000

TL;DR. A year ago, the exciting way to run an AI agent was a loop: point it at a task and let it repeat until done. The "leave it running overnight" screenshots were everywhere. That era is ending, and what is replacing it is graphs: agents built as structured maps of named steps, with defined paths between them, explicit state, and the ability to branch, recover from a crash, and be watched. This is not a fashion. It is the field growing up, from "run it and hope" to something you can actually run a business on. Here is the shift, the research behind it, and why it matters even if you never write a line of it.

The loop era, and its ceiling

The simplest way to run an agent is a loop. Do a step, feed the result back in, repeat until the work is finished. In its purest form that is the Ralph Wiggum technique that went viral in 2025: a coding agent in a bash loop, running unattended until it produces something. It is genuinely clever, and for the right work it still is.

But a single loop has a low ceiling, and the moment the work gets real you hit it. A loop cannot branch cleanly when a task needs to go two ways at once. It cannot recover gracefully when the machine crashes halfway through a six-hour run, it just starts over. It is hard to observe: from the outside, a loop is an opaque box that is either still going or done, with little to see in between. And it cannot easily route work, sending one kind of subtask one way and another kind elsewhere. For a weekend project none of that matters. For production, all of it does.

Enter graphs

The answer the field has converged on is to stop thinking of an agent as a loop and start thinking of it as a graph: named steps, called nodes, connected by defined paths, called edges, with state passed explicitly between them. The best-known framework for this is LangGraph, where nodes are functions, edges are the control flow, and the state is something you can see and checkpoint. There are others, but the pattern is the point.

A graph fixes exactly what the loop could not. It can branch and merge, because that is what edges are for. It can retry a single failed step instead of restarting the whole run. And because every step and every transition is named, you can watch it happen, log it, and pause it at a specific point. The opaque box becomes a map.

Sitting underneath this is a second shift, less visible but just as important: durable execution. Engines like Temporal and Restate wrap each step of a long-running agent so that if the process crashes, it resumes from where it stopped instead of redoing everything, or worse, repeating a step that already charged a customer or sent an email. A loop that runs overnight and dies at hour five loses five hours. A durable graph loses nothing. For anything that touches money or real systems, that difference is the whole game.

The frontier: graphs that build themselves

The bleeding edge goes one step further: can the graph design itself? Instead of an engineer laying out the nodes and edges, can the system search for the best structure automatically, or even generate a bespoke graph for each task?

The research says yes, with an important caveat about the hype. A 2026 survey of the field, From Static Templates to Dynamic Runtime Graphs, maps this whole space and reaches a sober verdict: fully generating a fresh workflow graph at runtime is usually overkill and riskier than it looks. The pragmatic sweet spot is to build one well-validated graph and let a router select the right piece of it per task, which captures most of the benefit while keeping the safety of a structure you already trust.

Where automatic structure search does pay off, the results are striking. AFlow, a system that searches the space of workflow graphs using Monte Carlo Tree Search, beat manually designed workflows by an average of 5.7% and other automated methods by 19.5% across six benchmarks. More tellingly, it found structures that let a smaller, cheaper model reach GPT-4o-level results on a coding benchmark at 4.55% of the cost. The structure of the graph, not just the model inside it, is where a large chunk of the performance and the cost now lives.

Why this matters even if you never build it

Here is the part for anyone paying for AI rather than writing it. This shift is not a framework preference. It is the line between a demo and a system you can depend on.

A loop is fine when nothing is at stake. Graphs and durable execution exist because production has stakes: a run has to survive a crash, be observable while it happens, and recover without repeating what it already did. This is the same maturation we described in our Oversight Ladder and in keeping AI agents trustworthy in production. Loops belong at the unsupervised, low-stakes end. Real business work belongs on structured, recoverable rails where a person and a system can both see what is happening.

So the useful question for a vendor is not "do you use the latest framework." It is simpler: what happens when a run fails halfway through? If the honest answer is "it starts over" or "we would not know," you are looking at loop-era engineering pointed at a production problem. If the answer describes a structure that recovers a single step, keeps its state, and can be watched, you are looking at someone who has made the jump from loops to graphs. That jump is quietly becoming the difference between AI that demos well and AI that runs your business.

We build production AI on structured, recoverable rails, not overnight loops, because for the work our clients depend on, that is the only honest way to do it. If you want to understand what that means for something you are considering, that is what a first conversation is for.

Frequently asked questions

What does it mean that AI agents are moving from loops to graphs?
A loop is the simplest way to run an agent: repeat a step over and over until it is done, like the Ralph Wiggum technique that went viral in 2025. A graph is a structured version: named steps (nodes) connected by defined paths (edges), with explicit state passed between them, so the agent can branch, merge, retry a single step, and be observed. The field is moving from loops to graphs because loops hit a ceiling once the work gets real: they cannot branch cleanly, recover from a crash mid-run, or be watched closely. Graphs can.

What is LangGraph?
LangGraph is one of the best-known frameworks for building agents as graphs. Nodes are functions or steps, edges define the control flow, and state is passed explicitly between nodes. It is representative of the broader shift: instead of one opaque loop, you get a structured graph you can inspect, checkpoint, and resume.

Can AI agents build their own workflow graphs?
At the research frontier, yes, but be careful with the hype. A 2026 survey of the field (From Static Templates to Dynamic Runtime Graphs) finds that fully generating a workflow graph at runtime is usually overkill and riskier than it sounds. The pragmatic approach that captures most of the benefit is to build one well-validated graph and let a router select the right subgraph per task, not generate a new one from scratch each time.

Why does this matter if I am buying AI, not building it?
Because it is the difference between a fragile demo and a system you can run your business on. Loops are fine for a weekend project. Production work needs to survive a crash, be observed, and recover, which is exactly what graphs and durable execution provide. If a vendor is still running everything in an unattended overnight loop, they are building demos. Ask what happens when a run fails halfway through.

The Oversight Ladder: the five levels of AI coding autonomy

Dominik — Sat, 25 Jul 2026 19:28:06 +0000

Originally published on ddd.consulting.

TL;DR. "AI coding agent" describes five very different things, separated by one question: how much human oversight sits between the agent and your production system. We call it the Oversight Ladder, and it runs from Level 1 (the agent suggests, a person writes every line) to Level 5 (the agent runs unattended overnight). Higher is not better. It is less supervised. Most AI projects that fail do not fail because the technology cannot do the work. They fail because someone ran it a level or two higher than the work could safely take, without the guardrails that level needed. Here is the ladder, and how to place your own work on it.

Why "AI agent" is a useless word on its own

When a vendor says they build with AI agents, they have told you almost nothing. The same phrase covers a developer using autocomplete and a system that writes and ships code to production overnight with no one watching. Those are not variations on a theme. They are different risk profiles, different failure modes, and different price tags, sold under one word.

This vagueness is not harmless. It is why so much money is being wasted. Gartner forecasts that more than 40% of agentic AI projects will be cancelled by the end of 2027, and the reasons it gives are escalating costs, unclear business value, and inadequate risk controls. Those are not technology problems. They are the symptoms of running at the wrong level of autonomy. Meanwhile Deloitte's 2026 survey found that only about 21% of organisations have mature governance for agentic AI, which means roughly four in five are deploying autonomy they cannot yet control.

The fix is not to fear the technology or to chase the highest level. It is to know exactly which level a given piece of work belongs at, and to insist on the controls that level requires. That needs a shared language. The self-driving car industry solved the same problem years ago with its levels of driving automation, and everyone now knows what "Level 5 autonomous" means. Software needs the same clarity.

The Oversight Ladder

Five levels, separated by how much a human sees and stops before code reaches production.

Level	Name	Who does what	Right for
1	Assist	The agent autocompletes. A person writes and owns every line.	Anything. This is just a faster keyboard.
2	Review	The agent produces whole changes. A person reviews every one before it ships.	High-stakes work: money, security, customer data.
3	Checkpoint	The agent produces and tests changes. Automated gates plus a person block anything that fails.	Most real product work at pace.
4	Orchestrate	Several agents work in parallel under a senior person who directs and reviews. Agents cannot merge their own work.	Building a lot, fast, without losing control.
5	Autonomous	Agents run unattended, for example overnight. A person reviews the batch afterward.	Exploration and throwaway work, not production a business depends on.

Read the ladder as a dial, not a scoreboard. Level 5 is not the destination. It is the setting with the least human oversight, which makes it the right choice for a narrow set of low-stakes work and the wrong choice for almost everything a business actually runs on.

The internet is full of Level 5 stories. "I let it run overnight and woke up to a thousand commits" is a genre now. It is a fun demo. It is also the level where an unsupervised mistake goes straight to production, and for anything with a customer or a euro attached, that is not a story you want to star in.

What actually holds each level in place

Here is the part most content skips, because you can only write it if you have run these systems for real. The higher you climb the ladder, the more the controls have to be mechanical rather than polite.

At Levels 1 and 2, the control is obvious: a human reads everything. Simple and slow, and correct for the highest-stakes work.

At Levels 3 and 4, you are moving faster than a human can read every line, so the guardrails have to be built in. Two we learned the hard way, running agents on our own platform every day:

You cannot ask an agent to stay in its lane. You have to remove the lane. We ran parallel agent teams where a lead agent was instructed, in plain language, to delegate work rather than write it. Under load, it kept writing anyway, across several runs. Instructions did not hold. What held was mechanical: we stripped the lead's ability to edit files at all, so its only possible first move was to delegate. A control that depends on the agent choosing to obey is not a control. It is a hope.

Review has to catch what speed misses, and it will find plenty. On one of our own build runs, an agent team shipped seventeen changes with its own automated review passing. When a human reviewed afterward, sixteen issues surfaced, seven of them serious: a payment webhook that could process the same event twice, a permissions check that was quietly bypassed, an off-by-one error copied identically across three places, and development passwords that would have worked in production. None of this means the agents were bad. It means that at speed, the review layer is not optional, it is the product. We keep the exact catalogue of what slipped through, because a vendor who cannot tell you how their agents fail has probably not looked.

This is why Level 4 done properly is not more dangerous than Level 2. It is faster at the same safety, because the guardrails are structural. And it is why Level 5, for real production work, is a marketing position rather than an engineering one.

Placing your own work on the ladder

You do not need to know how any of this is built to make the call. You need to know the stakes. Three questions place almost any piece of work:

If this went wrong silently, what breaks? A customer charged twice, data exposed, a compliance breach: that work belongs at Level 2 or 3, no exceptions. An internal draft nobody depends on: Level 4 or 5 is fine.
Can a person still see what shipped? Autonomy is only safe when someone reviews the output, even in a batch. If the honest answer is that nobody is looking, you are not at Level 5, you are unsupervised, which is a different and worse thing.
What stops a mistake before a customer sees it? If the answer is a person, you are at Level 2. If it is a person plus automated gates, Level 3. If it is "the agent is usually right," you have no answer, and no level.

Most businesses, most of the time, want their real work built at Level 3 or 4: fast, but with automated gates and a senior human who can stop anything. That combination is where speed and safety stop trading against each other. Trust in fully autonomous agents actually fell over the last year, from 43% to 27% in Capgemini's research, and that is not pessimism. It is the market learning where the dial belongs.

The one question that cuts through the pitch

When someone offers to build software for you with AI, you do not need to interrogate their architecture. Ask one thing: at what level do you operate, and what mechanically stops the agent below full autonomy?

A good answer sounds like: "Mostly Level 3 and 4. Agents cannot merge their own work, a failing test blocks anything, and a senior engineer reviews the output." A bad answer waves at how advanced the AI is and how rarely it makes mistakes. The first describes a system. The second describes a hope, and you would be paying for the hope.

We build production software with agent teams every day, mostly at Levels 3 and 4, with the guardrails this article describes. If you want your own roadmap placed on this ladder honestly, that is what a first conversation is for. The original version of this post lives at ddd.consulting.

Frequently asked questions

What are the levels of AI coding autonomy?

We use five, borrowing the idea from self-driving cars. Level 1 (Assist): the agent autocompletes, a person writes and owns every line. Level 2 (Review): the agent makes whole changes, a person reviews each before it ships. Level 3 (Checkpoint): the agent makes and tests changes, automated gates plus a person block anything that fails. Level 4 (Orchestrate): several agents work in parallel under a senior person, and they cannot merge their own work. Level 5 (Autonomous): agents run unattended and a person reviews the batch afterward.

Is a higher level of autonomy better?

No. Higher means less human oversight, not better work. The right level depends on the stakes. Anything touching money, security, or customer data belongs at Level 2 to 4 with real guardrails. Throwaway exploration can run at Level 5. Treating Level 5 as the goal is how expensive mistakes reach production.

What is the single most useful question to ask an AI development vendor?

At what level do you operate, and what actually stops the agent below full autonomy? If the answer is that they ask the agent to behave, that is not a control. A real control is mechanical: the agent structurally cannot merge its own work, and a failing test blocks it. Ask what happens when the agent gets it wrong, because it will.

Why do so many agentic AI projects get cancelled?

Gartner forecasts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. In our reading, most of that is running at the wrong level of autonomy without the guardrails that level needs.