On this page
Start here: this is not a launchBusiness viewWhat you may and may not sayTechnical view (enough to keep you accurate)If a customer asksFor Marketing
Start here: this is not a launch
There is nothing to announce. PR #241 changes one GitHub Actions workflow file. No screen in the clinic web app, the patient portal, or the mobile app is different. No clinic will notice anything. There is no release note, no in-product banner, no changelog entry for customers.
If this page reached you because it was auto-generated for every PR, the correct action is: no action. The rest of this page exists for the one case where this is useful to you — when someone outside the company asks how Dentolize tests its software.
Business view
What actually changed
Dentolize runs an AI agent that reviews every pull request's preview environment and tests it in a real browser. This PR restructured that agent from one unattended pipeline into four supervised steps, with a human reading and correcting the AI's reasoning between each.
In plain terms: an engineer can now catch the AI misunderstanding a change before the AI acts on that misunderstanding.
Why this is a quality story, not a product story
The interesting claim is not "we use AI". Every software company says that in 2026, and the phrase carries no information. The interesting claim is the opposite one:
We use AI in our QA process, and we deliberately built checkpoints where a human corrects it before it does anything consequential.
That is a discipline story. It plays well precisely because it is unfashionable — it concedes that the AI is often wrong and describes the process built around that fact. In a market where healthcare buyers are nervous about AI touching their systems, "we don't trust it unsupervised either" is a stronger position than "our AI is very advanced."
Where this legitimately belongs
Not in a product announcement. Possible homes, in order of fit:
- Engineering blog / careers content. An honest post about building
human-in-the-loop AI tooling — the review-then-correct pattern, the failure modes found, what was kept manual and why. This is genuinely good developer recruiting material and costs nothing in claims.
- Security & quality questionnaires. Enterprise and hospital-group buyers
ask "describe your QA process." This is a concrete, verifiable answer. See For Sales for the wording.
- Internal comms. Explaining to the wider company why the engineering team
is investing in QA infrastructure.
What you may and may not say
Safe to say
- "Every pull request gets an automated preview environment that is reviewed and
browser-tested before merge."
- "Our AI-assisted QA process has explicit human review checkpoints — an
engineer reads and corrects the AI's analysis before any tests run and before any code is changed."
- "Test results are recorded as tracked issues, one per user scenario, with the
evidence retained."
Each of these is supported by the code: .github/workflows/sandbox-qa.yml:60-82 (fetching human edits), :124-140 (the editable comments), :172-207 (one issue per story), :241-250 (retained artifacts).
Do not say
| Don't | Why |
|---|---|
| "New feature available to customers" | It is unreleased and not customer-facing. Nothing ships to a clinic. |
| "AI automatically fixes bugs before they reach you" | fix is opt-in, human-dispatched, and its commits are code-reviewed like anyone else's. |
| "Fully automated QA" | The entire point of the change is that it is not fully automated. Saying this inverts the story. |
| "AI-verified" / "AI-certified" | These imply an assurance standard that does not exist. |
| "Every change is tested by AI" | The workflow is dispatched manually, per branch, per action (:24). It is not automatic on every PR. |
| Any percentage, coverage figure, or defect-reduction number | None exists. Don't invent one. |
That last row matters most. There is no measured before/after in this PR. If a number is needed for a piece of content, it has to be produced first.
The accuracy trap
The natural marketing instinct is "our AI finds bugs automatically". The workflow is manually dispatched — someone picks a branch and clicks Run (.github/workflows/sandbox-qa.yml:23-24). Describing it as automatic on every change is straightforwardly false and would be caught by any technically literate buyer reading a security questionnaire response.
Technical view (enough to keep you accurate)
You don't need this to do your job, but these are the facts behind the claims above, so you can defend them if challenged.
It's one file. .github/workflows/sandbox-qa.yml, 250 lines, +70/−46 in this PR. It orchestrates; the agent itself runs elsewhere.
Four actions, two edit gates. review → (human edits) → plan → (human edits) → test → fix. The edits are made by editing a GitHub comment; the next action reads the comment's current body (.github/workflows/sandbox-qa.yml:76-82). The invitation is literally printed in the comment header: "AI — edit freely; plan builds on your edits" (:132).
Only two of the five actions can change code. review, plan, and test create comments and issues only. fix and full-auto push commits to the branch, which are then reviewed by a person like any other commit (:50-53).
The results are auditable. Each tested scenario becomes a GitHub issue with its outcome (:191-200); the agent's full log and raw output are attached to the run for 14 days (:241-250).
It is manually triggered. workflow_dispatch only — no push or PR trigger (:23-24). This is the fact most likely to make a claim inaccurate.
If a customer asks
They almost certainly won't — but if a technically curious buyer or a prospect's security team asks how Dentolize tests changes, hand it to Sales with For Sales, which has the vetted wording and the objection handling. Don't improvise on this one; the honest version is already the strong version.