How we work
Forty years of engineering discipline. Modern tools, used responsibly.
This page covers the rules we build by, exactly where AI fits in and where a person stays in charge, and the evidence from a live site that it works.
Kington Parishes, as of 26 Sep 2026.
The starting point
Mr Wright's Rules
Eight software engineering principles, condensed from forty years of professional practice and written down long before AI tools existed. They're just as true now, and they're public.
- There are no shortcutsSoftware creates technical debt the way trees create oxygen. It's unavoidable, but good practice keeps it small.
- All code is first-class codeCode that fails to explain itself to other people is poor, and potentially dangerous. Test code included.
- Code for other people, not just for the solutionSay what the code is going to do, up front.
- Avoid stream-of-consciousness programmingCode written without intent leaves boundary conditions unhandled and failure modes unconsidered.
- Security is your responsibilityThe primary non-functional requirement. Built into the pipeline, not bolted on afterwards.
- Always test firstGood tests are nearly impossible to reverse-engineer later. Write them first, so they're always there.
- Test functionality, not implementationTest the contract with the caller, so the code underneath is free to change.
- Test business rules, aim for 100% coverageFull coverage and a green build buy the confidence to refactor, or rewrite, and trust it still works.
What changes with AI
The rules don't get less true. They move.
An AI writing the code doesn't make good engineering expire. It changes where each principle bites, and understanding that is the difference between AI making a site faster to build and AI making it riskier.
Tests become the control
"I understand it because I wrote it" no longer applies. Tests written first, against the real business rules, become the thing the AI is held to. The code underneath can be regenerated without re-earning trust from scratch.
Intent moves into the spec
A vague prompt produces stream-of-consciousness code, with nobody's memory to interrogate afterwards. So the thinking happens before the AI is prompted, in a written spec, and after, in review.
Confident isn't correct
AI output reads as clean and assured even when it's wrong. Sloppy code used to look sloppy. Now fluent code invites a skim, exactly when it needs a careful read. We don't skim.
You own it, whoever typed it
"The AI wrote it" is no more an excuse than "the framework did it" ever was. Every line that ships stands behind our name.
Verify what it asserts
Models invent plausible package names and config flags with total confidence. Every dependency is checked to exist, and to be the genuine article, before it's trusted.
Standing instructions
Every project has a written rule-book the AI must follow on every change: run the tests, audit dependencies, calculate contrast, log the release. The rules travel with the code.
In practice
Every change, the same way.
We use GitHub for every project and Claude Code to do most of the typing. The workflow around them is what makes that safe.
The life of one change
- Spec
- What should change and how we'll know it worked, written by a person
- Test
- A test that fails until the change is right
- Code
- Claude Code writes it, following the project's standing instructions
- Check
- The full suite, an accessibility scan of every page and a dependency audit
- Review
- A person reads the diff before it merges
- Record
- A commit, a tagged build number and an entry in the public changelog
The evidence.
Kington Parishes · as of 26 Sep 2026
466
automated tests before every change
151
tagged releases since 31 August
36
pages from one shared engine
0
accessibility violations, every page
0
known high or critical vulnerabilities
What that buys a live site.
Checked automatically on every change, not promised once at launch and left to drift.
Same-day changes
A wording change, a new page or a whole feature goes out the day it's asked for, with no monthly change quota.
Real browser tests
374 Playwright tests drive a real browser through search, forms, keyboard navigation and the mobile menu, plus 92 fast logic tests.
Tagged, every time
Each release is tagged against the exact commit that shipped it, for a real audit trail rather than a claim.
Dependency audit on every push
A push is blocked outright if a high or critical vulnerability turns up.
Addresses bots can't scrape
Email addresses are encoded so the simple harvesters behind most spam lists can't read them.
Hardened file serving
Tested against path-traversal attempts, including encoded and Windows-style tricks, rather than trusted to behave.
Zero accessibility violations
Every page passes a full axe-core scan, the engine behind most enterprise accessibility audits, on every change.
Contrast that's calculated
Every text and background pairing clears WCAG AA by real relative-luminance calculation, not by eye.
Built to be found
Structured data per content type, link previews that look right when shared, and a sitemap regenerated on every build.
Instant site search
A search box that finds the right section of the right page as you type, with no external service.
Enter it once
People, events and prices each live in one place, and appear everywhere they belong.
Self-tidying content
Old notices come down and newsletters move to the archive on their own, when their date passes.
A real change
What "always test first" looked like.
Kington Parishes' noticeboard retires an old notice and reveals its replacement once a date passes. That logic had never been tested, so we added a test, after the fact.
Spec it precisely
Which cards hide and 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 on each.
Prove it's real
Break the logic on purpose, confirm the test fails loudly, then revert.
Confirm, then ship
Green again, committed, tagged and logged in the public changelog.
This site's own build log.
The same discipline applies here. These are the latest entries, pulled from the changelog on every build.
2026.09.27.007Correct which Cloudflare setting injects the blocked inline script: it is JavaScript detections…
2026.09.27.006Pin every text file to Unix line endings with a .gitattributes file (ported from kington-parishes),…
2026.09.27.005Document that Cloudflare's bot-detection feature injects an inline script which the site's security…
2026.09.27.004Confirm the remaining prices, so none are placeholders any more: Sales & stock from £2,500 and…
2026.09.27.003Confirm prices: business Starter from £450 and Business from £1,200, and a personal sales listing…
Want to see it applied to your project?
Tell us what you're building, and we'll show you what the process would look like.