Case · AI coding
My company’s IT is run by a coding agent.
This website, its database, its hosting and the company’s documentation are run by a coding agent working inside rules I wrote. The repository is public, so what this page says can be checked there.
11
pull requests merged to production on launch day, 30 September 2026. Each had a passing preview build first.
13
wiki articles written the same day, alongside the code: what exists, what was decided and why.
28 min
when the domain did not resolve that day, after a DNS move failed. Described below, with the rule it led to.
What the agent is given
Nothing here depends on a special model. It depends on four things in the repository.
Project instructions
One file the agent reads at the start of every session: how the code is organised, where the copy lives, the fixed names of the offers and how I write. It includes the rule that no fact, number or title may be invented.
A company wiki
What exists, how it is set up, what was decided and why, and what is still open. Sources are saved first and never edited; the articles are compiled from them. The agent reads the wiki before acting and updates it in the same piece of work.
Connections
Command-line access to the code host, the hosting provider and the database, linked to this project only. The permissions that govern my client work are kept apart and stay untouched.
Checks that can fail
Every pull request gets a production build and a preview deployment. A script checks the wiki and fails the pull request on a broken link, a missing source or a stale index.
Who decides what
The line is written down in the repository, and I am the only one who moves it.
The agent, on its own
- Code, copy and design changes to the site
- Database migrations
- Domain, environment and deploy commands at the hosting provider
- The whole pull request: branch, checks, merge, and verifying production afterwards
- Keeping the wiki current
Needs me
- Accounts the agent cannot reach: domain registrar, email, payment
- Secrets. I add them myself; the agent knows their names, never their values
- Anything destructive, such as wiping data or deleting a service, every time
- Decisions about money, clients and what the company sells
- Any new fact about me or my clients on the site
An automatic safety check blocks the agent from reading credentials and from editing its own permissions, even when asked to in chat.
I do not review before the merge here. It is my own company and the risk is mine. In a team that line belongs somewhere else, and deciding where is part of the setup.
How a change reaches production
The same six steps every time, whether the change is one sentence or a new part of the site.
- 01
I ask
In plain language, the way I would ask a colleague.
- 02
It reads
The project instructions and the wiki pages for the area it is about to touch.
- 03
It builds
On a branch, then opens a pull request that says what changed and why.
- 04
Checks run
Production build, preview deployment and the wiki check. The agent merges only when they pass.
- 05
It merges
Production deploys in about a minute.
- 06
It verifies
It checks the live site, then records what changed in the wiki.
Launch day, 30 September 2026
Every pull request merged that day, in Copenhagen time. Each line links to the change itself.
What went wrong
On launch day we moved the domain’s name servers to the hosting provider. The provider never created a zone for the domain, so from 15:59 to 16:27 nothing resolved for anyone without a cached answer. That included incoming email, which was delayed, not lost. We switched back.
The agent had logged what each name server answered while it happened. The same day that log became a runbook, with one step that would have caught the problem: ask the new provider’s name servers directly before switching, and stop if the answer is empty or refused.
Later that afternoon the site looked down from my own network while it was fine everywhere else. A resolver had cached an empty answer during the repair. That became a second entry: check from outside before changing anything.
Things go wrong with or without an agent. What this setup adds is that the lesson is written down the same day and read before the next change.
Four lines from the repository
Copied as written.
No hype and no invented facts, clients, numbers or job titles; leave things out rather than guess. Every figure comes from real work and says whether it was measured in production or tested on historical data.Held back: an AI coding FAQ about safety and payoff, because it would state new claims about Mathias's methods in his voice.Stop before `main` only when Mathias has to do something specific first, and say what.Query the new provider's nameserver directly and compare with the old one, record by record. A "refused" answer or an empty answer means stop.The same parts, in your codebase
This is what I set up for a development team: instructions the agent reads every time, a written line between what it may do alone and what needs a person, checks that can fail a pull request, and a place where decisions and incidents are recorded. Where the line sits depends on your systems and your risk.
Tell me what you need.
Three lines is enough. I reply within one working day with how I’d approach it and what it would take.
- No cost and no obligation
- A straight answer on whether I can help
- A price before any work starts