AI-DLC & augmented testing

Verify at the pace you now generate

Ninety per cent of development professionals now work with AI, and the volume of code arriving for review has gone up accordingly. What decides whether that speed turns into delivered value or into instability is not the assistant: it is what verifies its output, and how early.

Frame your AI-DLCEstimate your augmented project

AI does not fix a delivery chain. It amplifies the one you have.

Adopting AI speeds up the production of code without, on its own, improving what controls it. The volume arriving for review goes up, and it arrives into the gates that were already there.

Our work therefore addresses the chain rather than the assistant: requirements written to execute, tests derived from the expected behaviour, a small number of gates that hold, and a named engineer who answers for what is delivered. That is what separates a team producing more from a team delivering more.

What we do

Four workstreams, from the requirement written to execute to the incident seen before the user.

WORKSTREAM 01Intent, not opinion

Write the requirement so it executes

Expected behaviours in a form a machine can check, produced with the business rather than after it. It is what lets generated code be compared against intent instead of against the opinion of whoever reviews it.

a requirement clarified verbally cannot arbitrate a generated pull request

  • One behaviour, one executable check
  • Written with the business, before generation
  • The gap with the code shows by itself
WORKSTREAM 02Not from the code

Generate the tests from the requirement

Test cases derived from the specification, not from the code that was just written. Code-derived tests confirm what the code does, including its defects, which is exactly the trap when the code was produced in seconds.

a test written after the code confirms the code, defects included

  • Cases derived from the behaviour, not the implementation
  • Ambiguity in the requirement surfaced, not smoothed over
  • Coverage measured on behaviours, not on lines
WORKSTREAM 03At commit, not at acceptance

Hold a small number of gates

Behaviour coverage, dependency vulnerabilities, accessibility and a weight budget, checked at commit. Few enough that nobody switches them off the first time a release is at risk, which is what makes them gates.

four gates that always hold beat twenty that hold until a hard week

  • Blocking checks kept deliberately few
  • An assistant proposes, a named engineer answers
  • Duplication watched, since that is where it drifts
WORKSTREAM 04The last verification

Verify what production says

Service level objectives set on real journeys, detection that sees a business incident before customers report it, and every deployment traceable back to the change that caused it.

a chain that ships fast without observing lands its defects faster

  • Objectives on journeys, not on infrastructure
  • Detection before the first customer call
  • Each deployment traceable to its change

The loop we equip

Figure · The AI-DLC cycle

The AI-DLC lifecycle

Four phases, one governed loop: framing turns intent into specifications, agents generate, guardrails verify, and delivery ships continuously.

The four phases

Framing
Intent becomes executable specifications.
Generation
Agents scaffold, refactor, document.
Guardrails
Checks, security gates, human review.
Delivery
From branch to production, observed.
Software governed end to end
Every decision traced, every change reviewed: the speed of AI without losing control of it.
Legend
FramingGenerationGuardrailsDelivery

What you get

One project runs through the four deliverables below: rebuilding a subscription journey with the augmented chain. Each step states what is actually handed over, in the order it is handed over.

01/ perimeter

The perimeter given to the agents

What they are allowed to produce, and the three areas they never touch: premium calculation, migration of live contracts, and anything writing to the customer record. Decided beforehand, not during.

01-perimetre-agents.yaml · parcours-souscription

parcours-souscription

  • 01-perimetre-agents.yaml
  • 02-tests-derives.feature
  • 03-barrieres.yaml
  • 04-mesure.yaml
# Un assistant sans périmètre écrit finit par toucher au calcul de
# prime un vendredi soir. Le périmètre se décide avant, pas pendant.

confie_aux_agents:
  - écrans et composants d'interface
  - appels aux services existants
  - tests unitaires et de composant
  - documentation technique et journal des décisions

jamais_confie:
  - le calcul de prime et les règles tarifaires
  - la migration des contrats en cours
  - tout ce qui écrit dans le référentiel client
  # Non par méfiance envers l'outil : ces trois zones portent des
  # règles métier négociées avec l'actuariat, dont l'écart ne se voit
  # ni à la compilation ni au test.

conventions_donnees_a_l_agent:
  standards: le guide interne, versionné, pas un prompt oral
  interdits: dépendance nouvelle sans arbitrage écrit
  style: celui du dépôt, vérifié par le formateur automatique

signature:
  regle: chaque changement porte le nom d'un ingénieur
  # Le volume produit ne change pas qui répond. Il change seulement
  # le temps que cette personne doit pouvoir y consacrer.
02/ tests

Tests derived from the requirement

Scenarios written from the expected behaviour rather than from the generated code, including the ambiguity the assistant silently resolved on its own and which goes back to the business.

02-tests-derives.feature · parcours-souscription

parcours-souscription

  • 01-perimetre-agents.yaml
  • 02-tests-derives.feature
  • 03-barrieres.yaml
  • 04-mesure.yaml
# Ces cas sont dérivés de l'exigence, pas du code produit. Un test
# écrit après le code confirme ce que le code fait, ses défauts
# compris, ce qui ne prouve rien.

Fonctionnalité: souscription d'un contrat par un client

  Scénario: le conseiller a la main sur le contrat
    Étant donné un contrat en cours de modification par un conseiller
    Quand le client tente de le modifier
    Alors la modification est refusée
    Et le motif du refus est affiché au client

  Scénario: justificatif au-delà de la limite
    Étant donné un justificatif de 12 Mo
    Quand le client le dépose
    Alors le dépôt échoue avant l'envoi
    # Avant l'envoi, pas après : la différence est invisible côté
    # code, et très visible côté client sur une connexion mobile.

  # AMBIGUÏTÉ RELEVÉE, pas tranchée par nous
  # Deux conseillers ouvrent le même contrat en même temps.
  # L'exigence ne dit pas lequel garde la main. L'assistant, lui,
  # a produit un comportement : le dernier arrivé gagne. C'est une
  # décision métier, prise par défaut, par personne.
  # → renvoyée à l'actuariat avant d'écrire le scénario.

  Scénario: accessibilité du parcours complet
    Étant donné le parcours de souscription de bout en bout
    Quand il est audité selon la norme EN 301 549
    Alors aucune violation automatique n'est relevée
