How I work with teams
AI amplifies what is already there
Most teams introduce AI tools and hope for speed. What actually happens depends less on the model than on the path to production. Where tests, linting and security checks are enforced automatically, a team measurably gets better with AI. Where those gates are missing, more code appears faster than anyone can take responsibility for.
So I do not start with the tool selection. I start with your delivery pipeline.
Not tied to a tool or a vendor
GitHub Copilot, Claude Code, Cursor, Codex: the large coding assistants now cover the same building blocks. Instruction files, specialised agents, reusable prompts, deterministic guardrails, tool access over MCP, planning phases and permissions exist everywhere — mostly the names differ.
That makes the tool question a question of licensing, integration with your existing infrastructure and data protection, not of features. I answer it for your context and build your setup so that switching vendors does not become a new project.
The same goes for the models: Anthropic, OpenAI and Google as much as open models you run in your own infrastructure or in a European cloud. Where your code must not leave the building, we set up locally hosted models.
How I work with teams
Three steps, always in this order.
01
Baseline
Measure before anything gets introduced. Without numbers from before the rollout, every later efficiency claim is an assertion — mine included.
02
Harden
Tests, linting, security analysis and review rules run automatically in the pipeline and apply to human and machine-written code alike. That makes the origin of the code a side issue.
03
Adopt
We work in your repositories, not in sample projects. What is left at the end is a working setup in your code that your team can run without me.
What we talk about early
Test automation
Without solid tests, AI becomes an accelerator in the wrong direction: more code per day that nobody can check. In most projects I see, the test situation is the actual bottleneck — not the model. That is why test automation is part of the AI topic and not next to it.
Guardrails for unattended agents
The more independently an AI tool works, the less an instruction in the prompt carries. What an agent may and may not do belongs in permissions, sandboxing and automated checks — not in a polite request to the model.
Who I work with
Development teams from around four people upwards, in mid-sized companies and industry, including regulated environments where demonstrable checks are mandatory anyway.
Questions I get asked first
- Which AI coding tool should we use?
- Usually the wrong first question. GitHub Copilot, Claude Code, Cursor and Codex now cover the same building blocks — instruction files, specialised agents, reusable prompts, guardrails, tool access over MCP. What actually differs is licensing, how the tool fits your existing infrastructure, and what your data protection requirements allow. I answer that for your context and build the setup so a vendor change does not become a new project.
- How much faster will our team be?
- I do not put a number on that, and I would be sceptical of anyone who does before seeing your pipeline. The cleanest controlled study on the topic measured experienced developers in familiar codebases taking longer with AI while being convinced they were faster. Without a baseline from before the rollout, every efficiency claim is an assertion — mine included. That is why the work starts with measuring.
- Our test coverage is weak. Should we fix that first?
- Not first — alongside. Without solid tests, AI becomes an accelerator in the wrong direction: more code per day that nobody can check. In most projects I see, the test situation is the actual bottleneck rather than the model. So test automation is part of the AI work, not a prerequisite you have to finish before we start.
- Can our code leave the building?
- It does not have to. Alongside the models from Anthropic, OpenAI and Google, we work with open models you run in your own infrastructure or in a European cloud. Where the requirement is strict, we set up locally hosted models.
- How do we stop an agent from doing something destructive?
- By making it technically impossible rather than asking politely. The more independently an AI tool works, the less an instruction in the prompt carries. Permissions, sandboxing, lifecycle hooks that intercept tool calls before they run, and automated checks in CI are the controls that hold; a line in a prompt is not a security boundary.
- What does an engagement look like?
- It starts with a 20-minute call about where your team stands, then a baseline of your delivery pipeline. From there the measures follow your situation rather than a fixed package. The work is delivered through SHI GmbH, where I lead the AI Engineering & Developer Productivity practice.
How an engagement runs
The work is delivered through SHI GmbH, where I lead the AI Engineering & Developer Productivity practice. This site is my personal one — for the commercial side, the contract and the imprint, SHI is the counterpart.
No strings attached. We talk about where your team stands.