Ihre Agentur schreibt Ihren Code mit KI. Das sollten Sie festlegen, bevor Sie unterschreiben

Ja, Ihre Agentur nutzt mit nahezu an Sicherheit grenzender Wahrscheinlichkeit KI, um einen Teil Ihres Codes zu schreiben, und das ist in Ordnung. Nicht in Ordnung ist KI-generierter Code, den kein Mensch sorgfältig gelesen hat und den kein Test abdeckt, gemerged an einem Freitag, weil die Demo fällig war. Die Lösung ist kein Tool-Verbot. Es ist eine kurze Liste von Kontrollen, die Sie vor dem ersten Sprint in Vertrag und Repository festschreiben.

Warum das heute wichtiger ist als vor zwei Jahren

Ein Entwickler mit einem Coding-Assistenten kann an einem Nachmittag ein funktionierend wirkendes Feature produzieren, für das früher drei Tage nötig waren. Das ist real. Das Problem ist, dass Review, Testing und Verständnis nicht im gleichen Tempo schneller geworden sind. Wenn eine Agentur dieselben Review-Gewohnheiten wie zuvor beibehält und ihren Output verdreifacht, erhalten Sie dieselbe Fehlerquote pro Zeile, nur angewendet auf dreimal so viele Zeilen.

Technical Debt sammelte sich früher im menschlichen Tempo an. Jetzt sammelt sie sich im Maschinentempo an, und sie sieht an der Oberfläche sauber aus. Die erste Version unserer eigenen Outreach-Engine, beschrieben in Abschnitt 4, war eine fünfstufige Kette, die sich wunderbar las: jeder Schritt gut benannt, jede Funktion souverän kommentiert, nichts, worüber ein Reviewer gestolpert wäre. Sie hatte auch fünf Stellen, an denen sie leise versagen konnte, und die saubere Oberfläche war genau der Grund, warum niemand die vier zusätzlichen Schritte hinterfragte. KI-generierter Code ist gut formatiert und gut benannt, und genau das verleitet einen schwachen Reviewer dazu, nur zu überfliegen. Wir haben über die allgemeine Disziplin dahinter in Technical Debt Management geschrieben. Dieser Beitrag behandelt die spezifische Variante, die auftritt, wenn ein Dienstleister den Code schreibt.

Die fünf Dinge, die Sie verlangen sollten

1. Ein Test-Gate, das Merges blockiert, kein Testing-Versprechen

„Wir schreiben Tests" ist ein Satz. Ein Gate ist eine Konfiguration. Verlangen Sie beides, bevor die Arbeit beginnt:

• Branch-Protection auf main, sodass nichts gemerged wird, während die Pipeline rot ist. GitHub dokumentiert das unter Protected Branches, und jeder größere Hosting-Anbieter hat ein Äquivalent.
• Einen in der CI erzwungenen Coverage-Grenzwert, nicht einen, der nur in einer Folie berichtet wird. Auf einem TypeScript-Stack sind das wenige Zeilen in einer Vitest- oder Jest-Konfiguration. Die genaue Zahl ist weniger wichtig als die Tatsache, dass der Build fehlschlägt, wenn sie sinkt.

Stellen Sie dann eine Frage, die Agenturen unterscheidet: „Können Sie mir einen Pull Request aus dem letzten Monat zeigen, der durch einen fehlgeschlagenen Test blockiert wurde?" Lautet die Antwort „unsere Tests schlagen nie fehl", testen die Tests nichts.

2. Ein namentlich benannter Mensch, der jeden KI-generierten Diff liest

Assistenten produzieren Code. Sie übernehmen keine Verantwortung dafür. Ihr Vertrag sollte festlegen, wer das tut, und das Repository sollte es belegen: Jeder Pull Request hat einen Reviewer, der nicht der Autor ist, und das Review enthält Kommentare, nicht nur ein grünes Häkchen.

Achten Sie auf zwei Anti-Patterns:

• Selbst gemergte Pull Requests. Eine Person promptet, dieselbe Person approved. Das ist null Review.
• Review nur durch KI. KI-Review-Bots erkennen Stilfragen und offensichtliche Bugs. Sie wissen nicht, dass Ihre Preisregel eine Mehrwertsteuer-Ausnahme für saudische Kunden hat. Der Mensch, der die Domäne kennt, muss den Diff lesen.

3. Eine Dependency- und Secrets-Richtlinie

KI-Assistenten fügen gerne Pakete hinzu. Sie greifen zu einer Library, um eine Zeichenkette zu formatieren. Jedes davon ist eine Supply-Chain-Angriffsfläche und eine Lizenzfrage. Verlangen Sie:

• Eine committete Lockfile und die Regel, dass neue Abhängigkeiten in der Pull-Request-Beschreibung ausgewiesen werden.
• Keine Secrets, Kundendaten oder proprietären Code in Tools, die mit Eingaben trainiert werden. Die meisten Enterprise-Stufen der großen Assistenten bieten eine No-Training-Einstellung; der Vertrag sollte festhalten, dass die Agentur diese nutzt.
• Eine klare Zuweisung sämtlicher Deliverables an Sie, unabhängig davon, wie sie entstanden sind. Gute Agenturen tun das bereits. Die KI-Klausel schließt nur die Lücke „aber ein Tool hat es geschrieben".

4. Weniger Zeilen, nicht mehr

Der günstigste Code zum Testen ist der Code, der nie geschrieben wurde. KI macht es mühelos, eine sechsstufige Pipeline zu generieren, wo ein Schritt reichen würde, und jeder zusätzliche Schritt ist eine Stelle für einen stillen Fehler.