03

Four gates, not fifteen

Behaviour coverage, vulnerabilities, accessibility and a duplication ceiling. Line coverage and cyclomatic complexity are deliberately left non-blocking: they are gamed without proving anything.

04

A measurement of the chain, three months in

Throughput doubled and every gate held. The bottleneck moved to human review, at thirty-one hours before first read, which is exactly where a bottleneck belongs.

How we deliver

PHASE 012 to 6 weeks

Discover

depending on scope, sector and the level of compliance required

  • Audit of use cases and pain points
  • Value / feasibility matrix
  • Executable specification (ASDD)
PHASE 024 to 10 weeks

MVP

depending on system complexity and integrations

  • An agent in a real environment
  • Generated tests, measured coverage
  • Go / no-go before industrialisation
PHASE 033 to 6 months

Scale

depending on the number of agents and connected systems

  • Multi-agent orchestration on a shared foundation
  • CI/CD and MLOps integration
  • Team upskilling
PHASE 04continuous

Run

service commitment defined with you

  • LLMOps observability
  • FinOps optimisation of AI costs
  • Continuous compliance audit

What the AI-augmented chain actually shows

2 h
is the median time a development professional spends working with AI each day, in DORA's State of AI-assisted Software Development 2025: the volume arriving for review changed scale
3.8%
of changed lines are moved code, meaning refactored, in 2026 against 21% in 2022, while duplicated blocks are up 81% over 2023, in GitClear's Maintainability Gap research
30%
of developers report little or no trust in the code AI produces, while more than 80% credit it with improving their productivity, in the same DORA study

Chains that hold at speed

View all projects
Gates that hold, on eighteen squads at once
Ageas FranceInsurance
Quality gates
Case(01)

Gates that hold, on eighteen squads at once

coverage 41% → 83% · post-release incidents ÷4

The challenge

Life insurance products where a defect reaching production is a policy miscalculated, on a delivery chain that had to speed up across eighteen product squads without the checks becoming negotiable when a date got close.

Our answer

Blocking quality gates built into the chain rather than bolted beside it, test coverage taken from forty-one to eighty-three per cent, and the practice transferred through an internal DevOps academy so the squads keep it running themselves.

Read the case study
Seeing the incident before the customer does
BforBankBanking
Verified in production
Case(02)

Seeing the incident before the customer does

time-to-detect ÷5 · P1 remediation ÷3

The challenge

Payment, login and transfer journeys where an incident is noticed by customers before the monitoring, and where every minute of detection is a minute of transactions that did not go through.

Our answer

Forty-eight service level objectives aligned on real journeys rather than on infrastructure, detection of a business incident brought from twenty-five minutes to under five, and P1 remediation from twenty-eight minutes to nine.

Read the case study

Insights & Perspectives

AI-DLC09.10.2025

AI-generated test cases from user stories

A controlled experiment measures what AI test generation actually returns: eighty per cent of time saved, and twenty-seven per cent of ambiguity left in the requirement.

AI-DLC24.09.2025

How can AI simplify and speed up user acceptance testing?

Automating scenario generation, results analysis and anomaly detection in acceptance testing, and what that changes for the people who run it.

AI-DLC04.09.2025

Fuzz testing in the AI era

A forty-year-old technique that never saw wide adoption, and what changes now that generating and triaging cases costs almost nothing.

Go to the Adservio blog
TALK TO AN EXPERT

Verify at the pace you now generate

Executable requirements, tests derived from the behaviour, a small number of gates that hold, and production watched on the journeys that matter.

By submitting this form, you agree to our privacy policy.

Frequently asked questions

No. DORA's 2025 research finds that AI adoption raises delivery throughput and delivery instability at the same time. AI amplifies the chain you already have: where the controls hold, the gain is real; where they were negotiable, the damage simply arrives sooner and in greater volume.

Because a test derived from code confirms what the code does, including its defects. That was already a weak habit; it becomes a trap when the code was produced in seconds and nobody has read it line by line. Deriving cases from the written behaviour is what lets the two be compared at all.

By moving the reading onto the requirement rather than onto every line. The executable behaviours say what was expected, the derived tests fail where the code departs from it, and a named engineer signs off on the result. Reading everything stopped being possible; checking everything against a written intent did not.

Duplication, and the share of code that gets refactored. GitClear measures moved code falling to 3.8% of changed lines in 2026 against 21% in 2022, while duplicated blocks rose 81% over 2023. An assistant makes inserting a block cheaper than restructuring one, and that shows up in maintenance a year later.

Few. A long list of blocking checks gets switched off the first time a release is at risk, and never comes back. Four that always hold are worth more than twenty that hold until the first difficult week, and it is that reliability, not their number, that makes them gates.

It moves the effort earlier. Writing a behaviour so it executes costs hours; discovering at acceptance that the generated code answered a different question costs a rebuild. The specification also does double duty, since it is what the review compares the generated code against.

Framing takes 2 to 6 weeks depending on scope, sector and the level of compliance required, and produces the executable behaviours, the gates that will block and the perimeter given to the agents. A first journey delivered through the augmented chain, in production rather than in a demonstrator, follows in 4 to 10 weeks.

Question not covered? Ask us