Entwicklung einer vollständigen Enterprise-Anwendung mit dem harnext Coding Agent

AI Agents Agentic Workflows Developer Productivity Engineering Culture

„AI schreibt den größten Teil unseres Codes" klingt wie ein Startup-Slogan. Kann es real sein für eine Enterprise-Anwendung – Live-Kunden, Live-Abrechnung, ein Monorepo, wo ein fehlerhafter Merge Geld kostet? Bei QualityUnit ist es so. Hier ist der zehnmonatige Beweisweg und die Regeln, die es funktionieren lassen.

TL;DR: In zehn Monaten ist Agent-verfasste Arbeit von den ersten experimentellen PRs zu 133 von 144 Entwicklungs-PRs, die im Mai zusammengeführt wurden (92%) gegangen – überprüft durch eine dreigeteilte forensische Überprüfung aller 1.409 zusammengeführten PRs bis hinunter zu Commit-Trailern und eine manuelle Überprüfung jeder unmarkierten 2026-PR. Es geschah nicht durch „den AI Code schreiben lassen": Es geschah durch das Hinzufügen von Regeln – eine Risk-Tier-Harness-Config, eine gestaffelte Agent-Pipeline mit begrenzten Review-Schleifen, geschützten Pfaden und einem Menschen, der jeden Merge hält. Die Regeln sind das Produkt. Und mit einer Context Engine, die die Agents füttert, kostet die gleiche Arbeit jetzt ~30% weniger pro Task (gemessen hier ).

Was es wirklich braucht

Kein Tool. Eine Pipeline, eine Policy-Datei und ein Gate – betrieben von harnext .

Die Pipeline: gestaffelte Agents, ein Mensch

Der Harness ist harnext – QualityUnits Open-Source-, Provider-agnostischer Coding-Agent-Harness. In unserem Production-Monorepo durchläuft jedes Problem, das in die Pipeline eintritt, den gleichen Parcours von CI-ausgelösten Agent-Stufen, sein Fortschritt wird durch Labels verfolgt, die ein Mensch auf einen Blick lesen kann:

Die Production-Pipeline: Tagger, Triage, Plan, Implementierung, Review mit einer begrenzten Review-Fix-Schleife, einem unabhängigen Code-Review-Agent, dem menschlichen Merge – plus Doc-Gardening, das dokumentations pro Ordner nach dem Merge synchron hält

Zwei Details sind wichtiger als die Anzahl der Stufen. Die Schleife ist begrenzt: Mängel, die bei der Überprüfung gefunden werden, gehen eine begrenzte Anzahl von Malen zurück zur Implementierungsstufe – Agents konvergieren oder eskalieren zu einem Menschen, sie thrashing nicht. Nichts beginnt blind: Bevor eine Zeile geschrieben wird, muss der implementierende Agent die Konventionen des Projekts laden und einen Bestätigungsblock ausstrahlen, den Reviewer überprüfen können.

Die Policy-Datei

Die andere Hälfte ist eine maschinenlesbare Policy: Jeder Pfad im Repo wird in Risk Tiers klassifiziert, jeder Tier mit durchsetzbaren Gates. CI liest es; Merge-Policy liest es; Agents werden darüber informiert. Es ist kein Rat:

Was eine High-Risk-Änderung bestehen muss: erforderliche Checks, zwei Genehmigungen, obligatorischer Review-Agent, kein Self-Merge, geschützte Pfade, Architekturgrenzen, Screenshot-Beweis – und eine obligatorische Context-Bestätigung

Geschützte Pfade – Migrationen, Zahlungen, Auth – sind Dateien, die kein Agent berühren darf. Architekturgrenzen werden durchgesetzt, nicht vorgeschlagen. Nehmen Sie diese Regeln weg und ein Coding Agent ist ein sehr schneller Generator von glaubwürdig aussehenden Haftungen.

Zehn Monate, ein Diagramm

Der Adoptionspfad, gemessen aus dem Repository selbst.

Entwicklungs-Pull-Requests, die pro Monat zusammengeführt werden, Juli 2025 bis Juni 2026 – Dunkelblaugrün führte die vollständige Agent-Pipeline End-to-End aus, Hellblaugrün ist ein Entwickler, der direkt mit dem Agent paart, Grau ist unmarkiert. Der Prozentsatz ist die gesamte Agent-Beteiligung und erreicht im Mai 2026 92%

Das Diagramm zählt für jeden Monat, wie viele zusammengeführten Entwicklungs-PRs ein hartes Agent-Signal tragen – der Coding Agent’s Footer, die Pipeline-Labels, die Harness-Tier-Konvention, Commit-Co-Author-Trailer, Agent-Commit-E-Mails oder das eigene Konto der Pipeline als Autor. Dependency-Bot-PRs (etwa 8% aller Merges) sind vollständig aus dem Diagramm ausgeschlossen – sie sind weder menschliche noch Coding-Agent-Arbeit. Wir überprüften die Signale auf drei unabhängige Wege: PR-Metadaten für alle 1.409 Merges, Commit-Level-Trailer über 5.000+ Commits und ein manueller forensischer Pass über alle unmarkierten PRs von 2026. Drei Lesarten sind wichtig:

