KI-gestützte Code-Qualität: Wie Nicht-Entwickler mit Harness sichere PRs erstellen

Die Vorstellung, dass nur Softwareentwickler Änderungen in Produktionscode vornehmen können, gehört mit modernen KI-basierten Systemen der Vergangenheit an. Bei airCloset zeigt sich: Selbst komplexe Pull Requests mit über 1.700 Zeilen und 41 Dateien lassen sich von Nicht-Technikern erstellen, während KI-gestützte Harness-Systeme die Qualität sicherstellen. Wie dieser Prozess funktioniert und welche Mechanismen dahinterstecken, erklärt dieser Artikel.

Vom Code zur Produktion: Wie Harness die Qualitätssicherung automatisiert

Das Harness-System von airCloset, intern unter dem Codenamen cortex bekannt, hat sich in den letzten Monaten weiterentwickelt. Ursprünglich als Runtime-Plattform für KI-Produktionen konzipiert, ermöglicht es nun auch Nicht-Entwicklern wie Produktmanagern oder Teamleitern, Pull Requests direkt in das Produktionsrepository zu integrieren. Die Grundlage dafür bilden vier zentrale Komponenten: der Wissensgraph, automatisierte Reviews, Selbstheilung und Wiederholungsprävention.

Die neueste Entwicklung geht jedoch einen Schritt weiter: Nicht nur die Qualitätssicherung, sondern auch die Erstellung von Code wird demokratisiert. Ein konkretes Beispiel zeigt, wie dieser Prozess in der Praxis aussieht und welche Hürden dabei überwunden werden müssen.

Ein 1.742-Zeilen-PR von einem Nicht-Entwickler: So funktioniert der Ablauf

Ein kürzlich eingereichter Pull Request mit dem Titel „PL dashboard ver.2“ verdeutlicht die Möglichkeiten des Harness-Systems. Der PR umfasste:

• 1.742 Zeilen Code in 41 Dateien
• Änderungen in mehreren Repository-Bereichen (Shared-Types-Paket, API-Server, SQL-Abfragen mit INNER JOIN und LEFT JOIN, Web-App-Seiten, View-State und persönliche Einstellungen)
• Eine neue Projektansicht für Manager und Teamleiter, die Daten nur aus ihren jeweiligen Abteilungen anzeigt

Für einen erfahrenen Entwickler hätte diese Änderung mehrere Tage in Anspruch genommen. Doch hier kam sie von einem Nicht-Programmierer – ein Szenario, das ohne KI-Unterstützung und automatisierte Qualitätssicherung kaum vorstellbar wäre.

Die vier Phasen des Review- und Merge-Prozesses

Der Ablauf des PRs gliederte sich in vier iterative Review-Runden, bei denen ausschließlich KI und automatisierte Bots zum Einsatz kamen:

1. Erste Review-Runde:

• Das KI-gestützte Review-System identifizierte einen kritischen Fehler: eine Berechtigungslücke, durch die Daten anderer Abteilungen in die Ansicht gelangten. Zusätzlich wurden kleinere stilistische und strukturelle Probleme gemeldet.

1. Automatisierte Korrekturen:

• Ein Author-Bot (ein automatisierter Agent, der auf dem Entwickler-Endgerät läuft) nahm die notwendigen Anpassungen vor und schloss die Berechtigungslücke. Die kleineren Probleme wurden behoben.

1. Zweite Review-Runde:

• Das System fand noch verbliebene Nit-Picks (kommentierte Kleinigkeiten) sowie einen Lint-Fehler (no-empty-function).
• Der Author-Bot korrigierte diese und optimierte die Lade-Skelette des Dashboards.

1. Dritte Review-Runde und Merge:

• Nach weiteren Feinjustierungen durch den Author-Bot erteilte das KI-System die Freigabe. Die Continuous Integration (CI) bestätigte die Testabdeckung (100 % der Shared-Type-Checks, API-Tests, Web-Spezifikationen und Lint-Regeln). Anschließend wurde der PR automatisch gemergt.

