How we build with AI

What it gets you

Work that used to take weeks is now often running within days. The most important thing about that is not the speed, but what suddenly becomes possible at all: an internal tool for a single department, an integration a handful of people use, a version of a system that is finally accessible. That kind of work always used to die on the business case.

Our c-clients are the proof of it. Three systems that in practice require a mouse and a screen, reopened for those who work with a screen reader or braille display. As a separate project it could never have added up — this way it did.

What the machine does, and what we do

The AI writes the lion's share of the code. We set the direction, the architecture, the taste and when something is done — and we read what comes out. Nothing goes to production because a model says it is right; it goes to production because we have reviewed it and the checks are green.

So you are not buying AI. You are buying working software, with us as your point of contact. Who typed it changes nothing about who stands behind it.

The rules come first, not last

A model left free to associate produces surprises that are no use to you. So every assignment begins with the same written house rules — not as a good intention, but as an instruction the AI is given literally:

• Never make anything up. What has not been checked is not written down as fact — not in code, not in documentation, not to you.
• Accessibility is the starting point, not an extra round: semantic HTML, usable with keyboard and screen reader, readable without JavaScript.
• Git is the source. Work begins on a separate branch and only reaches production through the pipeline — never a quick change on the server itself.
• Fit what is already there: the same style, the same patterns, no extra library without reason.
• Never quietly throw anything away. What runs stays until it is shown to be no longer needed.

Those rules are not theory: they are on paper, they apply to every session, and they grew out of mistakes we did not want to make twice.

Not one model, but a team with roles

We do not let one model do everything. We work with a fixed set of roles, each with its own task and its own view, and bring them in where the work calls for it:

• An architect who thinks first and makes a plan, before there is a single line of code.
• A builder who carries out that plan in the style of the code already there.
• A critic who holds the work up to the light and demands proof — separating what is shown from what is assumed.
• A tester and a security reviewer who check what the code really does, not what it should do.
• A designer for rhythm, typography and how something feels.

That way several quality passes go over the same work, each with a different question: is the plan sound, is the execution sound, is the evidence sound, is it secure, does it feel right. That is exactly what matters, because the classic risk of AI code is not that it does not work — it is an answer that sounds convincing and is wrong. One model checking its own work does not find that.

Everything through git, everything through the pipeline

All our work lives in git — the AI's too. Every change is its own branch with a readable description of the why, is reviewed, and only reaches main once the checks are green. What is live is therefore always traceable to one change, and reversible in one step.

The pipeline does the rolling out, not a human with a laptop: the server pulls the new version from git itself. Nobody copies files to production, so nothing can be live that is not in git.

That same pipeline is where quality assurance belongs. On every change the same series of checks runs, and only once they are all green can anything go live:

• A WCAG rule scan on every page, in both the light and the dark theme.
• A virtual screen reader that walks the reading order, the heading structure and the labels of form fields on every page.
• Automated tests of structure and behaviour in a real browser — including the check that everything also stays readable without JavaScript.
• Gates that stop the release the moment a key or an internal address ends up in the code.

This site is built with it too: the same branches, the same pipeline, the same gates. What you read here is therefore not a promise about how we would like to do it.

Where the AI stops

An automated check is not experience. Our checks catch a lot, but they do not replace someone who works with a screen reader every day and feels within ten seconds that a screen is off. We seek that testing from people; where we do not yet have it for something, we say so rather than leave it out.

The same goes for the choices that really matter: what you actually need, what it is worth, and what we deliberately do not build. There is no model for that. That is the conversation.

And yes — it is also simply fun

Things come out that we had not thought of in advance, and the threshold to try something has become low. You benefit from that: testing an idea no longer costs a quarter. But it is also why, alongside accessible system clients, our work page carries a variant-sudoku generator, a mindmap app and two word games.

Curiosity is not a side issue. What we learn while playing comes back in the work where it has to be serious.

This site is itself work in progress

What you see here is not a finished product but work in progress: we are still building it while you read, exactly as described above — in small changes, each through the same checks. Pages are added, texts get sharper, and what can be better changes.

We would rather tell you that than pretend everything is already done. If you see something that is wrong or could be better, we welcome it.

Curious what this means for your project?

Tell us what you want to build or have improved. Then we will say honestly what is and is not realistic — and what it takes.