Arbeitsweise
Sechs Stationen, bevor etwas in Betrieb geht.
Jede Änderung läuft dieselbe Strecke, ob ein Mensch sie begonnen hat oder ein Werkzeug: Entwurf, Umsetzung, Tests, Code-Review, Security-Review, Freigabe. KI ist dabei eines unserer Werkzeuge – ein gut beherrschtes, aber eben ein Werkzeug. Was es bei uns verändert hat und wo es nichts zu suchen hat, steht auf dieser Seite.
Was besser geworden ist
Vier Dinge, die vorher nicht so gut waren.
Der Gewinn liegt nicht darin, dass eine Maschine tippt. Er liegt darin, dass die Arbeit zwischen den Handgriffen verschwindet – und dass genau die Dinge jetzt selbstverständlich sind, die früher am Ende eines Projekts als Erstes gestrichen wurden.
Weniger Fehler
Jede Änderung wird gegengelesen, bevor sie ein Mensch zu Gesicht bekommt – gegen unsere eigenen, aufgeschriebenen Konventionen. Das ist ein Vorfilter und kein Ersatz für das menschliche Review: Ein Modell übersieht Zusammenhänge und meldet Dinge, die keine sind. Was es leistet, ist, dass im Review über Fachlichkeit gesprochen wird statt über Einrückungen und vergessene Null-Prüfungen.
Mehr Sonderfälle
Der leere Zustand, die abgelaufene Sitzung, der Anhang mit 40 MB, die Mail ohne Absenderkennung: Genau die Fälle, für die am Projektende nie Zeit war, werden heute von vornherein mitgedacht – und mit einem Test belegt.
Bessere Tests
Jede Änderung bringt ihre Tests mit. Nicht als guter Vorsatz, sondern als Bedingung: Ohne grüne Testsuite läuft bei uns keine Auslieferung. Das ist auch der Grund, warum agentische Entwicklung überhaupt trägt.
Bessere Dokumentation
Sie entsteht mit, weil die Agenten sie brauchen: Was ein neuer Entwickler wissen müsste, steht bei uns im Repository. Der Nebeneffekt für Sie ist der wichtigere – das Wissen über Ihr System hängt nicht mehr an einer einzelnen Person.
Die Grenze
In sensiblen Bereichen arbeiten wir nicht blind.
Beispiel: DIVI Kindernotfall-App
Die App entsteht weiterhin überwiegend in Handarbeit. KI hilft beim Testen, beim Aufspüren von Sonderfällen und beim Dokumentieren – aber jede Zeile, an der eine Medikamentendosis hängt, wird von Menschen geschrieben, von Menschen geprüft und fachlich abgenommen.
Wo ein Fehler jemanden gefährden kann, ist Geschwindigkeit das falsche Ziel. Dort ist KI ein zusätzliches Paar Augen – nie das letzte. Das ist keine Zurückhaltung aus Vorsicht vor der Technik, sondern die gleiche Regel, die wir auch an Menschen anlegen: Wer eine Dosierungstabelle anfasst, macht das nicht allein.
Umgekehrt gilt dasselbe für die fertige Software: Auch dort schlägt eine KI vor und ein Mensch schickt ab. Keine Antwort an einen Kunden, keine Einstufung und keine Freigabe läuft bei uns automatisch durch.
Der Prüfweg
Keine Station lässt sich überspringen.
Jede Änderung läuft dieselbe Strecke – ob ein Agent sie begonnen hat oder ein Mensch. Die Reihenfolge ist nicht verhandelbar, und keine Station lässt sich überspringen, weil es gerade eilt.
-
01 Entwurf
Datenmodell, Schnittstellen, betroffene Dateien, Migrationen und Risiken stehen fest, bevor die erste Zeile entsteht. Wer hier schludert, bekommt von einem Agenten zuverlässig das Falsche – schnell und in großer Menge.
-
02 Umsetzung
Abgegrenzte Aufgaben, ein Zweig je Aufgabe, ein Pull Request je Zweig. Mehrere laufen parallel, aber keine greift der anderen ins Lenkrad. Was nicht durchschaubar ist, wird nicht zusammengeführt.
-
03 Tests
Automatisierte Tests zu jeder Änderung, dazu die vollständige Suite bei jedem Lauf. Sie sind die einzige Rückmeldung, die ein Agent zuverlässig versteht – und die einzige, die auch in zwei Jahren noch prüft, was heute gemeint war.
-
04 Code-Review
Geprüft wird gegen unsere aufgeschriebenen Konventionen: Zugriffsrechte je Mandant, Zeitzonen, Fehlerbehandlung in der Eingangsstrecke, Umgang mit personenbezogenen Daten. Erst danach sieht ein Mensch den Vorgang.
-
05 Security-Review
Was Sicherheit berührt, geht an unsere eigenen IT-Security-Spezialisten: Authentifizierung, Rechteprüfung, Datenflüsse, Abhängigkeiten, Angriffsfläche. Bei größeren Änderungen mit Penetrationstest.
-
06 Freigabe durch einen Menschen
Ein Entwickler liest den Pull Request und entscheidet. Er verantwortet die Änderung – nicht der Agent, der sie vorgeschlagen hat. Erst danach läuft die Auslieferung, und die läuft ohne Unterbrechung für die Nutzer.
Informationssicherheit
Security-Reviews und Penetrationstests machen unsere eigenen Leute.
Nicht als eingekaufter Termin einmal im Jahr, sondern als Teil der Entwicklung. Unsere Spezialisten prüfen Architektur und Code, greifen die Anwendung an, bevor es jemand anderes tut, und verfolgen jeden Befund bis zur behobenen Ursache.
Zusammen mit KI ist unsere Software sicherer als je zuvor. Der Grund ist banal: Prüfen ist billiger geworden. Wir sehen mehr Änderungen genauer durch, weil das Durchlesen nicht mehr die teuerste Stunde des Tages ist – und zwischen Befund und behobener Ursache liegt selten mehr als eine Sitzung, weil Fix und Test darin zusammen entstehen.
Verlangt Ihre Vergabe einen unabhängigen Test durch Dritte, arbeiten wir mit externen Prüfern – der interne Review ersetzt ihn nicht. Was unsere Prüfung leistet und was nicht.
Penetrationstests
Die Anwendung wird auf Angriff geprüft, nicht nur auf Funktion – Authentifizierung, Rechteumgehung, Einschleusen, Dateiverarbeitung.
Abhängigkeiten mit Riegel
Bekannte Schwachstellen in Bibliotheken brechen bei uns den Auslieferungslauf ab, statt in einem Bericht zu landen, den niemand liest.
Befunde mit Nachlauf
Jeder Befund bekommt einen Test, der ihn ab dann verhindert. Ein zweites Mal darf dieselbe Lücke nicht entstehen.
ISO/IEC 27001:2022
Die Abläufe dahinter – Zugriff, Freigabe, Vorfall, Wiederanlauf – sind zertifiziert und werden geprüft.
Was Sie davon haben
Mehr Umsetzung pro Woche – bei strengerer Prüfung.
Kürzere Runden
Weniger Altlast
Weniger Personenabhängigkeit
Prüfbare Historie
Reden wir über Ihr System.
Ob Neubau, Übernahme oder eine KI-Funktion in einer bestehenden Anwendung: Schildern Sie kurz die Ausgangslage, wir melden uns mit einer Einschätzung.
Antwort in der Regel innerhalb eines Werktages – von Alexander Fendt oder jemandem aus dem Team, der die Software auch baut.