Zum Inhalt springen
SwankyForge
SwankyForge
Alle Insights
Artikel8 Min. Lesezeit

Mit einem KI-Partner in jedem Repository automatisieren wir die Prüfungen und lassen fünf Entscheidungen bei Menschen

Wie das Engineering-Team mit KI-Coding-Assistenten arbeitet: was bei jeder Änderung automatisch läuft, was immer ein Mensch entscheidet und was wir noch nicht gemessen haben.

Die meiste Engineering-Arbeit in unseren Repositories beginnt heute damit, dass ein KI-Coding-Assistent einen ersten Entwurf schreibt. Nichts davon geht auf das Wort des Assistenten hin live. Diese Notiz beschreibt das Setup, wie es im Repository hinter dieser Website existiert, weil wir dieses öffentlich zeigen können. Sie listet außerdem die Entscheidungen auf, die wir bei Menschen lassen, und die Zahl, die wir Ihnen noch nicht nennen können.

Die Kurzfassung, wenn Sie einkaufen

Wir sind ein kleines Labor aus zwei Engineers, ergänzt um Spezialisten je nach Projekt. Ein KI-Assistent arbeitet neben uns beiden. Er entwirft Code, Tests, Dokumentation und Routinetexte. Automatische Prüfungen laufen bei jeder Änderung und blockieren diejenigen, die eine Regel verletzen. Ein Mensch liest jede Änderung, bevor sie gemergt wird. Nichts erreicht Produktion oder Öffentlichkeit ohne ein ausdrückliches Ja.

Was Sie davon haben: Dieselben zwei Engineers decken mehr von der Routinearbeit ab, die kleine Teams gern auslassen, etwa Tests, Dokumentation und Release-Prüfungen. Das lässt mehr vom Budget für die Teile, die Urteilsvermögen brauchen: die Kennzahl wählen, entscheiden, ob sich ein Modell lohnt, und es in Ihren Prozess einfügen.

Was wir nicht behaupten: eine Zahl zur Beschleunigung. Wir haben keine gemessen, und die externen Belege sagen, dass selbst berichtete Beschleunigung unzuverlässig ist. Die letzten Abschnitte sagen, was wir messen würden und was das für einen Kunden bedeutet.

Was die Forschung sagt: Das Tool ist nicht der Gewinn

Vier Studien aus 2025 haben geprägt, wie wir das aufgesetzt haben.

  • Googles DORA-Programm befragte für den Bericht 2025 fast 5.000 Technologie-Fachleute. 90% nutzen KI bei der Arbeit, und mehr als 80% glauben, dass sie dadurch produktiver geworden sind. Dennoch haben 30% wenig oder kein Vertrauen in den generierten Code. Der Bericht fasst zusammen, dass KI „amplifies what's already there“: Starke Teams werden besser, Teams mit Schwierigkeiten erleben, wie sich ihre Probleme verschärfen.
  • Bains Technology Report 2025 ergab, dass Teams mit KI-Coding-Assistenten Produktivitätsgewinne von 10–15% sehen. Manche Unternehmen berichten 25–30%, aber nur, wenn KI mit einer Neugestaltung des ganzen Prozesses einhergeht. Ein Grund, warum die erste Zahl klein ist: Schreiben und Testen von Code macht etwa 25–35% der Zeit von der Idee bis zum Launch aus.
  • Die Stack Overflow Developer Survey 2025 ergab, dass 84% der Befragten KI-Tools nutzen oder planen, sie zu nutzen, und 46% der Genauigkeit der Ausgabe misstrauen. Das häufigste Ärgernis war Ausgabe, die fast richtig ist, aber nicht ganz.
  • METR führte eine randomisierte Studie mit 16 erfahrenen Open-Source-Entwicklern an 246 realen Aufgaben durch. Mit erlaubten KI-Tools dauerten die Aufgaben 19% länger. Die Entwickler hatten eine Beschleunigung von 24% erwartet und glaubten danach immer noch, 20% schneller gewesen zu sein. Die Autoren weisen darauf hin, dass das Ergebnis spezifisch für ihr Setting ist: große, ausgereifte Open-Source-Projekte und Entwickler mit begrenzter Erfahrung mit dem verwendeten Tool.

Zusammen gelesen sagen die Studien drei Dinge. Einen Assistenten einzuführen ist einfach. Der Gewinn hängt vom Prozess drumherum ab. Und niemandes Eindruck von der eigenen Geschwindigkeit ist ein Beleg. Also stecken wir den Aufwand in den Prozess (Anweisungen, Prüfungen und Freigabepunkte) statt in die Wahl des Tools.