Ergebnis: Innerhalb weniger Stunden durchlief der PR vier Review-Runden, drei Korrekturschleifen und wurde ohne manuelle menschliche Prüfung in die Produktion überführt. Die Qualitätssicherung erfolgte ausschließlich durch KI und Automatisierung.

Warum dieser Prozess für Nicht-Entwickler funktioniert

Die entscheidenden Faktoren, die diesen Ablauf ermöglichen, sind:

• Automatisierte Reviews: Das KI-System prüft nicht nur auf Syntaxfehler, sondern erkennt auch logische Schwachstellen wie Berechtigungslücken – eine Aufgabe, die für manuelle Reviews oft zu aufwendig oder fehleranfällig wäre.

• Selbstheilung: Kleine Anpassungen werden direkt vom Author-Bot vorgenommen, sodass der Entwickler sich auf die inhaltliche Logik konzentrieren kann.

• Wiederholungsprävention: Sobald ein Problem erkannt und behoben wurde, wird es automatisch in zukünftigen PRs verhindert. Das reduziert menschliche Fehler nachhaltig.

• Qualitätssicherung ohne manuelle Freigabe: Die Kombination aus KI-Reviews, automatisierten Korrekturen und CI-Tests stellt sicher, dass kein Code ohne vorherige Prüfung in die Produktion gelangt – selbst wenn der Ersteller kein Entwickler ist.

Grenzen und Herausforderungen: Wo die Technologie an ihre Grenzen stößt

Trotz der beeindruckenden Automatisierung gibt es Bereiche, in denen menschliches Eingreifen unverzichtbar bleibt:

• Neue Infrastruktur aufbauen: Wenn eine Änderung grundlegend neue Systeme erfordert (z. B. die Einführung einer neuen Datenbank oder Microservice-Architektur), ist weiterhin Fachwissen von Entwicklern nötig. Die Harness-Technologie unterstützt hier vor allem bei der Wartung und Optimierung bestehender Strukturen.

• Komplexe Architekturentscheidungen: Nicht alle Probleme lassen sich durch automatisierte Lösungen beheben. In solchen Fällen bleibt die Zusammenarbeit mit erfahrenen Entwicklern essenziell.

• Philosophische Fragen: Die Demokratisierung der Code-Erstellung wirft Diskussionen auf – etwa darüber, welche Verantwortung Entwickler tragen und wie weit Automatisierung gehen darf. Diese Themen werden in einem separaten Artikel der Serie vertieft.

Die Zukunft: Vom Harness-System zu Consumer-to-Consumer-Diensten

Die aktuelle Entwicklung bei airCloset markiert einen wichtigen Meilenstein: Die Harness-Technologie hat sich von einem reinen KI-Runtime-System zu einer Plattform für nicht-technische Nutzer weiterentwickelt. Während der Fokus bisher auf der Wartung und Qualitätssicherung lag, steht nun die Skalierung für Consumer-to-Consumer-Dienste im Mittelpunkt.

Die nächsten Schritte umfassen:

• Ermöglichung von Low-Code/No-Code-Workflows für Endnutzer, die direkt mit dem Harness-System interagieren können.
• Integration von Benutzerfeedback in Echtzeit, um die KI-gestützten Reviews weiter zu verbessern.
• Erweiterung der Automatisierung auf weitere Bereiche wie Deployment, Monitoring und Incident Response.

Diese Entwicklungen werden die Art und Weise, wie Software gewartet und verbessert wird, grundlegend verändern – und zeigen, dass KI nicht nur Entwickler, sondern auch Produktverantwortliche und Geschäftsleute zu Code-Autoren machen kann.

Der nächste Artikel der Serie wird sich mit der philosophischen Grundlage des Harness-Systems befassen: Welche Kompromisse wurden eingegangen? Welche Prinzipien blieben erhalten? Und warum ist dieses Design ein Schritt in die richtige Richtung? Bleiben Sie dran.