Every consultancy says it uses AI. Here is the machinery.
The claim is now worthless on its own — everyone makes it, and almost nobody will show you what it means inside their repository. So this page describes what is actually committed alongside the code, and why each piece exists.
It also describes the half that no repository holds. Tooling decides how fast the work goes. It does not decide whether the work was the right work, and that judgement is the part you are actually hiring.
Why this is a selling point rather than a curiosity
The usual objection to hiring one person is the bus factor, and it is a fair objection. The usual answer — “I document things” — is not much of one, because documentation written for humans rots at exactly the rate nobody notices.
What changes the calculus is that the operating context now has to be machine-readable to be useful to me at all. The brief that tells an agent what this system is, what has already been decided and what it must never do is the same brief that tells a human the same things. It stays current because the work stops being correct when it drifts.
So the artifact you get is not just working software. It is working software with its own operating instructions attached, in a form the next engineer can use whether or not that engineer is me.
What is actually in the repo
- A committed project brief
- Every repository carries a document that states the decisions already made — architecture, conventions, the things that must not be re-litigated. It is the first thing an agent reads and the first thing a new contributor reads, which is not a coincidence.
- Project-local skills
- The rules a new engineer would otherwise learn by breaking something, written down and scoped to the situations where they apply: how to write a case study without publishing a client's intellectual property, what the type system is, which colour tokens exist and why. They load when the work touches that area.
- Architecture diagrams checked by a script
- Diagrams go stale silently, which makes them worse than no diagram at all. Mine are validated against the source by a checker, so a diagram that no longer matches the code fails rather than quietly misleading whoever reads it next.
- Verification before the claim
- Nothing is reported as working until the command has been run and the output read. That sounds obvious, and it is the single discipline most often skipped — by people and by agents.
This site is itself an example. The positioning, the confidentiality rules per client, the approved factual claims and the design tokens are all committed here, and the pages were written against them.
The rules I hold it to
- The context lives in the repository
- Not in my head, and not in a thread. If I am unavailable, what I know about your system is written down where the next person — or the next agent — can act on it.
- The model does not get the last word
- Generated code is reviewed the way any pull request is reviewed, against a spec that existed first. Speed comes from removing the parts of the job that were never thinking, not from skipping the thinking.
- You can see all of it
- The brief, the rules and the diagrams ship in your repository, not mine. If the engagement ends, the operating instructions stay with the code.
The part that is not in the repository
The first thing I ask is not what your stack is. It is what breaks when this does not work, and who gets the phone call. Most technical decisions turn out to be someone's Tuesday — the person who has to explain the outage, the one re-keying data by hand because the integration drops records, the founder who cannot ship the thing they promised. Architecture that ignores those people is usually correct and still wrong.
I have also been on the other side of the invoice. I have co-founded, built and run products of my own, which means I have made the decision you are about to make with my own money on the far side of it. That changes what I flag early: cost that will compound, complexity you will have to staff for, the feature that is cheaper not to build.
Something I got wrong, since it explains the rest
On a rescue engagement I inherited a build a client had already invested heavily in, and agreed to work inside it because that was the ask. It was the wrong call. The foundation could not carry what the business actually needed, and no amount of good code on top was going to change that. I was also asked to build the domain modules first and wire authorization across them afterwards — which does not work, because authorization spans everything and therefore constrains everything. It forced a redesign, the timeline stretched, and the project was eventually paused.
I should have said so at the start, plainly, and I did not. That is why the first week of an engagement now includes the conversation nobody enjoys: whether the thing you have will get you where you are going, and what it costs if it will not. I would rather lose the work than take it on terms I already know will fail.
What it does not mean
It does not mean your system is designed by a model. Architecture decisions are mine, and I will defend them to you in plain sentences. It does not mean estimates collapse to nothing, because the constraint on most projects was never typing speed. And it does not mean your code or your data is fed to anyone: what tooling is used, and on what, is a conversation we have before the engagement starts rather than a surprise afterwards.
What it does mean is that the unglamorous, mechanical parts of delivery — the migrations, the test scaffolding, the documentation that would otherwise never be written — stop being the reason a project slips.
Want to see it against your system?
A fixed-scope audit is the cheapest way to find out what you have, and it produces the first version of exactly these artifacts for your codebase.