Synthetic Industry

Vibe Engineering: evidence and method

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.

Inspect the public exampleSee the proposed workflow

This page separates an existing open-source demonstration from the process offered for new client work. It is not a client case study or proof of production delivery.

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; this was not a customer commission.

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.

Inspect the before/after codeRead checks and limitations

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 supports a narrow claim: our sample workflow found and repaired a behaviour change beyond the test suite. It does not establish client acceptance, hosted deployment, monthly throughput or production reliability.

From a request to something you can try.

The proposed client workflow, not a report of a completed engagement. 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. These are proposed records, not published performance statistics. We have no verified client-lane delivery-time, acceptance or production-defect figures to report here.

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

Want this discipline behind your product?

The proposed Vibe Engineering Lane is US$10,000 per month for a bounded plan on one product. Read the capacity, access and acceptance limits, then tell us what you would want working first.

Read the lane offerAsk about the evidence by email

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