AI in development

This page exists because the question is a fair one, and it is better answered directly than left to guesswork. Below is what artificial intelligence actually does in our products, what it does not do, and why it is still involved in a few places.

Development does not run "through AI" by default

There is no rule here that says "write it with AI". Products are designed and written by people: architecture, domain logic, security, handling of user data, payments — those are decisions an author answers for, not a model.

Where it does take part, consistently:

• finding bugs and errors — going over code and catching what a person missed;
• diagnostics — working through an incident, a log, odd behaviour in production;
• reviewing our own and each other's work — a second pair of eyes before a release;
• routine — mechanical edits, repetitive moves, the rough scaffolding around a decision that has already been made.

Those are exactly the tasks a machine is good at: its attention does not tire, and it reads in full what a person skims. The line is not whether AI touches the code — it is who makes the decision and who can explain the result.

Design: where AI is involved, and why

Here it is more honest to say it plainly. The team is small, and there is not enough time right now to take every screen of every product to its best possible quality. So some interface elements were made with AI involved.

The boundaries we hold:

• AI does not design the applications themselves — their structure, navigation, main screens;
• AI does not design the key pages of our products;
• AI is involved in individual windows and supporting elements — where it matters more that the element exists and works than that it is polished.

Take the company structure. That page was made entirely by AI: the interactive tree, the layout, how the nodes behave, and the small visual effects down to the last detail. It exists as a pleasant extra, so that a user or anyone from outside can see at a glance how our departments and products fit together — and it is exactly the kind of place where that approach fits. Delaying work on the player or on billing for it would be odd.

Individual mechanics inside the products work the same way: where an element matters in itself rather than as part of the architecture, it can perfectly well be built end to end by a machine.

We are not cutting AI back — we are looking for the balance

This page used to say we would reduce the influence of AI to a minimum. That was not true, and there is no reason to keep something untrue here.

We are not going to remove AI from the process, and we are not going to replace people with it. Both extremes are equally bad: the first means doing half as much for no reason, the second means losing the understanding of your own product. What we are after is a balance in which one person comfortably produces more than a whole team used to, and still understands their code: how it is built, what happens inside it, and why it was done this way.

Everything else follows from that:

• AI helps us produce more; it does not replace the author. It speeds up the routine, optimises processes, proofreads what was written, and takes on the parts that need patience rather than judgement.
• Structure, architecture and boundaries stay with the person. Even as we move towards development with more AI involved, we are the ones setting its limits: what gets designed, where the service boundaries run, what things are called, and what counts as correct.
• Understanding the code is non-negotiable. Code nobody in the company can explain is not finished, no matter who wrote it. That is exactly what our machine-enforced code standard is for: it holds names, contracts and structure in one shape, so that a year from now a person can read them — not only whoever generated them.

So no: we do not plan to reduce the amount of AI in our process. We plan to reduce the share of it we do not understand.

Which model we use

One: Claude by Anthropic. Not an assortment of models picked by price per task, but a single one we trust.

It does not run out of the box either. It is wired with additional skills for reviewing its own code and hunting bugs, plus our own skills written specifically for this platform — they know our services, our code standard and our sharp edges. Separately documented: how our code standard relates to language models — we deliberately do not hand a model the full standard, because it drifts back to the style it was trained on.

In our view Anthropic's model is currently the safest and the best option for a business on the market. That is our opinion and our choice, not a claim about anyone else's products.

What the model does not get to decide

Code written or fixed with AI involved goes through the same checks as any other: the machine code standard in pre-commit and CI, human review, and a deploy verified on production itself. No line reaches users on the grounds that "the model suggested it".