Ixor verankerde Claude Code van Anthropic in de ontwikkelcyclus van Dokapi: een vaste workflow met skills, guardrails en menselijke goedkeuring. Sinds maart 2026 draait die workflow in productie.
De context
Dokapi is een Belgisch API-platform voor e-facturatie in heel Europa. Als erkend Peppol Access Point verwerkt het meer dan 70 miljoen documenten per jaar in meer dan 30 landen. Klanten koppelen één keer, en Dokapi neemt de formaten, netwerken en lokale compliance-regels voor zijn rekening.
Dat legt een hoge druk op het ontwikkelteam. Regelgeving verandert voortdurend, nieuwe landverplichtingen blijven komen, en elke wijziging moet gebouwd, getest, gereviewd en gedocumenteerd worden zonder in te boeten op veiligheid. Dokapi is ISO 27001-gecertificeerd: snelheid mag nooit ten koste gaan van controle.
De menselijke kant
Zoals de meeste ontwikkelteams experimenteerden de developers van Dokapi al met AI-codeertools. Maar iedereen gebruikte ze anders, met eigen prompts, eigen gewoontes en een eigen idee van wat "goed" is. De winst bleef individueel en moeilijk meetbaar. En de vragen die een securitybewust team moet stellen, bleven onbeantwoord: wat ziet de tool, wat mag hij doen, en wie controleert zijn output?
De echte bottleneck zat zelden in het schrijven van code. Hij zat in alles errond: branches opzetten, commits en pull request-beschrijvingen schrijven, reviews uitvoeren, opmerkingen verwerken, documentatie up-to-date houden. Werk dat nodig is, repetitief, en makkelijk uitgesteld wordt.
De aanpak
We begonnen niet met iedereen een nieuwe tool te geven. We begonnen met afspreken hoe het team wil werken. In een teamsessie brachten we in kaart waar AI waarde toevoegt in de ontwikkelcyclus en waar het alleen ruis toevoegt. We bekeken ook hoeveel autonomie een agent mag krijgen, en welke guardrails niet onderhandelbaar zijn.
We focusten op zes domeinen: hergebruik van skills en configuratie, AI in de ontwikkelcyclus, schaal en complexiteit van de codebase, autonomie en controle, kwaliteit en security, en adoptie binnen het team.
Het resultaat was een concrete pilot-workflow, eerst in één project: Jira-ticket in, gereviewde pull request uit. De workflow is gebouwd op Claude Code en telt elf stappen. Een developer schrijft een goede specificatie in Jira en start de ontwikkeling via een skill. Vanaf dan maakt Claude Code een feature branch aan met de naam van het ticket, codeert volgens de conventies van het team en zet het ticketnummer in elke commit. De developer test lokaal. Daarna opent Claude Code een pull request met een uitgebreide beschrijving en start een code review, gevolgd door een security review. De developer verwerkt de opmerkingen, en een mens geeft de finale goedkeuring.
Sinds maart 2026 draait deze workflow dagelijks in productie bij het ontwikkelteam van Dokapi.
Elke stap wordt aangestuurd door een kleine, gedeelde en geversioneerde skill, gegroepeerd in vier families:
- Workflow: het volgende ticket oppikken, committen met het ticketnummer, een pull request openen.
- Kwaliteit: code vereenvoudigen, bouwen volgens de richtlijnen, tests genereren en documentatie schrijven.
- Review: reviews starten en opmerkingen op pull requests opvolgen.
- Security en compliance: statische security review, scannen van dependencies en licentiecontroles.
De agent werkt waar het team al werkt: Jira voor tickets, Bitbucket voor repositories en pull requests, en Bitbucket Pipelines, waarvan de build-output teruggevoerd wordt in de lus zodat fouten automatisch opgelost worden.
Guardrails by design
Voor een ISO 27001-bedrijf is controle geen optie. Daarom worden de harde grenzen niet aan afspraken overgelaten, maar op toolniveau afgedwongen via hooks. De agent kan niet mergen zonder menselijke goedkeuring en kan geen gevoelige bestanden lezen, zoals environment-bestanden, sleutels of secrets. De blocklist groeit mee naarmate het team bijleert. Een security review is een verplichte stap in elke pull request, geen optie.
De developer blijft op elk kritiek moment aan het stuur. Hij schrijft de specificatie, test lokaal, verwerkt de reviewopmerkingen en geeft de finale goedkeuring. De agent doet het voorwerk.
De impact
- Voor het ontwikkelteam: de gemiddelde doorlooptijd van Jira-ticket tot ontwikkelde, gereviewde en gedocumenteerde code daalde in de eerste maand van 6 naar 4 dagen.
- Voor de kwaliteit: elke pull request krijgt nu dezelfde code review en security review, en documentatie is een vast onderdeel van de workflow in plaats van een bijzaak.
- Voor de consistentie: dankzij gedeelde skills en configuratie werkt elke developer volgens dezelfde standaarden, op welk project hij ook zit.
- Voor Dokapi als geheel: snellere oplevering van de wijzigingen die klanten en regelgevers vragen, zonder de controles los te laten waar een ISO 27001-platform op steunt.
Waarom Ixor?
De meeste teams nemen AI-codeertools developer per developer in gebruik. Wij behandelen het als een procesverandering. Eerst spreken we af hoe het team wil werken, dan leggen we dat vast in skills en guardrails, en pas dan schalen we op.
Bij Dokapi is het resultaat geen slimmere autocomplete. Het is een ontwikkelworkflow waarin Claude Code het routinewerk draagt en mensen de beslissingen nemen.
