What AI-driven development means here.
Agents write, test and review the code. People set the rules, read the previews and approve the releases. That division is the whole method. Everything else on this page is the discipline that makes it safe: written rules the agents read before they start, one branch per change, checks that run before anything ships, a person at the gate, and a record of every change. It is how this website is built, how the system that runs our marketing is built, and how we configure the platforms our solutions run on.
The loop: rules, change, checks, gate, record.
- Rules. Every project carries its standing rules in one file, in plain words, with the date and the request that produced each one. The agents read it first. A rule that is not written is a rule that will be broken.
- Change. An agent pulls the main line, branches for one change and makes it: the code, the data, the test for the new behaviour. It never commits to the main line, never rewrites history, never pushes over someone else’s work. Two people and several agents work the same code at once this way.
- Checks. The unit tests, the build and a set of check scripts that sweep the rendered product. A finding stops the change. The check’s summary line, verbatim, goes into the pull request.
- Gate. An agent reviews the diff against the rules and the record; a preview of the change goes to a named person, who answers with one digit. Nothing reaches production without that answer, and the release is made from the main line, never from a branch.
- Record. A dated note beside the code: the request in the requester’s own words, what changed and where, the checks verbatim, the screenshots, what was left undone and why. Six months later the why is still there.
What the agents do, and what they do not.
They read the codebase and the rules, propose a design, write the code and the tests, run the checks, read the results and fix what they find, draft the record and open the pull request. They review each other’s work against the same rules. They do not decide what the product should be, they do not merge, and they do not release. Those are a person’s decisions, and the method keeps them so: a credential an agent can use is scoped to what it needs, a release command runs only from an approved state, and the approval itself is a message from a named person that the record keeps.
The checks, and how a defect becomes one.
The checks are code, kept beside the product, and they sweep what a person would otherwise inspect by eye: the layout at nine viewport sizes, from a phone to a wide desktop; the copy rules (every heading ends with a period, no placeholder text, no vendor named where the page is not about that vendor); the search metadata on every route; colour contrast on every band; every related link answering; the share image of every page. Each check prints one summary line and exits with a code the pipeline reads.
When a person finds a defect the checks missed, the fix ships with a new probe that would have caught it. An eyebrow that wrapped on a wide screen became a rule that no eyebrow wraps from 700 pixels up. A hero whose figure sat below its heading on a phone became a rule that the heading comes first under 700 pixels. A menu whose lead group sat on the right became a rule that the group we want read first is leftmost. The checks are the memory of every defect a person has had to find, and the reason each is found only once.
Configuration is code, under the same rules.
A CMS row, a CRM field, a journey in a marketing platform, a scheduled job: each is production as much as a line of code, because a customer, a prospect or a colleague sees what it does. So each is changed the same way. Read the current state before writing, in the same turn. Write once, through the platform’s own interface, never by hand in a screen when an interface exists. Read it back and compare. Log the change with who asked and who approved. A change to a shared surface, a template, a routing rule, a gateway, is presumed to reach every page or every run it touches until the after-check proves otherwise. “Backwards compatible” is a result of that check, never an opinion.
What it changes for a client.
Speed, first: an agent does not wait for a sprint to start, and a change that is small stays small. The capability page on agentic solution development carries the measured figures for our own build, with the method beside them. Then confidence: the record and the checks mean a client can read why every line exists and see that it was tested before it reached them. Then portability: the rules, the checks and the records are files in the client’s own repository, so another team, or another set of agents, can pick the work up without a handover meeting.
What a client gets.
- A repository with the code, the data, the tests and the check scripts, and the standing rules in one file at its root.
- A record for every change, in plain words, with the request, the diff’s reach, the checks verbatim and the screenshots.
- A release flow in which a named person approves every production change from a preview, and the release runs from the main line only.
- The same flow for the configuration of the platforms the software runs on, with a read-back on every write.
- No credential value in any file, message or log; secrets read by name from an encrypted store at run time.
Where it is not the right choice.
A one-off script nobody will run twice does not need the record. A prototype meant to be thrown away does not need the gate. We will say so, build it the quick way, and label it so that nobody mistakes it for the product.
