Many companies have work that runs the same way every week: translating texts, putting reports together, looking up data. That is where we use AI, when we can measure how much time it saves. A person looks at every result first.
Add the event on 14 November with these three photos.
Done. The preview of the changed page is ready, required fields and image sizes are fine.
What we use AI for today
A lot of manual work goes into content. For the website platform of a European hosting group, the AI translates all CMS content into the configured languages and keeps to a glossary and to rules for the tone. It creates new pages from a short instruction. None of it goes live before the editors have approved the language and the page. On smaller websites this works straight from the chat: your team tells Claude what should change, and Claude creates the draft in the CMS.
A second area is questions that come up again and again. For a university in Austria, an assistant answers questions about the degree programmes. It searches the university’s information and suggests programmes that fit. The language model behind it can be swapped.
Then there is data that someone has to read and summarise. For three radio stations, Claude analyses the visitor data: one report goes out by mail every day, and seven more every week to management, marketing, sales and programming. In the support of an online portal, we use Claude to look things up directly in the portal’s data.
We use AI ourselves as well. Claude searches our knowledge base Lobster7 for runbooks and failure patterns, books our time in Mantis and creates invoices.
What all of this has in common is that the task comes up often and you can see quickly whether the result is right. If someone has to check every result at length, AI hardly saves time. Then a script or an interface without any AI is often enough, and that is what we build.
Which models we use
For text and code we mostly use Claude from Anthropic, for images Grok from xAI. Through OpenRouter we reach many more models with one account and pick, for each task, the one that fits on quality and cost.
If data should not end up with any provider, the model runs locally with us, on a Mac or a Raspberry Pi. Which model it will be, we decide together with you before the start.
How the AI reaches your software
We do not build a separate product next to your software. The AI works through the interfaces your software already has, or through one we build for the purpose. Often that is an MCP server. MCP stands for Model Context Protocol, the standard through which an AI assistant such as Claude talks to other software.
We set what the assistant may do in the MCP server. In the CMS, for example, it creates drafts but cannot publish them. In support it looks up data but cannot delete anything. Anyone using the server signs in, and if you like, every call ends up in an audit log.
Move the mouse over a step or tap it. What happens before it and what comes after stays highlighted.
How we go about it
- Measure the task
We look at how long the task takes today, how often it comes up and who does it.
- Build a slice
The first version covers one slice of the task, built with your data and the model you have approved.
- Connect
The model works through the interfaces of your software, with its own access and only the rights it needs. Whatever it creates stays a draft until someone on your side approves it.
- Measure again
We measure again. If the automation saves no time, we take it out again.
Understanding old code with AI
Old software often lacks documentation. Then we first let a language model read the code:
- We get read only access to the repository, configuration and build scripts, and we change nothing.
- The model drafts a description of modules, entry points, cron jobs, interfaces and outdated dependencies.
- An engineer checks every statement against the code, and we remove anything we cannot back up.
- The checked result goes into the inventory, the runbooks and the knowledge base.
The model shows us where a person needs to look more closely. It does not replace an engineer. This fits well with a Legacy Check or a software takeover.
PHP2Shell showed how quickly models now find bugs in large amounts of code. Researchers found two critical PHP vulnerabilities with the help of AI, and attackers use the same models. That is why you should know what is in your old code.
Data protection and human review
Move the mouse over a step or tap it. What happens before it and what comes after stays highlighted.
- Code and data go only to providers you have agreed to, or to a model that runs locally.
- We remove or replace personal data first, as far as the task allows.
- Every integration gets its own API key with exactly the rights it needs. In a CMS we grant these rights per collection.
- Only someone who signs in with a verified company account gets in through an MCP server.
- Whatever a model produces stays a draft until a person approves it. Decisions with consequences for people are always made by a person.
What we do not do
We do not quote savings we have not measured.