HALTUNG
Ein Agent ist ein neuer Kollege
Die wichtigste Entscheidung war keine technische. Wir behandeln einen KI-Agenten wie einen neuen Mitarbeiter: Er bekommt einen Namen, eine klare Rolle und eine Einarbeitung. Er kann schon viel, aber seine Gewohnheiten hat er woanders gelernt. Also zeigen wir ihm, wie wir arbeiten, welche Begriffe in einem Projekt gelten und welche Altlasten er nicht übernehmen soll.
Macht er einen Fehler, erklären wir ihm, warum. Wie bei einem Kollegen, nur dass die Erklärung dauerhaft bleibt: in Regeln, Skills und Projektdateien, die jeder Agent beim Start liest. So fängt niemand in jeder neuen Sitzung wieder bei null an. Ein Review-Agent kennt ein Projekt nach hundert Reviews besser als am ersten Tag. Das ist der eigentliche Hebel.
SO LÄUFT EIN TICKET MIT AGENT
Vom Ticket zum Merge Request
Ein Beispiel aus unserem Alltag
Ein Wert in einem Kundenportal sollte von 80 auf 115 Tage steigen, in zwei Systemen gleichzeitig. Der Agent hat beide Änderungen umgesetzt, die Pipelines liefen grün, nach wenigen Minuten lagen zwei fertige Merge Requests bereit.
Ein Entwickler prüft und gibt frei, den Code angefasst hat er nicht. Bei kleinen, klaren Tickets ist das heute Alltag. Bei großen bleibt der Mensch näher dran.
LEITPLANKEN
Regeln, die kein Agent umgehen kann
Prüfen statt bitten
Was früher als Bitte im Prompt stand, prüfen jetzt Linter und statische Codeanalyse. Über Hooks läuft das bei jedem Schritt des Agenten mit.
Schnelle Tests
Ein End-to-End-Test läuft schon mal 40 Minuten. Integrationstests geben dem Agenten in Sekunden Rückmeldung, deshalb bauen wir sie aus.
Eigene Runner
Lange Testläufe bekommen eigene Pipeline-Runner. So blockieren sie niemanden, der gerade etwas ausliefern will.
Kennzahlen im Merge Request
Testabdeckung und Komplexität der Änderung stehen direkt im Merge Request. Der Reviewer sieht auf einen Blick, wo er genau hinschaut.
Jeder Agent braucht seine eigene Kiste
Ein Agent, der viel darf, kann auch viel kaputt machen. Deshalb bekommt jeder Agent nur das, was er für seine Aufgabe braucht.
Das Problem
Ein Agent arbeitet mit den Rechten des Menschen, der ihn startet. Er sieht dieselben Server, Zugänge und VPNs.
Und zwei Projekte auf einem Rechner kommen sich in die Quere: gleiche Ports, gleiche Docker-Netzwerke, verschiedene VPNs.
Unser Ansatz
Jeder Agent bekommt pro Branch eine eigene kleine virtuelle Maschine mit genau dem, was er für die Aufgabe braucht.
Ist der Branch gemerged, wird die Maschine weggeworfen. So laufen viele Aufgaben parallel, ohne sich zu stören.
SO BAUEN WIR DAS
Eine Micro-VM pro Branch
Auf einem zentralen Server startet ein Broker auf Anfrage eine leichtgewichtige virtuelle Maschine mit Firecracker. Welche Werkzeuge darin stecken, ob Flutter, .NET oder Node, beschreibt jedes Projekt selbst in einer Nix-Konfiguration im eigenen Repository.
So ist jede Umgebung reproduzierbar und schnell bereit. Nach dem Merge verschwindet sie wieder. Diesen Baustein bauen wir gerade.
Zugangsdaten bleiben draußen
Zugangsdaten holt sich die Maschine beim Aufbau einmalig aus unserem zentralen Secrets-Manager, danach ist der Zugang wieder weg. Der Agent selbst kommt nicht heran.
Er arbeitet mit eigenem Git-Zugang und genau den Rechten, die seine Aufgabe braucht. Produktivsysteme und Kundendaten sind für Agenten tabu.
WISSEN TEILEN
Blick in unseren Skill-Marktplatz
Findet einer von uns einen guten Weg, soll ihn jeder nutzen können. Dafür haben wir einen internen Marktplatz in GitLab. Wer dort einen Skill ablegt, macht ihn per Webhook automatisch für das ganze Team installierbar.
Ein Beispiel: unser Skill für das ERP SelectLine. Er bündelt, was wir aus mehreren Projekten über API, Datenbank und typische Fallstricke wissen. Evals prüfen, ob er tut, was er soll. Architekturentscheidungen halten wir zusätzlich als kurze Decision Records fest.
Was bei uns schiefging
Agenten machen Fehler, wie Menschen auch. Einer hat in einem älteren Projekt einen Begriff aus dem Altcode weiterverwendet, obwohl wir ihn ausdrücklich abgelöst hatten. Seine Begründung: Der vorhandene Code macht es doch auch so. Ein anderer wollte sich auf einen Server verbinden, nur weil wir über ein Problem dort gesprochen hatten. Er kam nicht weit. Beides hat uns gezeigt: Regeln gehören in Leitplanken, nicht nur in den Prompt.
VERTRAUEN
Wie viel darf der Agent allein?
In der Sprintplanung schätzen wir nicht nur den Aufwand eines Tickets, sondern auch, wie weit es automatisch laufen darf. Das Vertrauen wächst mit jedem Ticket, genau wie bei einem neuen Kollegen.
KLEIN
Klare Änderung, gut getestet: Der Agent erledigt alles, ein Mensch gibt frei.
MITTEL
Der Agent baut, der Reviewer prüft Stichproben und schaut auf die Kennzahlen.
GROSS
Erst denken Menschen: Anforderungen, Architektur, Entscheidungen. Dann arbeitet der Agent zu.
TABU
Produktivsysteme, Zugangsdaten, Kundendaten. Da hat kein Agent etwas zu suchen.
WERKZEUGKASTEN
Womit wir arbeiten
Agenten
Claude Code MCP-Server Skills und Plugins Hooks
Code und Pipeline
GitLab und GitLab CI Eigene Runner Linter und statische Analyse Integrationstests
Umgebungen
Firecracker Micro-VMs Nix-Konfiguration Docker Secrets-Manager
Anbindungen
Ticketsystem Figma Decision Records Evals für Skills
Was Entwickler uns zuerst fragen
Häufige Fragen zu KI in der Entwicklung
Welche KI nutzt ATMINA in der Softwareentwicklung?
Im Alltag vor allem Claude Code, verbunden mit GitLab, unserem Ticketsystem und Figma. Regeln, Skills und Umgebungen gehören uns und funktionieren auch mit anderen Modellen.
Was ist ein Coding-Agent?
Eine KI, die nicht nur Code vorschlägt, sondern selbst arbeitet: Dateien ändern, Tests starten, Fehler lesen, nachbessern, einen Merge Request anlegen.
Sieht die KI unsere Daten oder Zugangsdaten?
Nein. Agenten arbeiten in abgeschotteten Umgebungen mit eigenen, eingeschränkten Zugängen. Produktivsysteme, Zugangsdaten und Kundendaten bleiben tabu.
Wer trägt die Verantwortung für den Code?
Wir. Jeder Merge Request wird von einem Entwickler geprüft und freigegeben. Die Verantwortung bleibt bei den Menschen, die Du kennst.
Wie prüft Ihr, was ein Agent gebaut hat?
Mit Tests, Linter und statischer Analyse bei jedem Schritt, einer Review-Checkliste im Merge Request und einem Review durch einen Menschen. Wie genau, hängt vom Ticket ab.
Wird Software dadurch günstiger?
Vieles wird schneller, vor allem kleine, klar beschriebene Aufgaben. Dadurch lohnen sich Vorhaben, die früher zu teuer waren. Was das für Dein Projekt heißt, klären wir im Erstgespräch.
Könnt Ihr das auch bei uns einführen?
Ja. Was hier steht, haben wir erst an uns selbst ausprobiert. Für Dein Team starten wir mit einem Visionsworkshop, mehr dazu unter KI im Unternehmen.
Wer steckt hinter ATMINA?
ATMINA Solutions GmbH aus Hannover, Theaterstraße 8. Wir entwickeln Apps, Portale, Backends und KI-Lösungen für den Mittelstand, für Energieversorger, Zoos und Verwaltung. Ansprechpartner: Rüdiger Schwertz, info@atmina.de, 0511 31014100.
Hast Du noch Fragen?
Schreib uns eine Mail oder ruf uns einfach an.
Nimm Kontakt zu uns auf und sprich mit uns über alles, was Dir noch auf der Seele brennt. Wir freuen uns von Dir zu hören!