Fifty years of the hard way. Out of habit.

Building UnClick taught us how much work surrounds a small software change. Files. Builds. Reviews. Waiting to find out what broke. The change stayed small. The work around it didn't. So we flipped it. UnStack. Rules first. Code second. You define what must be true, with examples the machine can check. AI builds the code. The engine checks it and runs the version you commit. A lesson can become a rule for the next change.

Three steps around the rules

  • You write the rules: Say what the app must do in plain English. Pair each requirement with a worked example and the result you expect.
  • An AI builds the app to match: AI proposes code to meet the rules. You can inspect the code and preview the change. If a check fails, the code or the requirement needs attention.
  • Check, review and commit: The normal commit path reruns the required checks before selecting the running version. Further checks can flag a problem for review. Undo is available, subject to data checks; it cannot unsend an email.

Measured, with the caveats left in

  • Rebuilt from the rules alone: In the 5 September experiments, nine rebuilds from stored rules passed their checks on the first attempt. Comparing the resulting apps exposed behaviour the rules had not specified. Passing checks did not make the rebuilt apps identical. The early roster failure was later traced partly to missing test setup; on 6 September, a repaired harness and clearer rules produced a passing rebuild.
  • Checking the checks: The jobs-board v11 mutation test recorded a score of 72% on 8 September. It deliberately changed the code to see whether the checks noticed. It caught 55 changes and missed 21. That measures this test sample, not the percentage of the app that is correct.
  • Held under load: The 6 September test used sixteen writers making fifty writes each, with zero recorded errors. This was a controlled test. It does not establish performance for every app, data size or customer workload. The jobs-board production takeover remains unproven.

Time is the thing you get back

  • Planning estimates, not measured savings: The estimates of 500 to 900 hours versus 100 to 150 hours concern work around the code for a project the size of UnClick, assuming about 500 changes. They are not measured whole-project savings or a promised speed-up. A controlled comparison is still needed.

Still to prove or finish

  • Jobs-board pilot: The engine handles comparison traffic; the existing service still serves users. A production takeover, complete historical rule evidence, access and retry checks, and independent measurements of whole-project savings remain to be proved or finished.

Open source and install

UnClick is an MCP server you can install in one step and use from any MCP-compatible client.