Don’t take the code’s word for it.

A change can compile, pass its tests and still behave differently. The engineering work includes finding that difference, explaining it and giving you something you can inspect.

This page shows an open-source demonstration and the process behind the lane.

A small example. An important distinction.

Published sample: a Rails 7.2 to 8.0 upgrade on our own copy of the open-source Tracks application. We are not affiliated with Tracks.

Passing tests did not prove unchanged behaviour.

The existing suite ran 647 tests with no failures or errors before and after the completed change, with two tests skipped by the project. During the upgrade it caught a stats-page crash, which was fixed. Runtime checks found a separate time-handling change.

A time at 12:00, offset +05:00, converted inside the app

Rails 7.2: 07:00 +0000

Rails 8.0, before the fix: 12:00 +0500

Both represent the same instant, but the application's output changed. We restored the previous behaviour and checked the result.

What review found, and what it did not

A second AI model reviewed the change and raised the loss of a development translation editor. Runtime checks, not that diff review, revealed the time behaviour and the changed fresh-database setup path.

What remains unproved

Tests used SQLite, not MySQL or PostgreSQL. The effect of the changed fresh-database path on those other databases was not tested. Browser coverage was limited to pages loading; email, uploads and a real production database were not checked.

This example shows one thing: our sample workflow found and repaired a behaviour change beyond the test suite.

From a request to something you can try.

The client workflow. The exact environment, checks and delivery arrangements are agreed for your product.

  1. Capture the result you want.

    A feature request, reproducible bug or maintenance objective becomes a short acceptance brief. We resolve questions that materially affect the result instead of silently guessing.

  2. Gather context and agree a plan.

    Inspect the permitted repository, documentation and existing behaviour. Identify conventions, dependencies, data boundaries and tests. Agree a small enough scope to demonstrate and accept.

  3. Implement away from production.

    Agents make changes in an isolated working environment. Where feasible and authorised, a temporary application environment uses representative synthetic data, with live email, payments and other external side effects disabled.

  4. Run it, then challenge it.

    Run relevant tests and exercise the affected behaviour in the application. For UI changes, inspect desktop and mobile flows where applicable. Separate review looks for mistakes; defects found are repaired and rechecked. We state anything that could not be verified.

  5. Show the outcome with its evidence.

    Present a working preview or runnable backend example, a plain-English walkthrough, checks and known limitations. Capture screenshots where helpful and video when agreed. You can try the result and ask for corrections.

  6. Accept, then release within authority.

    Record your acceptance against the brief. Deliver the agreed code and handover. Deployment, production data and account actions remain separate permissions; a preview is never evidence that a live release happened.

Useful evidence is more than a commit count.

For an agreed engagement, the delivery record should show what was requested, when a usable preview became available, which checks ran, what review caught, what remained uncertain and whether the customer accepted it.

We would also record required human intervention, review cycles and any known post-release defects.

No employer code, private tickets, confidential screenshots or unauthorised aggregate figures are used on this page.

Want this discipline behind your product?

The Agentic Engineering Lane is $10,000/month for a full-time AI engineer on one product. Read how the lane works, then tell us what you would want working first.

Enquiry only. Please send no code, customer data, passwords or account invites. You can also write to hello@syntheticindustry.ai.