Was der Assistent in unserem Repository tut

Wir nutzen Claude Code. Fünf Bausteine machen seine Arbeit vorhersehbar.

Projektanweisungen. Eine Datei im Wurzelverzeichnis des Repositorys sagt dem Assistenten, was wo liegt, welche Regeln hart sind und welche Befehle auszuführen sind. Sie ist versioniert wie Code, sodass eine Änderung an den Regeln im Review wie jede andere Änderung auftaucht. Jeder mit Zugriff auf das Repository kann genau lesen, was dem Assistenten gesagt wurde.

Skills für wiederkehrende Aufgaben. Ein Skill ist ein kurzes schriftliches Verfahren, dem der Assistent für eine Art von Aufgabe folgt. Wir haben acht: eine Fallstudie mit ihrem Evidenz-Eintrag aufschreiben, eine Engineering-Notiz entwerfen, einen Beitrag für die Unternehmensseite entwerfen, ein Profil für eine externe Plattform erzeugen, Text auf vertrauliche Namen und personenbezogene Daten prüfen, ein reines Lese-Audit der Vertrauenssignale der Website, einen wöchentlichen Statusbericht und die Triage eingehender Anfragen. Jeder Skill legt fest, wo er aufhört. Keiner davon endet mit einer Veröffentlichung.

Hooks. Die Aktionen des Assistenten laufen durch Skripte, die wir geschrieben haben. Nachdem er eine Datei bearbeitet hat, wird diese Datei auf vertrauliche Namen und personenbezogene Daten gescannt, und ein Fund schickt den Assistenten zurück, um ihn zu beheben. Bevor er einen git commit oder push ausführen kann, lässt ein Guard den Vertraulichkeitsscan und den Claims-Lint über das laufen, was den Working Tree gleich verlassen soll. Jeder Fund blockiert den Befehl. Ein gewöhnlicher git pre-commit Hook wendet dieselben Prüfungen auf von Hand erstellte Commits an.

CI bei jedem Push und Pull Request. Die Pipeline führt Lint, Typprüfungen und einen Build aus, dann drei Guards:

  • den Vertraulichkeitsscan, über Quellcode, Inhalte und das gerenderte HTML. Fehlt seine Konfiguration, schlägt er fehl, statt stillschweigend durchzulaufen;
  • den Claims-Lint, der eine Liste von Superlativen und Formulierungen mit geliehener Autorität ablehnt;
  • den Content-Validator, der eine Fallstudie ohne Evidenz-Eintrag ablehnt, ein Referenzdesign, das gemessene Zahlen behauptet, und eine Zahl auf der Startseite, die nicht auf die Fallstudie verlinkt, aus der sie stammt.

Diese Regeln sind absichtlich mechanisch. Ein Assistent produziert schnell plausiblen Text, und plausibel, aber falsch ist genau der Fehler, den die Umfragen beschreiben. Eine Regel, die bei jedem Commit läuft, hängt nicht davon ab, dass sich jemand, Mensch oder Modell, erinnert, sorgfältig zu sein.

Die Content-Pipeline. Alles, was für die Öffentlichkeit bestimmt ist, durchläuft drei Ordner: Entwürfe, freigegeben, veröffentlicht. Ein Skill kann in die Entwürfe schreiben und nirgendwohin weiter. Nur der Inhaber führt den Freigabeschritt aus, der beide Scans erneut laufen lässt, bevor er die Datei verschiebt. Veröffentlichen geschieht manuell: Ein freigegebener Beitrag wird dem Inhaber als einfügefertiger Text geschickt, und eine freigegebene Notiz geht erst mit dem nächsten freigegebenen Push auf main live. Diese Notiz hat diesen Weg genommen. Ein Assistent hat sie aus den eigenen Dateien des Repositorys entworfen, die Scans liefen darüber, und sie hat diese Seite erreicht, nachdem ein Mensch sie freigegeben hat.

Was wir nie delegieren

