The question "Do you use AI?" no longer tells vendors apart. The answer is yes everywhere. What does tell them apart: who is liable for the code that comes out of it, who owns the rights to it, and how do you bill for work that keeps getting faster? We answer that here as concretely as we can — including the places where the law is not yet settled.
Subject: our delivery model for AI-assisted software development · Roles in the flow: planning, organisation, development, code review, testing · Contract type: service contract, per period, cancellable monthly
In short
| Approval rule | No code generated by AI systems reaches the customer codebase without review and approval by a human lead developer. Per feature, not blanket. |
| Excluded from AI | Hardware-level development (sensors, measurements, real device behaviour) — guaranteed in the contract. |
| Data protection | Anonymisation by self-hosted models in our own infrastructure; external model providers only ever receive anonymised content. |
| Rights | Three separate arrangements: exclusive right of use for what can be protected, a covenant not to assert rights for what cannot, pre-existing rights stay with the provider. |
| Price | A fixed monthly price per team instead of a day rate. Model and infrastructure costs included. |
| Term | One period = two sprints = one calendar month. Cancellable monthly, without giving reasons, without minimum commitment. |
| First proof | A working interim result after the first development sprint, so after four weeks. |
What "agentic development" concretely means here
For us, agentic software development means this: alongside the human team, an orchestrated flow of specialised AI agents works across the roles of planning, organisation, development, code review and testing. Not a single model that "builds" a feature, but several models with different jobs, with defined hand-overs and review steps between them. The human in this setup is not a supervisor with a veto at the end, but the last instance before every merge.
"Do you use AI?" has become the most boring question in every first meeting. The answer is always yes. It is yes from every vendor you invite, and it was yes before anyone started talking about it.
The question that actually makes a difference is a different one: who is liable for the code that comes out of it?
I answer it here for us, as concretely as I can. Not because I think our way is the only one, but because most answers to this question currently consist of marketing copy.
What the flow actually looks like
The orchestration is tiered, and that tiering is the whole point.
Break down. Powerful models break requirements down into narrowly cut work packages. This is the most expensive step, and it pays off. The most common reason agentic development fails is not a weak model, but a work package that is too large.
Implement. Smaller, fast models with a deliberately limited scope do the implementation. A model that gets exactly one clearly defined task delivers more reliably than a strong model that has half a feature dumped at its feet.
Review. The review that follows runs on powerful models again, in multi-stage quality gates. Whoever implemented does not review. That is not an AI rule; it is an ordinary rule of software development, simply applied consistently here.
The line that is not negotiable
No code generated by AI systems reaches our customers' codebase without prior review and approval by a human lead developer. Approval is given per feature, not as a blanket, and it is the last instance before every merge into master.
That is the answer to the opening question. Liability sits with a named person who looked at the code first.
There is a second line we draw in the contract: hardware-level development is not generated by AI systems. Connecting sensors, interpreting measurements, understanding how real devices behave under real conditions — a specialist does that. Speed helps little here if nobody on the team has ever held the device in their hands.
Then there is how we handle the data itself. For anonymisation, we run self-hosted models inside our own infrastructure. External model providers only ever receive content that has been anonymised first. We clarify requirements for processing location and non-retention before the project starts, and we put them in the contract, not in a passing conversation.
The question hardly anyone asks
What actually happens to the rights to code that no human wrote?
Almost every service contract contains roughly the same sentence: the contractor grants the client the exclusive, unrestricted and transferable right to use the work results. That sentence worked for decades because a simple chain stood behind it. A person writes code, the code is a work protected by copyright, the person is its author, their employer holds the rights and can pass them on.
That chain breaks at one point as soon as a substantial share of the code is produced by machines.
Copyright protection requires a personal intellectual creation. Where no human creative threshold is reached, the prevailing view is that no protected right comes into existence at all. No author, no work, nothing on which an exclusive right of use could be granted. A vendor who promises it anyway is promising something they do not own. The customer signs a contract that grasps at nothing at this point, and typically only notices when it becomes uncomfortable: in due diligence, at an exit, in an audit, or at the moment they want to exclude a third party and discover they lack the legal position to do so.
The second point is even more uncomfortable, because no contract can cure it. Exclusivity towards the vendor can be arranged. Exclusivity towards the whole world cannot be created for unprotected parts — not with a sharper clause and not with a higher fee.
So we take a different route and arrange three things separately.
| What | How we arrange it | Why |
|---|---|---|
| Protectable work results | An exclusive, irrevocable and transferable right of use, unrestricted in territory, time and content — including modification, reproduction, distribution and sublicensing, "to the extent protected rights exist". | The qualification is not a retreat, but an honest description of the legal position. |
| Non-protectable parts | No grant of rights, but a covenant: we assert no rights of our own and do not hinder unrestricted use. | The legally clean substitute for something that cannot be transferred. In practice it puts the customer where they wanted to be. |
| Pre-existing rights | Methods, processes, tools, software components, the orchestration platform, prompts and model configurations stay with us; the client receives a simple, unrestricted right to use, maintain and further develop them. | Whoever moves this line too far in the customer's favour quietly sells off their own company in every project. |
What carries the actual protection in this model is not copyright, but confidentiality. Source code, technical documents and all information about the end customer are expressly confidential information for us, subcontractors we use are bound accordingly, and we only name a customer publicly as a reference with prior consent in text form. Whoever protects code through secrecy rather than copyright is on the more robust side in AI-assisted development. That is inconvenient for sales slides, but it holds.
This third line is the one most often drawn wrongly, in both directions. Whoever draws it too narrowly delivers a result the customer cannot run without the vendor, and then calls the dependency a partnership.
One question is, incidentally, still unanswered, and I see no point in pretending otherwise: what happens when a model reproduces someone else's protected code? Contractually, you can contain this through review duties, approval and documentation of the components used, and that is exactly what we do. Legally, it is not finally settled. Anyone who promises you an unlimited indemnity for it today either has a very large risk budget or has not understood the problem.
And then came the uncomfortable part
How do you bill for work that keeps getting faster?
Not by person-days, at least. A team that delivers with this kind of support needs less time for the same result. Whoever bills by time earns less with every gain in efficiency. You then quietly sell an interest in slowness along with it, and the customer knows it. The day rate is the only price in our industry that gets worse when the vendor gets better.
Our answer is a fixed monthly price for a complete team that can start work immediately. What it covers is deliberately broad.
The capacity. Two sprints of two weeks each, one team in the roles of IoT and security expertise, CI/CD and lead development, and delivery lead. The stated capacity shares are for commercial calculation. They create no obligation to provide specific people in specific time slots, and they are expressly not a quota of hours for someone to work off.
The machine costs. All costs of running the AI systems used are included, including the costs of external model providers and of the infrastructure we run ourselves. No surcharges, no passing on of tokens, no discussion about which model ran how often. That is more than a convenience for accounting. When model costs are passed through, there is an immediate incentive to use more of them, and the customer pays for every misconfiguration. If we miscalculate on tooling, that is our problem.
The travel. The amount includes travel costs for agreed appointments at the client's site. Only agreed trips outside the place of work are billed on top, with receipts attached to the invoice.
The scaling. We scale in whole teams, not in fractions of an FTE. Additional teams working in parallel under the same model, each at the same amount, announced ten working days before the period starts. The reason is not commercial but practical: half an extra developer does not make a well-rehearsed team faster; it keeps it busy.
What does not go away, despite all this, are the activity reports. We present them monthly; the client can object in text form within two weeks, otherwise they count as accepted. At first sight that is a contradiction: no billing by time, yet reports anyway. It resolves once you separate the two. The price does not depend on the effort. Transparency about what was worked on does. A customer who may not see what happens to their budget is not a partner, but a subscriber.
The team is a team, not a collection of individuals. Every role has a stand-in in-house, and we expressly reserve the right to exchange team members while keeping the same professional qualification. For buyers used to checking CVs and fixing names in the contract, that takes some getting used to. It is still the more reliable commitment. A project that depends on one person's holiday plans is not an offer, but a risk with an invoice.
Why we offer monthly cancellation
Work is commissioned per period; one period equals two sprints and therefore one calendar month. At the end of every period, the client decides whether to continue. The decision is due at the latest ten working days before the period ends, so we can plan capacity for the following month bindingly. If no notice arrives, the engagement automatically extends by one period.
This automatic extension is the one part of the model that could be held against us, so I name it myself. We defuse it with a duty on our side: at the latest five working days before the deadline, we send a reminder in text form about the decision that is due. A contract that extends because the customer forgot about it is not a business model, but a trick.
Ending the engagement itself is informal, in text form, without giving reasons, without remaining terms, and without settlement or cancellation payments. There is no minimum commitment across the six periods.
That is uncomfortable. It means we have to qualify again every month.
It is still the only honest construction I could find for this offer. We sell a promise about speed and quality that cannot be proven before the project starts. Whoever sells something like that and insists on minimum terms at the same time asks the customer to carry the entire risk of an unproven claim. That is why our first development sprint ends with a working interim result. After four weeks you know where you stand, and you can leave.
What we are liable for, and what not
This is where it gets truly uncomfortable, because at this point our contract contains a sentence that sounds like a retreat at first: the services are provided on the basis of a service contract. No specific outcome is owed.
Why don't we sell a contract for work and results if we are so convinced we can deliver?
Because a contract for work needs a conclusively described deliverable that is fixed before the start. That is exactly what does not exist in a project whose backlog is prioritised together and adjusted continuously. Whoever writes "contract for work" on it anyway then does one of two things: they build in a substantial risk premium that the customer pays whether or not the risk materialises. Or, from week three on, they defend the original scope against every insight the project produces. That is the point at which most fixed-price projects tip over internally, long before anyone says so.
So we take the service contract and put the risk somewhere else. Not into a promise of success that nobody can measure in a dispute anyway, but into cancellability. The customer is protected not by a guarantee, but by being able to stop paying us at any time. That is the sharper sanction, and it works without a lawyer.
What follows from this for liability is also stated expressly in the contract instead of in the small print. For intent, gross negligence and harm to life, body and health, we are liable without limit; nothing changes there. For the remaining cases of simple negligence in breach of essential contractual duties, liability is capped at a concrete amount per claim, and we have fixed that cap specifically for the project instead of copying it from a standard set of terms.
I know how that sounds in an article about trust. Still, I consider the alternative unserious. A mid-sized service provider that promises unlimited liability for consequential damage is either promising something its balance sheet cannot carry in an emergency, or it has priced the risk in and is not telling you. Both are more expensive for the customer than a cap that stands in a recognisable relation to the contract volume. And clauses where that relation is no longer recognisable will, in case of doubt, not survive a review under German standard-terms law anyway. A liability promise that is void in a dispute protects no one; it only feels reassuring at signing.
The proof: we build our own products with it
At this point, the fair follow-up question is: nicely described, but does it work?
The most honest answer a service provider can give is not a reference list, but its own product. We develop two, both with exactly the method I have described here.
Actana AI is an operating system for AI. One place where agents, information, apps and everyday automation live together, instead of being spread across four tools that were all built before agents existed. You build by describing in plain language, visually on a canvas, or with code. It is not tied to any AI provider, the model can be switched at any time, and it runs in our cloud or on the customer's own systems. We have been working on agents since 2020, long before the word appeared in every sales deck.
Actana Control is the tool behind the method. A self-hosted control plane for agentic coding: one panel over any number of machines running Claude Code, Codex, Cursor CLI and OpenCode in real terminal sessions against their repositories. The code never leaves the machine it already lives on. Nothing is uploaded or mirrored, and there is no telemetry. The project is MIT-licensed on GitHub and currently in pre-release.
The point is not product advertising. The point is that our orchestration is not a slide deck. It is software we use ourselves every day, whose control plane is publicly visible, and which is built under the same quality gates that run in customer projects. Whoever hires us does not get a concept that is invented during the project.
How we work when we want to prove something to ourselves is in our lab reports: a 320-billion-parameter model on a 16 GB MacBook and one game, two builds, zero publishable results. Both include the numbers, the uncomfortable ones too.
Frequently asked questions
Who is liable for AI-generated code?
With us, a named person. No code generated by AI systems reaches our customers' codebase without prior review and approval by a human lead developer. Approval is given per feature and is the last instance before every merge into master. Contractual liability then follows the normal rules: unlimited for intent, gross negligence and harm to life, body and health; for simple negligence in breach of essential contractual duties, capped at an amount per claim fixed specifically for the project.
Who owns the rights to AI-generated code?
There is no blanket answer, and that is exactly the point. Copyright protection requires a personal intellectual creation. Where no human creative threshold is reached, no protected right comes into existence — and so there is nothing on which an exclusive right of use could be granted. We therefore arrange three things separately: an exclusive right of use for the protectable work results, a covenant not to assert rights for the non-protectable parts, and pre-existing rights to our own methods and tools, with a simple right of use for the client.
Is AI-assisted development GDPR-compliant?
It can be, if the data flow is governed. For anonymisation, we run self-hosted models inside our own infrastructure. External model providers only ever receive content that has been anonymised first. We clarify requirements for processing location and non-retention before the project starts and put them in the contract. Whoever only asks these questions during the project has asked them too late.
Why no contract for work and no fixed price per project?
A contract for work needs a conclusively described deliverable that is fixed before the start. That does not exist in a project whose backlog is prioritised together on an ongoing basis. Whoever writes "contract for work" on it anyway either builds in a risk premium the customer pays in any case, or defends the original scope against every new insight from week three on. We take the service contract and move the risk into monthly cancellability.
Why no day rate?
Because the day rate is the only price in our industry that gets worse when the vendor gets better. A team that delivers with agentic support needs less time for the same result. Whoever bills by time earns less with every gain in efficiency — and so quietly sells an interest in slowness along with it. Instead, we charge a fixed monthly price per team, which also includes all model and infrastructure costs.
The short answer
Machines write. People approve. Whoever approves is liable.
And whoever claims to be faster because of it should do three things: build the price so that it profits from their own speed instead of fearing it. Name the limits of their own liability instead of making promises that do not hold when it matters. And leave the door open for the customer, so the promise has to be kept again every month.
If you have a project for which you currently lack development capacity, and building your own team through recruiting and onboarding no longer fits your timeline: we provide a complete team that can work from the first sprint. After four weeks you see a working interim result and decide again.
Feel free to write to me directly, or first take a look at what we have built for ourselves with this method.