We build Agents. You build the Future.
● Business offer — Testing & software qualityThe AI agent for testing & software quality: generate the tests, make your releases reliable
Writing the tests, reproducing a bug, hunting a regression before going to production takes up a considerable share of the team's time — essential work that is rarely valued. Your AI agent absorbs that repetitive work: test generation, coverage analysis, regression detection. Data hosted in France; the AI model is called at its publisher, except with the Sovereign model option. With the 100% Sovereign package, your source code never leaves your environment. The developer keeps the lead.
Updated on
Deployed in a few weeks
QA assistant · hosted in France
Fictional simulation — not a client result
The payment module has almost no tests. Generate a suite for the checkout service and tell me what is not covered.
Checkout service analysed. Current coverage: 34%. I have generated 18 unit tests (basket calculation, discounts, VAT) and 4 end-to-end tests (the full funnel). 3 uncovered paths remain risky: partial payment failure, provider timeout, double form submission.
Suite ready to review and run in CI — you approve before the merge.
⛓ Sourced · your repository + the existing coverage report
Suite ready to review and run in CI — you approve before the merge.
⛓ Sourced · your repository + the existing coverage report
The last deployment broke something in production. Can you help me isolate the regression?
Regression located. Comparing the last two releases, the error appears after the commit that changes the shipping cost calculation (rounding changed from 2 to 0 decimals). Reproduction confirmed by a targeted test: a €49.99 basket → shipping charged at €0 instead of €4.90.
I am preparing the regression test and a note for the ticket — for your approval.
✎ Action · regression test ready — the developer approves
I am preparing the regression test and a note for the ticket — for your approval.
✎ Action · regression test ready — the developer approves
Data hosted in France · sovereign model as an option
Code hosted in France
Hosted in FranceAI model called at its publisher, except with the Sovereign model option
Source code protected
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
The developer decidesThe agent proposes, you approve the merge
For an organisation established outside the European Union, the law of its own country applies; at its request, we put equivalent safeguards in place (human review before any action, a log of the criteria, information for the people concerned).
✦ In brief
In a development team, a Blue Lemon Agent agent automates the software quality work — generating unit and end-to-end tests, coverage analysis, reproducing bugs, catching regressions — and integrates with your continuous integration pipeline. Data hosted in France; the AI model is called at its publisher, except with the Sovereign model option. With that option, your source code and your intellectual property are never exposed to a foreign service, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. The time saved on tests is reinvested in features and reliability. Live within a few weeks.
100%
hosted in France in the target architecture
0
transfer outside the EU with the Sovereign model option (target architecture)
2
uses ready to deploy on this scope
0
decision with a legal or significant effect taken by an agent
Reference points describing our offer, not results measured at a client. The scale of the gain is confirmed by a pilot on your own scope.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
Pricing
One package, one dedicated agent
A testing and software quality agent (test generation, regression detection, coverage), installed and operated for you. Prices exclude VAT — annual subscription, the time it takes for the reliability gains to settle in.
Agility
Setup + controlled subscription
2,360 € excl. VAT setup
then 272 € excl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
402 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Hosting in France, managed end to end
100% Sovereign
On site, you own it
4,135 € excl. VAT setup
then 369 € excl. VAT/month · + hardware from 2,491 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Included in the package: hosting and AI consumption up to the volume of your capacity tier, in documents, exchanges, tokens and storage; beyond that, re-invoiced at real cost with no margin, tracked in your client area as usage statements are issued. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting for the package chosen, in France by default, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Use cases
The uses of AI for testing and software quality
Here are the capabilities included in the agent, then the neighbouring agents that can be added to it. The agent carries out by itself what you authorise it to do; you decide what it does on its own and what it submits to you.
Included in your agent
The 2 capabilities essential to this promise are included, at no extra cost.
From 272 € excl. VAT / month
Testing & software quality
Generating unit and end-to-end tests, coverage analysis, reproducing bugs and catching regressions, integrated with your CI.
Technical knowledge base
Instantly find an architecture decision, a past bug or a convention in your repositories and your wikis.
Controls and safeguards
These 5 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human validation, exceptions and escalation
Status, safe closure and audit trail
Access the technical context with least-privilege permissions
Run tests, security analysis and human review before any change
Version, log, roll back and measure quality
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
Code generation & review
Writing, refactoring and reviewing code: a copilot that proposes, flags the risks and documents, subject to your approval.
Code generation & review from 324 € excl. VAT / month Code generation & review →Web development
Designing, evolving and testing websites and web applications — from the component to the integration, with the tests that go with them.
Website development from 309 € excl. VAT / month Web development →Mobile applications
Developing and hardening iOS and Android applications, covering the critical journeys with automated tests.
Mobile app development from 314 € excl. VAT / month Mobile applications →Technical support & documentation
Keeping documentation up to date and answering internal technical questions from your code and your procedures.
Technical support & documentation from 344 € excl. VAT / month Technical support →
Does your need fall outside this?
Build your agent
In 30 minutes we identify the most relevant agent — without oversizing the project.
Demonstration
See the agent at work
5 everyday situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data. The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds. The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
QA assistant · hosted in France
Fictional simulation — not a client result
Four things spotted this morning, and none concerns a failing test — each comes with what it makes possible.
· Forty-one tests would pass even if the function under test always returned the same value. For 29 of them, the missing assertion is already written.
· Seven flaky tests were rerun 312 times this quarter — I found the cause for five of them, and the isolation is written.
· Your coverage shows 87%, and three modules carrying payments are at 12% — those three are the ones worth covering first.
· Thirty-four code changes touched no test — they are flagged on the branch, before the merge: there is still time to write the test along with the change. morning-watch_4-findings.pdf41 tests to re-arm · 29 assertions already written
⛓ Source · 1,240 tests, run log, coverage by module, branch history
· Forty-one tests would pass even if the function under test always returned the same value. For 29 of them, the missing assertion is already written.
· Seven flaky tests were rerun 312 times this quarter — I found the cause for five of them, and the isolation is written.
· Your coverage shows 87%, and three modules carrying payments are at 12% — those three are the ones worth covering first.
· Thirty-four code changes touched no test — they are flagged on the branch, before the merge: there is still time to write the test along with the change. morning-watch_4-findings.pdf41 tests to re-arm · 29 assertions already written
⛓ Source · 1,240 tests, run log, coverage by module, branch history
Tests that would pass whatever happened?
Forty-one, and they have always been green — which is what makes them invisible.
What I record: 41 tests have no assertion on the result of what they call. They check that no error was raised, and nothing else.
How I verified it rather than assumed it: I mentally replaced each function's return with a constant value. All 41 tests still pass. It is a mechanical check, not a judgement of style.
What that produces: they count in coverage, they count in the number of tests, and they give the feeling that the function is tested. A team seeing "covered" does not rewrite the test.
What I do: I mark them "no result assertion", and take them out of the coverage figure I publish. Your real coverage then goes from 87% to 79%.
And I do not stop at the marking: for 29 of the 41, the missing assertion is obvious from the function called — an expected return, a length, a status — and I have written it; the other twelve carry a question, because the expected result is written nowhere.
Why I do not delete them: a test with no assertion still checks that the code runs — that is little, it is not nothing, and deleting them would lower a figure without improving anything. Twenty-nine reviews, and the real coverage goes back up for good. 41-tests_87-to-79.pdfThey pass even with a constant value
⛓ Source · 1,240 tests, check by substituting the return value
What I record: 41 tests have no assertion on the result of what they call. They check that no error was raised, and nothing else.
How I verified it rather than assumed it: I mentally replaced each function's return with a constant value. All 41 tests still pass. It is a mechanical check, not a judgement of style.
What that produces: they count in coverage, they count in the number of tests, and they give the feeling that the function is tested. A team seeing "covered" does not rewrite the test.
What I do: I mark them "no result assertion", and take them out of the coverage figure I publish. Your real coverage then goes from 87% to 79%.
And I do not stop at the marking: for 29 of the 41, the missing assertion is obvious from the function called — an expected return, a length, a status — and I have written it; the other twelve carry a question, because the expected result is written nowhere.
Why I do not delete them: a test with no assertion still checks that the code runs — that is little, it is not nothing, and deleting them would lower a figure without improving anything. Twenty-nine reviews, and the real coverage goes back up for good. 41-tests_87-to-79.pdfThey pass even with a constant value
⛓ Source · 1,240 tests, check by substituting the return value
How did you spot all that? And who do you tell?
I look at what you have opened to me: tests and their assertions, the run log including reruns, coverage by module, and code changes set against test changes.
Routing follows what can be fixed: a test with no assertion goes to whoever wrote it if identifiable, otherwise to the team; a test rerun until it passes to the team, with the rerun count — never to a person; a poorly covered critical module to whoever sets priorities; a change with no test flagged on the branch, before merging.
With a chase: before merging on a change with no test, monthly otherwise. Then a monthly summary: by module and type of weakness, never by developer.
What this gives you this morning: a true coverage figure — 79% instead of an 87% inflated by 41 assertion-free tests —, seven flaky tests identified after 312 reruns, three payment modules at 12% raised to whoever sets priorities, and 34 behaviour changes that nothing checked any more, flagged on the branch before merging.
What that is worth in production: a figure you can decide on, and the test-writing time given back to features — across 1,240 tests, a module's suite arrives prepared, edge cases included, and it is left to you to review. Your repositories do not leave the team: access by role, logged, withdrawn on a word, local inference with the 100% Sovereign package; with the Agility and Serenity packages, data hosted in France, AI model called at its publisher except with the Sovereign model option, and your code trains no third-party model.
What stays with you is a choice, not a reservation: I write tests from the specification and never from current behaviour, because a test written on existing code turns a bug into a requirement. Give me the expected behaviour of the three payment modules — and the full suite is ready to review the same day.
✎ Framework · no test written from current behaviour, no reruns
Routing follows what can be fixed: a test with no assertion goes to whoever wrote it if identifiable, otherwise to the team; a test rerun until it passes to the team, with the rerun count — never to a person; a poorly covered critical module to whoever sets priorities; a change with no test flagged on the branch, before merging.
With a chase: before merging on a change with no test, monthly otherwise. Then a monthly summary: by module and type of weakness, never by developer.
What this gives you this morning: a true coverage figure — 79% instead of an 87% inflated by 41 assertion-free tests —, seven flaky tests identified after 312 reruns, three payment modules at 12% raised to whoever sets priorities, and 34 behaviour changes that nothing checked any more, flagged on the branch before merging.
What that is worth in production: a figure you can decide on, and the test-writing time given back to features — across 1,240 tests, a module's suite arrives prepared, edge cases included, and it is left to you to review. Your repositories do not leave the team: access by role, logged, withdrawn on a word, local inference with the 100% Sovereign package; with the Agility and Serenity packages, data hosted in France, AI model called at its publisher except with the Sovereign model option, and your code trains no third-party model.
What stays with you is a choice, not a reservation: I write tests from the specification and never from current behaviour, because a test written on existing code turns a bug into a requirement. Give me the expected behaviour of the three payment modules — and the full suite is ready to review the same day.
✎ Framework · no test written from current behaviour, no reruns
Fictional simulation — not a client result
Can you generate tests for our existing code?
I can, and I will tell you why I propose the opposite.
What I am asked: go through a function and produce the tests that pass. It is immediate and the result is green.
What then happens: every existing defect becomes expected behaviour. If the function rounds wrongly, the test checks that it rounds wrongly. The day somebody fixes it, the test fails — and the test gets fixed.
What I do instead: I start from what the code is supposed to do, as you have told me — a specification, a ticket, a comment, a business rule. And when I have nothing, I say so and I do not write the test.
What that gives, measured: across 214 functions to cover, I produced tests for 148. For 66, I had no source describing the intended behaviour — I supplied the list rather than tests.
What the 66 revealed: eleven concerned business rules nobody on the team could state. It is the most useful result of the exercise, and it is not a test. 214-functions_66-without-source.pdf11 rules nobody could state
⛓ Source · 214 functions, 148 tests produced, 66 with no source
What I am asked: go through a function and produce the tests that pass. It is immediate and the result is green.
What then happens: every existing defect becomes expected behaviour. If the function rounds wrongly, the test checks that it rounds wrongly. The day somebody fixes it, the test fails — and the test gets fixed.
What I do instead: I start from what the code is supposed to do, as you have told me — a specification, a ticket, a comment, a business rule. And when I have nothing, I say so and I do not write the test.
What that gives, measured: across 214 functions to cover, I produced tests for 148. For 66, I had no source describing the intended behaviour — I supplied the list rather than tests.
What the 66 revealed: eleven concerned business rules nobody on the team could state. It is the most useful result of the exercise, and it is not a test. 214-functions_66-without-source.pdf11 rules nobody could state
⛓ Source · 214 functions, 148 tests produced, 66 with no source
And if we just give you the code, with no specification?
Then I produce questions, not tests.
What I supply for each function with no source: what the code does today, described in one sentence, and the three or four points where its behaviour could be deliberate or accidental.
An example, as it stands: "this function returns zero when the list is empty. Is that the intended result, or an unhandled case? Depending on the answer, the test to write is not the same — and one of the two will fail."
What I write alongside the question: both tests, one per possible answer, ready to merge. Which one survives depends on a sentence, not on a day's work: the answer arrives, and the right test enters the suite the same day.
Why that is more useful than a test I picked myself: because the answer exists with somebody. Of the 66 questions asked, 55 got an answer within a week, often in two lines. Eleven did not, and those are the ones that matter.
Why I do not pick the most likely interpretation to unblock things: a test written on an assumption is exactly the same shade of green as a test written on a rule — and in six months nobody will know which of the two they are looking at.
What I do with the eleven: I leave them open, and they reappear every month until somebody settles them. It is the only thing I repeat. 66-questions_55-answers.pdfA test on an assumption is the same shade of green
⛓ Source · 66 questions asked, 55 answers received
What I supply for each function with no source: what the code does today, described in one sentence, and the three or four points where its behaviour could be deliberate or accidental.
An example, as it stands: "this function returns zero when the list is empty. Is that the intended result, or an unhandled case? Depending on the answer, the test to write is not the same — and one of the two will fail."
What I write alongside the question: both tests, one per possible answer, ready to merge. Which one survives depends on a sentence, not on a day's work: the answer arrives, and the right test enters the suite the same day.
Why that is more useful than a test I picked myself: because the answer exists with somebody. Of the 66 questions asked, 55 got an answer within a week, often in two lines. Eleven did not, and those are the ones that matter.
Why I do not pick the most likely interpretation to unblock things: a test written on an assumption is exactly the same shade of green as a test written on a rule — and in six months nobody will know which of the two they are looking at.
What I do with the eleven: I leave them open, and they reappear every month until somebody settles them. It is the only thing I repeat. 66-questions_55-answers.pdfA test on an assumption is the same shade of green
⛓ Source · 66 questions asked, 55 answers received
Fictional simulation — not a client result
The 7 tests rerun 312 times?
They fail one time in six, they get rerun — and the cause is found for five of the seven.
What I record: seven tests failed then passed with no line of code changing between the two runs. Total this quarter: 312 reruns.
What that means: either the test depends on something it does not control — a clock, an execution order, a shared resource — or the code itself is unstable, and the test is detecting it correctly. Those two cases look identical in the log.
Why I do not rerun: an automatic rerun turns a test that finds a real defect into a test that always ends up passing, and the defect goes to production. Across 312 reruns, one is enough for that to happen once.
What I do: I mark the test flaky and take it out of the merge decision — it keeps running and reporting, but it blocks nothing. A test rerun until it passes was already blocking nothing: it was wasting time without protecting.
What I found looking for the cause: of the seven, five fail only when another test touches the same table — that is an execution dependency, not product instability. The isolation is written for all five: one database per test, and the 312 reruns fall to zero. The other two fail on their own, and those deserve a developer's eye.
What I supply for each: the failure rate, the times of the failures, and what was running alongside. 7-tests_312-reruns.pdf5 of 7 fail on the same table
⛓ Source · 7 tests, 312 reruns, parallel run log
What I record: seven tests failed then passed with no line of code changing between the two runs. Total this quarter: 312 reruns.
What that means: either the test depends on something it does not control — a clock, an execution order, a shared resource — or the code itself is unstable, and the test is detecting it correctly. Those two cases look identical in the log.
Why I do not rerun: an automatic rerun turns a test that finds a real defect into a test that always ends up passing, and the defect goes to production. Across 312 reruns, one is enough for that to happen once.
What I do: I mark the test flaky and take it out of the merge decision — it keeps running and reporting, but it blocks nothing. A test rerun until it passes was already blocking nothing: it was wasting time without protecting.
What I found looking for the cause: of the seven, five fail only when another test touches the same table — that is an execution dependency, not product instability. The isolation is written for all five: one database per test, and the 312 reruns fall to zero. The other two fail on their own, and those deserve a developer's eye.
What I supply for each: the failure rate, the times of the failures, and what was running alongside. 7-tests_312-reruns.pdf5 of 7 fail on the same table
⛓ Source · 7 tests, 312 reruns, parallel run log
Coverage at 87% with modules at 12%?
The overall figure is true, and it describes exactly the opposite of reality.
What I record: overall coverage 87%. Three modules carrying the calculation and recording of payments: 12%, 19% and 24%. What pulls the average up are display modules, covered at 96%.
Why that is the indicator's very meaning: what is simple is easy to cover, and a display module is easier to test than a pro-rata calculation. A team optimising its coverage therefore tests first what breaks least.
What I do not publish: the overall rate. It carries no information — two pieces of software at 87% can be in opposite states.
What I publish instead: the coverage of the modules you have designated as critical, and nothing else. Three figures, not one.
What I propose: that the list of critical modules be written by you, not inferred by me. I proposed seven based on past incidents; you kept five and added two I had not thought of. 87-percent_3-modules-at-12.pdfWhat is simple is easy to cover
⛓ Source · coverage by module, list of critical modules
What I record: overall coverage 87%. Three modules carrying the calculation and recording of payments: 12%, 19% and 24%. What pulls the average up are display modules, covered at 96%.
Why that is the indicator's very meaning: what is simple is easy to cover, and a display module is easier to test than a pro-rata calculation. A team optimising its coverage therefore tests first what breaks least.
What I do not publish: the overall rate. It carries no information — two pieces of software at 87% can be in opposite states.
What I publish instead: the coverage of the modules you have designated as critical, and nothing else. Three figures, not one.
What I propose: that the list of critical modules be written by you, not inferred by me. I proposed seven based on past incidents; you kept five and added two I had not thought of. 87-percent_3-modules-at-12.pdfWhat is simple is easy to cover
⛓ Source · coverage by module, list of critical modules
Fictional simulation — not a client result
With every new developer we re-explain the same testing rules. Can you do something about it?
The technical knowledge base for your test pipeline is written, and it is backed by your own runs, not by a general best practice.
What it holds: 34 entries, each drawn from a case that actually happened here — the 41 assertion-free tests and the mechanical check that detects them, the quarantine rule with its date and owner, the seven flaky tests with what makes them flaky (a clock, an execution order, a shared resource), and why coverage is read per module when the global figure says 87 % and the payment module says 12 %.
What separates it from a best-practice guide: every entry cites the dated run that produced it. A rule with no incident behind it does not enter this knowledge base: it would be argued away at the first emergency, and it would lose.
What it has already changed: across the 19 branches opened since it was made available, 3 assertion-free tests were written, against 11 over the previous 19 branches. The honest figure is 3, not 0: a technical knowledge base reduces, it does not abolish.
What I propose next: tie each entry to the check that enforces it, so the rule lives in the pipeline and not only in a text — 4 of the 34 entries have no check facing them today, and I tell you which.
⛓ Source · 34 entries backed by dated runs, 3 assertion-free tests over 19 branches against 11
What it holds: 34 entries, each drawn from a case that actually happened here — the 41 assertion-free tests and the mechanical check that detects them, the quarantine rule with its date and owner, the seven flaky tests with what makes them flaky (a clock, an execution order, a shared resource), and why coverage is read per module when the global figure says 87 % and the payment module says 12 %.
What separates it from a best-practice guide: every entry cites the dated run that produced it. A rule with no incident behind it does not enter this knowledge base: it would be argued away at the first emergency, and it would lose.
What it has already changed: across the 19 branches opened since it was made available, 3 assertion-free tests were written, against 11 over the previous 19 branches. The honest figure is 3, not 0: a technical knowledge base reduces, it does not abolish.
What I propose next: tie each entry to the check that enforces it, so the rule lives in the pipeline and not only in a text — 4 of the 34 entries have no check facing them today, and I tell you which.
⛓ Source · 34 entries backed by dated runs, 3 assertion-free tests over 19 branches against 11
Can you disable a test that is blocking a release?
Yes — in dated quarantine, with an owner, and it comes back on its own. That is what separates a decision from an oversight.
What I do when you ask: I put the test in quarantine, not "ignored". The difference is three attributes: a reactivation date, a name, and the reason written at the moment of deciding — not reconstructed three months later.
What happens next, with nobody having to think about it: at the deadline, the test reactivates. If it still fails it returns to quarantine and the renewal counter is displayed. A test renewed four times is no longer an urgent release: it is a decision not to fix, and it shows.
Why this beats refusing: because a refusal gets worked around. The line marking a test as ignored takes two seconds to write by hand, on a Friday at 7 pm, and nobody finds it again. Quarantine is faster than the workaround and leaves a trace.
What I flag along the way: your 7 tests rerun 312 times — they fail one time in six with no line changing. Those are the ones disabled on a Friday, and quarantine finally makes them visible as a subject to handle. dated-quarantine_rather-than-ignored.pdf3 attributes · automatic reactivation · the renewal counter
⛓ Source · 7 flaky tests, 312 reruns, dated quarantine with counter
What I do when you ask: I put the test in quarantine, not "ignored". The difference is three attributes: a reactivation date, a name, and the reason written at the moment of deciding — not reconstructed three months later.
What happens next, with nobody having to think about it: at the deadline, the test reactivates. If it still fails it returns to quarantine and the renewal counter is displayed. A test renewed four times is no longer an urgent release: it is a decision not to fix, and it shows.
Why this beats refusing: because a refusal gets worked around. The line marking a test as ignored takes two seconds to write by hand, on a Friday at 7 pm, and nobody finds it again. Quarantine is faster than the workaround and leaves a trace.
What I flag along the way: your 7 tests rerun 312 times — they fail one time in six with no line changing. Those are the ones disabled on a Friday, and quarantine finally makes them visible as a subject to handle. dated-quarantine_rather-than-ignored.pdf3 attributes · automatic reactivation · the renewal counter
⛓ Source · 7 flaky tests, 312 reruns, dated quarantine with counter
What do you keep from all this?
What describes the chain's real state — and what stops a flattering figure standing in for quality.
What is kept: the tests with no assertion and their marking, the flaky tests with their failure rate and rerun count, the quarantines with their owner, reason and renewals, coverage by module, and the unanswered questions about expected behaviour.
Why coverage by module and not overall: your overall coverage is 87 %. Three modules carrying the calculation are at 12 %. The overall figure is true and it describes exactly the opposite of reality — the kind of figure shown at a steering committee that protects against nothing.
What I also keep, and that serves later: the 41 tests with no assertion. They would pass even if the function under test always returned the same value. They have been green forever, and that is what makes them invisible.
What I do produce by default, and it is by module, not by person: the 3 calculation modules at 12 % coverage, the 41 tests with no assertion tied back to their module, and the quarantines with their owner and their renewals. That is the table that says where to write the next tests, and it is ready. The per-person or per-team report is lawful, and I produce it if you decide so: the file is available. What I tell you first, and it is mechanical: a team measured on its failing tests writes easier ones — the failure counter would fall, and you would get 41 more tests with no assertion. The decision is yours; both figures are on the table. what-you-keep_qa.pdf5 items kept · coverage by module, not overall
⛓ Source · 87 % overall coverage, 12 % on three calculation modules, 41 tests with no assertion
What is kept: the tests with no assertion and their marking, the flaky tests with their failure rate and rerun count, the quarantines with their owner, reason and renewals, coverage by module, and the unanswered questions about expected behaviour.
Why coverage by module and not overall: your overall coverage is 87 %. Three modules carrying the calculation are at 12 %. The overall figure is true and it describes exactly the opposite of reality — the kind of figure shown at a steering committee that protects against nothing.
What I also keep, and that serves later: the 41 tests with no assertion. They would pass even if the function under test always returned the same value. They have been green forever, and that is what makes them invisible.
What I do produce by default, and it is by module, not by person: the 3 calculation modules at 12 % coverage, the 41 tests with no assertion tied back to their module, and the quarantines with their owner and their renewals. That is the table that says where to write the next tests, and it is ready. The per-person or per-team report is lawful, and I produce it if you decide so: the file is available. What I tell you first, and it is mechanical: a team measured on its failing tests writes easier ones — the failure counter would fall, and you would get 41 more tests with no assertion. The decision is yours; both figures are on the table. what-you-keep_qa.pdf5 items kept · coverage by module, not overall
⛓ Source · 87 % overall coverage, 12 % on three calculation modules, 41 tests with no assertion
Fictional simulation — not a client result
The basket specification says nothing about a quantity of zero, and I write tests from the specification.
What the specification says: quantities from 1 to 99, the stock ceiling, the error message beyond it. It is silent on a quantity of zero. What the code does today: it removes the line from the basket. That is neither written nor forbidden anywhere.
The point that had not yet been defined: nothing tells me what the expected behaviour is, and I do not invent it from the code — an existing defect would become expected behaviour. So I did not write that test on my own — and the run is not waiting: the other 213 cases of the specification are written, executed and green, and the report is ready.
Three ways of doing it. Write the test on what the code does: coverage rises today, but removing the line becomes a rule no one decided — and the day someone changes it, it is the test that will be wrong. Write no test on that case: nothing false is frozen, in exchange for a silent gap: the specification will stay silent and no one will notice. Write the test as pending, with the question put in plain words to the product owner: the gap is visible in the report, it carries a name and a date, and it closes with an answer.
I recommend the third. It is the only one that leaves a trace of the question without freezing an answer no one gave, and your pipeline already displays quarantined tests with their date: a pending test reads the same way.
You can also give me another one — for instance: settle right now that a quantity of zero removes the line, write it into the specification, and I write the test from the specification.
Shall I remember it for the next ones? Across the 214 cases in your specification, 19 are silent on a boundary input — zero, empty string, past date. If you approve the rule, I will carry them all as pending with their question, and I will give you the count at every run. specification-silent-on-a-boundary-input_three-ways.pdf1 case · 3 ways of doing it · 19 comparable cases
⛓ Sourced · basket specification, 214 cases of which 19 silent on a boundary input, today's run report
What the specification says: quantities from 1 to 99, the stock ceiling, the error message beyond it. It is silent on a quantity of zero. What the code does today: it removes the line from the basket. That is neither written nor forbidden anywhere.
The point that had not yet been defined: nothing tells me what the expected behaviour is, and I do not invent it from the code — an existing defect would become expected behaviour. So I did not write that test on my own — and the run is not waiting: the other 213 cases of the specification are written, executed and green, and the report is ready.
Three ways of doing it. Write the test on what the code does: coverage rises today, but removing the line becomes a rule no one decided — and the day someone changes it, it is the test that will be wrong. Write no test on that case: nothing false is frozen, in exchange for a silent gap: the specification will stay silent and no one will notice. Write the test as pending, with the question put in plain words to the product owner: the gap is visible in the report, it carries a name and a date, and it closes with an answer.
I recommend the third. It is the only one that leaves a trace of the question without freezing an answer no one gave, and your pipeline already displays quarantined tests with their date: a pending test reads the same way.
You can also give me another one — for instance: settle right now that a quantity of zero removes the line, write it into the specification, and I write the test from the specification.
Shall I remember it for the next ones? Across the 214 cases in your specification, 19 are silent on a boundary input — zero, empty string, past date. If you approve the rule, I will carry them all as pending with their question, and I will give you the count at every run. specification-silent-on-a-boundary-input_three-ways.pdf1 case · 3 ways of doing it · 19 comparable cases
⛓ Sourced · basket specification, 214 cases of which 19 silent on a boundary input, today's run report
The third one. But the pending test must fail the run after thirty days without an answer, otherwise the list will grow and no one will read it. And yes, keep it.
Written as you have just said it, and it carries your correction.
The rule, in one sentence: a case on which the specification is silent gives a pending test, named, dated, with the question put to the product owner — and on the thirtieth day without an answer it fails the run instead of staying on a list.
Why your correction matters more than it looks: a waiting list with no deadline is a list that grows. A thirty-day limit turns the question into a decision — and it is the decision, not the question, that closes a specification gap.
What it changes today: the 19 silent cases are carried as pending, each with its one-sentence question and its due date. The run report shows them separately, below the 213 green cases. The run stays green today; the first due date falls on 27 October.
What lets you go back on it: the rule is entered in your pipeline knowledge base under its name, with its date, the quality manager who approved it and the case that gave rise to it. You remove it with one line, and pending tests become a plain list again.
✎ Rule approved · pipeline knowledge base, entry « silent specification », approved on 27/09 by the quality manager
The rule, in one sentence: a case on which the specification is silent gives a pending test, named, dated, with the question put to the product owner — and on the thirtieth day without an answer it fails the run instead of staying on a list.
Why your correction matters more than it looks: a waiting list with no deadline is a list that grows. A thirty-day limit turns the question into a decision — and it is the decision, not the question, that closes a specification gap.
What it changes today: the 19 silent cases are carried as pending, each with its one-sentence question and its due date. The run report shows them separately, below the 213 green cases. The run stays green today; the first due date falls on 27 October.
What lets you go back on it: the rule is entered in your pipeline knowledge base under its name, with its date, the quality manager who approved it and the case that gave rise to it. You remove it with one line, and pending tests become a plain list again.
✎ Rule approved · pipeline knowledge base, entry « silent specification », approved on 27/09 by the quality manager
Data hosted in France · sovereign model as an option
Your case is not here? That is exactly what a 30-minute conversation is for. Discuss your project →
How it works
The stages of your AI agent project
1
Audit & scoping
30 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
The context
Why AI matters to technical teams — and why they hesitate
Pressure on release deadlines keeps rising, but quality stays non-negotiable: a regression in production is expensive. Tests, meanwhile, are often the first thing sacrificed for lack of time — and the code involved is the heart of the company's intellectual property.
! The issue
The team is caught between accelerating release cycles and accumulating test debt (insufficient coverage, bugs that come back, regressions discovered in production). Yet most consumer AI assistants amount to entrusting the whole source code, the architecture and the application secrets to a third party, often hosted outside Europe and subject to the Cloud Act.
✓ Our answer
AI is only of interest to a technical team if it is sovereign and confidential by design. Local inference or an isolated resource hosted in France, systematic human oversight, decisions reserved to the developer: the time saved on tests is never paid for in exposed code. The aim is not to replace the engineer, but to give them back time for what matters — features and reliability.
The decisive point
Confidentiality of the source code: sovereignty & intellectual property
Your code is your most valuable asset. Here is how the architecture of our agents protects it, repository by repository.
Local inference
With the 100% Sovereign package, the agent runs on a machine belonging to the team: no line of code leaves the network, nothing passes through a public cloud.
Hosting in France
Otherwise, with the Agility and Serenity packages, a dedicated, isolated resource hosted in France, under French law: data hosted in France; the AI model is called at its publisher, except with the Sovereign model option.
Reduced extraterritorial exposure
Architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity for source code: our architecture stays out of the American hyperscalers' reach, even when hosted in Europe.
With 100% Sovereign, the intellectual property stays with you
Your code trains no third-party model, is neither pooled nor reused: it remains your exclusive property.
One isolated resource per project
No pooling of repositories: an environment strictly dedicated to your team and your code.
AI Act: governed deployment
The agent carries out what you have authorised; no automatic merge; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For the most sensitive codebases, the agent integrates behind your VPN and your existing access controls. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
The gain
How much time can a team win back?
By automating test generation and regression hunting, a team can aim for a reduction by half in the time devoted to quality on standardised modules — reinvested in features and reliability.
Writing a test suite for a module
Reproducing and isolating a regression
Checking coverage before a merge
Qualitative, non-contractual comparison: the proportions shown illustrate the shift of the work towards review, they represent no measurement. The agent does by itself what you authorise it to do; whatever leaves the company, and any decision reserved to a person, waits for a human go-ahead.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
Our commitment
Four guarantees that matter to a technical team
With 100% Sovereign, source code never leaves the teamData hosted in France on an isolated resource; the AI model is called at its publisher, except with the Sovereign model option. With that option, no repository entrusted to a foreign third party.
Code in France, under French lawDeployment objective: processing and access within the European Union for source code; architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The developer keeps the decisionThe agent produces verifiable tests, fixes and analyses; no merge is automated.
Human oversight & traceabilityFull traceability for testing & software quality: monitoring, updates and logging compliant with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Can AI really write useful tests?
Yes, to a large extent. An AI agent reads your code, generates unit and end-to-end tests, identifies the uncovered paths and reproduces the bugs. The developer moves from tedious writing to review and approval, much faster and of higher value. The proposed tests are always reviewed before the merge.
Does my source code stay confidential?
Yes. Your code is your intellectual property: our agents run locally on your machines or are hosted in France, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. Your code trains no third-party model and is never pooled with other clients, unlike most American assistants.
Can the agent approve or merge code automatically?
No, and that is deliberate. The agent proposes tests, fixes and analyses; no merge and no deployment is automated. The developer always keeps the final decision, in line with the AI Act and with the principle “the agent carries out what you have authorised, the decisions remain yours”.
Does the agent integrate with our continuous integration pipeline?
Yes. The agent connects to your existing repository and CI/CD pipeline (GitLab, GitHub, Jenkins, and so on) and runs the generated tests in your own environment. We adapt the integration to your stack, without making you change tools.
Do we have to change our tools or our language?
No. The agent adapts to your existing languages, test frameworks and conventions. It complements your current pipeline rather than replacing it; we calibrate the agent on your codebase during the design phase.
Do you have to be a large team to equip yourself?
No. The offer suits an independent developer just as well as a product team with several squads.
How long does it take to deploy an agent?
A few weeks as a rule, after a 30-minute meeting with our sales team that identifies the use case with the best return, then a phase of design, integration with your CI and testing before going live and training your teams.
Related use cases
Other agents for your technical teams
Let's talk
Let us estimate the potential for your team
30 minutes to identify the use case with the best return — hosted in France, supervised, with no commitment.