How we actually work.
Not a vague promise about "leveraging AI." The real mechanics — the rule-set behind it, and where a human has to be the one holding the pen.
Mr Wright's Rules
Eight software engineering principles, condensing forty years of professional practice — written down long before AI tooling existed, and just as true now. They're not internal-only; the whole thing is public.
- 01
There are no shortcuts
Software development creates technical debt the way trees create oxygen — unavoidable, but reducible through good professional practice.
- 02
All code is first-class code
If code fails to convey a technical solution to other people's minds, it is poor and potentially dangerous code — test code included.
- 03
Code for other people, not just for the solution
Say what your code is going to do, up front. Programming without intent leaves your source files as just a stream of consciousness.
- 04
Avoid stream-of-consciousness programming
Reading such code is like being transported into someone else's dream — boundary conditions unhandled, failure modes unconsidered.
- 05
Security is your responsibility
Security is the primary non-functional requirement. Built into the pipeline, not bolted on afterwards.
- 06
Always test first
Testing is nearly impossible to reverse-engineer well. Write it first, so it's always in place, protecting the code, the application and the customer.
- 07
Test functionality, not implementation
Test the contract code makes with its caller, not its internal mechanics — so the implementation is free to change without ever touching the test suite.
- 08
Test business rules, aim for 100% coverage
One source of truth for the business rules should drive the tests. Full coverage with a green build buys the confidence to refactor, or rewrite, and trust it still works.
The rules don't get less true. They redistribute.
A model writing the code doesn't make sound engineering principles expire. It changes exactly where each one bites — and understanding that redistribution is the entire difference between "AI-assisted" meaning faster, and "AI-assisted" meaning riskier.
Rules 6, 7 and 8 become the mechanism of control
When a person wrote every line, "I understand this because I wrote it" was the safety net. That net doesn't exist with AI-generated code — rereading it carefully afterwards is a poor substitute for having actually reasoned through it as it was typed. What replaces that net is the test suite: written first, testing functionality rather than implementation, aiming for full coverage of the real business rules. Do that, and the tests become the actual interface being programmed against — the AI becomes an implementation detail underneath them, free to be regenerated or refactored without anyone needing to re-earn trust in it from scratch.
Rules 1–4 shift from the code to the prompt and the review
A vague, stream-of-consciousness prompt produces exactly the failure mode Rule 4 describes — except now there's no developer's own memory to interrogate afterwards when it goes wrong, just an opaque model that can't tell you what it "meant," because it didn't mean anything. Programming with intent now has to happen mostly before the AI is ever prompted, in the spec, and afterwards, in the review.
Confident and correct are not the same thing
AI output reads as clean and confident even when it's wrong. Rule 2 assumed sloppy code looks sloppy — a visible cue to slow down. That assumption breaks with AI: fluent, well-formatted, plausible-looking code invites a skim-and-approve instinct exactly when it needs the opposite. We don't skim.
You own it, even if you didn't type it
“The AI wrote it” can't become a valid excuse, any more than “the framework did it” ever was. Every line that ships stands behind our name.
We verify what the AI asserts
Models hallucinate plausible-sounding package names and config flags with total confidence. Every dependency is checked to actually exist and be the genuine article before it's trusted.
What this looked like on a real change
Kington Parishes' noticeboard automatically retires an old notice and reveals its replacement once a date passes — custom, date-driven logic with no CMS behind it. It had never been tested. Here's exactly what "always test first" meant in practice, applied after the fact to something that already existed:
Spec it precisely
Before which cards should hide, appear, and when — including what "nothing has expired yet" should look like.
Write the test
A mocked clock, set to three different dates, checking the right cards appear and disappear on each.
Prove it's real
Deliberately broke the logic, confirmed the new test caught it and failed loudly — then reverted.
Confirm, then ship
Reverted change re-tested green, committed, tagged, and logged in the public changelog.
That's not a special case — it's what happens by default. Read the actual test →
Want to see it applied to your project?
Tell us what you're building. We'll show you honestly what the process would look like.
Get in touch