Fünf Entscheidungen bleiben bei Menschen, egal was die Tools können.

  1. Die Kennzahl mit dem Kunden vereinbaren. Welche Zahl Erfolg definiert, wie sie gemessen wird und welche Schwelle als erledigt gilt. Wir schreiben sie in den Vertrag, bevor das Training beginnt. Ein Assistent kann mögliche Kennzahlen auflisten. Er kann nicht wissen, auf welche Ihr Unternehmen reagieren wird.
  2. Beurteilen, ob sich ML lohnt. Manchmal ist die ehrliche Antwort eine Regel, ein Report oder eine Prozessänderung. „Noch kein ML“ ist eine Empfehlung, die wir aussprechen, und sie ist ein Urteil über Ihre Situation, keine Aufgabe zur Textgenerierung.
  3. Releases freigeben. Ein Merge auf main deployt. Nichts wird ohne ausdrückliches Ja des Inhabers auf main gepusht, und die Berechtigungen des Assistenten schließen Force-Pushes aus.
  4. Mit dem Kunden sprechen. Telefonate, schriftliche Antworten, schlechte Nachrichten. Ein Skill kann eine Antwort auf eine Anfrage entwerfen; ein Mensch liest sie, bearbeitet sie und schickt sie ab. Kein Skript kontaktiert einen Lead.
  5. Entscheiden, was öffentlich wird. Beiträge, Notizen, Profile, Fallstudien und Code-Releases. Die Pipeline macht Veröffentlichen zu einem bewussten Schritt statt zum Standard.

Der gemeinsame Nenner ist Verantwortung. Jede dieser Entscheidungen hat Folgen, für die jemand einstehen muss, und dieser Jemand muss ein Mensch sein. In einem Projekt ist es der eine namentlich benannte Engineer, der vom Anfang bis zum Ende bei der Arbeit bleibt.

Was wir nicht gemessen haben

Wir haben keine Vorher-Nachher-Zahl für unsere eigene Produktivität, und wir werden keine nennen. Das Ergebnis von METR ist der Grund: Entwickler, die 19% langsamer waren, glaubten, 20% schneller zu sein. Ein Eindruck, auch unserer, ist keine Messung.

Wenn wir eine Zahl veröffentlichen, trägt sie dasselbe Evidenz-Label wie unsere Fallstudien (gemessen, geschätzt oder illustrativ), und sie wird aus Aufzeichnungen wie diesen stammen, gesammelt über einen angegebenen Zeitraum:

  • Zeit vom Öffnen eines Issues bis zu einer geprüften, gemergten Änderung, für vergleichbare Aufgabentypen;
  • der Anteil gemergter Änderungen, die innerhalb von 14 Tagen zurückgenommen oder korrigiert wurden;
  • vor dem Merge von Hooks und CI gefundene Probleme, im Vergleich zu danach gefundenen Fehlern;
  • Review-Zeit pro Änderung, weil im Review die Ausgabe eines Assistenten Menschen Zeit kostet;
  • Stunden pro Meilenstein im Vergleich zur Schätzung aus unserem Rechner.

Bis dahin ist die ehrliche Aussage enger. Die Prüfungen laufen bei jeder Änderung, und die fünf Entscheidungen oben treffen Menschen.

Was das für Sie bedeutet

Mehr Routinearbeit wird erledigt. Bei festem Budget sind Tests, Dokumentation, Monitoring und Release-Prüfungen das, was kleine Teams zuerst streichen. Ein Assistent macht sie billiger zu schreiben, und die Prüfungen machen es schwer, sie auszulassen.

Der Preis geht an das Urteilsvermögen. Unsere Sätze und die Stunden hinter jeder Rolle sind auf der Preisseite veröffentlicht, und der Rechner zeigt die Rechnung. Die wichtigsten Stunden sind die für die Kennzahl, die Evaluation und die Integration in Ihren Prozess: die Teile, die kein Assistent für uns erledigt. Wenn Sie nicht sicher sind, ob ML die richtige Antwort ist, gibt der kostenlose Teardown in sechs Fragen ein erstes Urteil, und eine kurze bezahlte Discovery klärt es, bevor ein Modell trainiert wird.

Sie können das Setup prüfen. Das Repository liegt vom ersten Tag an in Ihrer Organisation. Arbeitet ein Assistent darin, liegen seine Anweisungen und Prüfungen ebenfalls in diesem Repository, neben der Historie jeder Änderung, wo Sie sie lesen können.

Stellen Sie jedem Anbieter dieselben Fragen. Welche KI-Tools sehen Ihren Code und Ihre Daten, und zu welchen Bedingungen? Welche Prüfungen laufen bei jeder Änderung, und blockieren sie oder warnen sie nur? Wer gibt ein Release frei? Hat der Anbieter seine eigene Beschleunigung gemessen, und wie? Die Antworten zeigen Ihnen, ob KI in deren Prozess Disziplin verstärkt oder deren Fehlen.

Quellen

Haben Sie einen Prozess, der zu viel kostet?

Erzählen Sie uns davon. Das erste Gespräch ist kostenlos, und wenn KI nicht die Antwort ist, sagen wir das.

Aufgabe besprechen