Das haben wir in unserer eigenen Outreach-Engine erlebt. Sie scrapt die Website eines Interessenten mit einem selbst gehosteten Crawler und nutzt ein lokales Modell, um eine maßgeschneiderte E-Mail pro Unternehmen zu entwerfen. Die erste Version war eine Kette: Fakten extrahieren, zusammenfassen, Ansatz wählen, entwerfen, verfeinern. Sie war langsamer, teurer und, wichtiger noch, sie hatte fünf Stellen, an denen etwas schiefgehen konnte, und fünf Dinge zu testen. Die Zusammenlegung in einen einzelnen Aufruf, der Fakten extrahiert und in einem Durchgang entwirft, übertraf die Kette sowohl bei Kosten als auch bei Output-Qualität und halbierte die Fläche, die wir mit Tests abdecken mussten. Den allgemeinen Fall haben wir in Single Call vs. Agent Chains aufgeschrieben.

Fragen Sie Ihre Agentur, wie sie entscheidet, wann generierter Code zu viel Code ist. Haben sie darauf keine Antwort, zahlen Sie die zusätzlichen Zeilen doppelt: einmal für das Schreiben und einmal für die Wartung.

5. Eine Codebasis, die Sie jemand anderem übergeben könnten

Der eigentliche Test für KI-generierten Code ist, ob ein neuer Entwickler, mit oder ohne Assistenten, ihn innerhalb einer Woche lesen kann. Verlangen Sie:

• Architekturentscheidungen schriftlich im Repository, in einem kurzen Docs-Ordner oder einer ADR-Datei, nicht im Chatverlauf. Halten Sie das Warum fest, nicht nur das Was. Wenn Ihre Agentur eine fünfstufige Kette in einen Aufruf zusammenlegt, wie wir es getan haben, gehört die Begründung neben den Code, sonst wird der nächste Entwickler mit Assistent die Kette wieder aufbauen, denn eine Kette ist das, wonach Assistenten greifen.
• Konsistente Patterns über alle Features hinweg. KI-Assistenten driften. Feature A nutzt einen Data-Access-Stil, Feature B einen anderen, weil sie an unterschiedlichen Tagen geprompted wurden. Linting und ein kleines Set an Templates beheben das meiste davon.
• Integrationstests für die Flows, die Ihnen Geld einbringen: Signup, Checkout, der Webhook Ihres Zahlungsanbieters. Unit-Tests auf Helper-Funktionen sind billige Füllmasse. Die Mehrwertsteuer-Ausnahme aus Abschnitt 2 ist genau die Art von Regel, die nur ein End-to-End-Test auf einem echten Checkout erfasst, und diese drei Pfade mit einem Tool wie Playwright abzudecken, schützt Ihren Umsatz.

Was das für das Angebot bedeutet

Erwarten Sie, dass faire Angebote beim Boilerplate-Code sinken: CRUD-Screens, Formulare, Admin-Tabellen, Standard-Integrationen. Erwarten Sie, dass sie bei den Teilen, die nie durch Tippgeschwindigkeit limitiert waren, weitgehend gleich bleiben: Datenmodell, Edge Cases in Ihren Geschäftsregeln, Performance und das Review selbst.

Eine Agentur, deren Angebot seit der Einführung von KI-Tools über die gesamte Breite um 60 Prozent gesunken ist, hat entweder beim Review gespart oder ist kurz davor. Eine, deren Angebot sich überhaupt nicht bewegt hat, gibt die Ersparnis wahrscheinlich nicht weiter. Der ehrliche Mittelweg ist eine niedrigere Zahl bei der vorhersehbaren Arbeit und ein Posten für Testing und Review, der nicht geschrumpft ist. Wenn Sie zwischen Engagement-Modellen abwägen, finden Sie in Fixed Price vs. Time and Materials, wie Sie das strukturieren.

Fragen für das erste Gespräch

• Welche KI-Coding-Tools nutzen Sie, und in welcher Stufe?
• Zeigen Sie mir Ihre Branch-Protection und CI-Konfiguration bei einem aktuellen Projekt.
• Wer reviewt KI-generierten Code, und kann ich einen Pull Request mit echten Review-Kommentaren sehen?
• Wie entscheiden Sie, wann generierter Code zu viel Code ist?
• Was geschieht mit meinem Code und meinen Daten innerhalb der Tools, die Sie nutzen?

Klare, konkrete Antworten bedeuten, dass die Agentur sich damit beschäftigt hat. Vage Beschwichtigung bedeutet, dass Sie der erste Kunde sind, der danach fragt. Kombinieren Sie das mit den allgemeineren Red Flags bei Softwareprojekten, und Sie filtern den größten Teil des Risikos in einem einzigen Gespräch heraus.

Das Fazit

KI-Coding-Tools sind ein Geschwindigkeitsmultiplikator. Multiplizieren Sie ein disziplniertes Team, erhalten Sie ein diszipliniertes Team, das schneller ausliefert. Multiplizieren Sie ein schlampiges, erhalten Sie Schlamperei in großem Maßstab, mit einer Codebasis, die großartig aussieht, bis der erste echte Vorfall eintritt. Ihre Aufgabe als Auftraggeber ist nicht, das Tool auszuwählen. Sie besteht darin, das Gate, den Reviewer, die Richtlinie und das lesbare Repository zu verlangen – und dann zu prüfen, ob es sie tatsächlich gibt.

Wenn Sie ein Projekt wollen, bei dem die Tests in der Pipeline liegen und der Reviewer vor dem ersten Commit feststeht, sprechen wir.