Begeisterung verblasst; Infrastruktur bleibt. Die 2025-Ära war Ad-hoc-, persönliche Adoption – und sie schwankte genau wie persönliche Gewohnheiten: 44% in einem Monat, kaum 4% im November, als die schwersten Benutzer pausiert. Der Harness änderte die Form der Kurve: Innerhalb eines Monats nach der Ankunft der Risk Tiers sprang der gemessene Anteil auf 89%; mit der vollständigen Pipeline erreichte sie 92% und blieb dort. Jede Schicht von Regeln erhöhte die Adoption mehr als die Begeisterung eines Einzelnen je tat. Die beiden Schattierungen erzählen die gleiche Geschichte innerhalb des Agent-Anteils: Das hellere Band ist Entwickler, die mit dem Agent von Hand paaren; das dunkle Band – Arbeit, die die vollständige Pipeline von Problem zu überprüftem PR durchlief – erscheint nur, wenn der Harness landet, und im Mai trägt es die Mehrheit der Agent-Arbeit.

Wir inspiziert den Rest, PR für PR. Für April–Juni 2026 zerfallen die PRs ohne Markierung in: Dependency-Bot-Automatisierung, Agent-Arbeit, deren einzige Attribution in Commit-Trailern überlebte, und ein Rest von möglicherweise handgeschriebenen Änderungen – etwa 11% der Non-Automation-Merges. Die ehrliche Aussage ist also: ~89% der echten Entwicklungs-Merges im letzten Quartal zeigen überprüfbare Agent-Beteiligung – und selbst das ist eine Untergrenze, da Editor-Ebene AI-Unterstützung keine Spur hinterlässt. Wir schickten auch skeptische Auditors bei den drei schwächsten Monaten, PR für PR: Novembers Zahl stieg von 1 auf 3 bewiesene (plus 3 verdächtig auf Stil), Januars fiel von 10 auf 8 nach zwei Falsch-Positiven, und Dezember wurde genau bestätigt – mit einer Wendung: nach Code-Volumen lieferten Dezembers acht markierten PRs 39% der eingefügten Zeilen dieses Monats. Der Agent schrieb bereits die großen Funktionen; die Zahl konnte es nur nicht sehen. Die Adoption ist auch nicht einheitlich: Einige Entwickler führen nahezu 100% Agent-unterstützt aus, ein Paar schreiben immer noch meist von Hand – die Pipeline trägt in jedem Fall einen wachsenden Anteil.

Die Qualität bewegte sich nicht rückwärts. Das gleiche Fenster versendet Tier-3-Änderungen – LLM-Provider-Integration, zahlungsnahe Arbeit, eine i18n-Expansion – unter Gates, die im Zeitraum strenger wurden, nicht lockerer. Und als wir die Agent-Review-Konsistenz direkt maßen, erreichten 21 von 22 unabhängigen Review-Agents das gleiche Urteil auf der gleichen PR.

Also wer ist der Autor?

Die beste Artikulation, wo dies den Menschen hinterlässt, kommt von einer Engineering-These, die Harness-getriebene Entwicklung auf einem luftfahrttechnischen Projekt untersuchte:

Zu dem Zeitpunkt, als eine Änderung den menschlichen Autor erreichte, waren die Routine-Qualitätsprobleme gelöst – die Überprüfung des Autors konzentrierte sich auf architektonische und Domain-Level-Entscheidungen. Der Merge war die Entscheidung des Autors. Die Urheberschaft des zusammengeführten Codes liegt beim menschlichen Autor, unabhängig davon, welcher Akteur den ursprünglichen Entwurf erstellte.

— Štefan Moravík, Design and Implementation of a Drone Mission Planning Module for Airport Lighting Inspection (These, 2026)

Das ist auch der Deal in der Production: Agents machen den Entwurf und die Routine-Qualitätsarbeit; der Mensch macht Architektur, Domain-Urteil und besitzt den Merge.

Häufig gestellte Fragen

Štefan ist ein KI- und Softwareingenieur, der FlowHunt entwickelt. Über das Produkt selbst hinaus entwirft er agentic Software-Engineering-Workflows für Entwickler, die Entwicklungskosten senken und gleichzeitig die Codequalität verbessern.

Štefan Moravík
Štefan Moravík
KI- & Softwareingenieur

Bringen Sie eine Agent-Pipeline zu Ihrem Team

FlowHunt hilft Engineering-Teams, Agent-Pipelines, Risk-Tier-Gates und Context-Workflows zu entwerfen, die die Code-Qualität erhöhen und Entwicklungskosten senken.