Most of the public debate on AI coding agents, in Italy and elsewhere, is measured on one question: how much code they write, and how fast. Software houses that build on contract, for multiple clients at once, under agreements built around formal acceptance testing, run into a different question that debate never asks: whose code is it once an agent wrote part of it, who answers for it in front of the client, and what has to ship alongside the software so that answer still holds months later. This piece describes the contracting model common in Italy and continental Europe, built around a formal handover and acceptance step (collaudo, in Italian contract practice) rather than the looser work-for-hire norms elsewhere.
What does an AI agent actually do, without the hype?
An AI coding agent is a program that, given a goal written in plain language, decides on its own which files to read, which to change, which commands to run, and when the task counts as done, without a person approving each intermediate step.
For a software house working under contract, that changes the relationship with code written for a client: it is no longer only the developer who decides how to get to the result, an agent decides part of that too, inside whatever boundaries someone at the company set. The contract with the client, though, does not distinguish between a line written by a person and a line written by an agent: it talks about delivery, conformance to specification, and accountability to whoever commissioned the work. Adding an agent to a contracted workflow adds a layer of autonomy in execution without touching the layer of contractual accountability, which stays whole and stays with the software house, not with the agent or the model vendor.
The code belongs to the client: what changes right away?
In most contracted software agreements, ownership of the code passes to the client on delivery or payment, regardless of who wrote it, and that does not change with an agent in the loop. The terms of use of the major agent vendors today assign output rights to the company using them, so the formal chain of ownership stays intact.
What actually changes is something less formal and more concrete: who can explain, months later, why a piece of code looks the way it does. With a human developer, the answer is almost always "ask whoever wrote it." With an agent launched by someone who has since moved to another project, or a company that has since changed contractors, that person is no longer enough on their own: what is needed is a record of the session, not a memory of it.
What changes at acceptance testing when an agent wrote the work?
Acceptance testing on a contracted software agreement exists to verify, before final payment, that the delivered work matches what was agreed. Historically it checks the outcome: tests pass, features exist, requirements are met. When part of the code comes from an agent, acceptance should also check a layer upstream of that, and today almost nobody does: did the agent actually have permission to touch those files, in that scope, with that level of autonomy?
Trusting the gut feeling that "the work looks fine" because someone watched it happen during the session is shakier than it seems. The 2025 METR randomized controlled trial, run on experienced developers working in real repositories, measured that developers using AI tools felt 20% faster once the work was done, while they were actually 19% slower, despite having predicted beforehand that they would be 24% faster. If a session's own sense of speed is that unreliable, the same holds for its sense of correctness: what is needed is verification done outside the session, not the impression of whoever launched it.
What should ship alongside the software?
| Traditional development | With an agent in the loop | |
|---|---|---|
| Who wrote the line | An identifiable person, in the commit | An agent, authorized by a person |
| What proves it was authorized | Usually the ticket or the work order | Often nothing but the prompt in a chat log |
| If the client asks months later | Ask whoever wrote that line | Need to know who launched that session |
| What acceptance testing needs | Passing tests, requirements covered | Passing tests plus proof of authorized scope |
Almost nobody writes that right-hand column today. AI coding agents get judged on how much code they produce and how good it is, not on what remains as proof once the session closes. On contracted work, that proof is not a nice-to-have: it is the difference between being able to answer a client and having to reconstruct what happened from memory.
How to bring in agents without losing control of the contract
A few concrete steps before letting an agent work on code that will ship to a client:
- Write down, per engagement, which files and repositories the agent may touch, rather than letting it infer that from chat context.
- Keep a session log tied to the task and the engagement, not just to the tool's own history.
- Feed that log into contractual acceptance testing, not only into internal code review.
- Do not accept "the tests pass" as sole proof when the same agent that wrote the code is the one saying so, for the same reason a developer does not review their own pull request on serious contracted work.
- Sign off delivery with the name of the person who reviewed it, not the name of the agent or the tool.
None of this is a reason to slow down adoption: agentic development stays a process decision, not a reason to hold back. What changes is what a company needs to have ready when a client, instead of asking for a new feature, asks for an account of the one already delivered. That is the same question Detent Bench measures along the line from requirement to release: not just whether the code works, but who can still prove it once the agent has closed the session. Detent, the end-to-end delivery system (detent-ai.com), starts from exactly this question on real contracted work, not from a final signature detached from the work that came before it.