Zum Hauptinhalt springen
Zurück zum Blog
KI

Mit KI programmieren, ohne sich täuschen zu lassen

Von ···4 Min. Lesezeit
Gouache: eine Wasserwaage mit türkisfarbener Libelle auf einem Holzregal an einer hellen Wand; darunter auf einem Brett ein kleiner geschnitzter Holzbaum, ein Bleistift und drei Schrauben.

Ein Coding-Agent, der eine Aufgabe abschliesst, schreibt oft «Behoben». Genau hier liegt die Gefahr. Hat der Agent keine Werkzeuge erhalten, um seine Arbeit selbst zu prüfen, ist dieser Satz oft falsch. Er führt zu Korrekturen, die nichts beheben, und manchmal zu schweren Störungen im Betrieb.

Wir verlangen deshalb von jedem Agenten einen Beleg, den er selbst beschafft hat. Ohne ihn ist die Aufgabe nicht erledigt. Diese Regel bestimmt, was wir der KI übertragen, was das Team prüft und was Sie mit jeder Lieferung erhalten.

Kein Beleg, kein «erledigt»

Ein Sprachmodell schreibt die wahrscheinlichste Fortsetzung eines Textes. Nach einer Korrektur ist «behoben» die wahrscheinlichste Fortsetzung, ob die Korrektur funktioniert oder nicht. Erst die Beobachtung des Ergebnisses entscheidet. Ein Ingenieur von Cursor hat daraus ein Prinzip seiner Methode pstack · Prove it works gemacht: «Es kompiliert» beweist nichts, der Agent muss das tatsächliche Ergebnis beobachten.

Jeder Agent legt deshalb einen Beleg für seine Meldung bei: den Test, der vorher fehlschlug und jetzt besteht, Screenshots der Seite auf Smartphone und Computer. Konnte er etwas nicht prüfen, schreibt er «nicht geprüft».

Was ein Agent selbst prüfen können muss

Belege zu verlangen, nützt nichts, wenn der Agent sie nicht beschaffen kann. Deshalb geben wir ihm die Mittel, seine Arbeit zu kontrollieren.

  • Die aktuelle Dokumentation der Werkzeuge, die er verwendet, damit er nachprüft, ob es eine Funktion gibt, statt sich daran zu erinnern.
  • Eine Karte der Abhängigkeiten im Code, damit er vor einer Änderung weiss, was sie beschädigen kann.
  • Einen Browser und Simulatoren, um jede Seite auf Smartphone, Tablet und Computer zu öffnen.
  • Ablauftests, in denen ein Agent ein Ziel wie «auf das Pro-Angebot wechseln» verfolgt und eine exakte Prüfung das angezeigte Ergebnis kontrolliert.

Meldet ein Agent einen Fehler, muss er ihn mit einem Test reproduzieren, bevor wir ihn berücksichtigen. Dieser Test bleibt danach im Produkt und spielt das Szenario bei jeder Änderung erneut ab.

Was wir einem Agenten übertragen

Unser Kriterium ist eine Frage. Lässt sich das Ergebnis prüfen, ohne den ganzen Code zu lesen? Erik Schluntz, Ingenieur bei Anthropic, vergleicht in seinem Vortrag Vibe coding in prod eine Anwendung mit einem Baum. Mit diesem Bild entscheiden wir, wo die menschliche Prüfung ansetzt.

Wo die menschliche Prüfung ansetzt

  1. Blätter

    Ein Berichtsbildschirm, ein Export, eine Administrationsseite.

    Einem Agenten übertragen, an getesteten Ergebnissen beurteilt.

  2. Äste

    Ein Buchungsablauf, ein gemeinsames Formular.

    Getestete Schnittstellen. Jede Änderung daran wird geprüft.

  3. Stamm

    Daten, Zugriffsrechte, Zahlungen.

    Vom Team verstanden und bei jeder Änderung geprüft.

Blätter sind die Funktionen, von denen nichts abhängt. Sind ihre Ein- und Ausgaben getestet, genügt ihr Ergebnis, um sie zu beurteilen. Der Stamm trägt die Daten, die Zugriffsrechte und die Zahlungen. Das Team versteht und prüft ihn, weil alles andere davon abhängt und kein Test technische Schuld misst.

Jeder zusätzliche Test macht einen weiteren Teil prüfbar und damit für einen Agenten übertragbar. Deshalb dient fast ein Drittel des Codes, den wir schreiben, dazu, den Rest zu prüfen.

Was das Team entscheidet

Der Agent setzt schnell um. Zu entscheiden, was umgesetzt wird und woran man erkennt, dass es richtig ist, bleibt Aufgabe des Teams.

Die richtigen Fragen, vor der ersten Codezeile. Was passiert, wenn eine Zahlung mittendrin scheitert? Wer darf die Daten eines anderen Kunden sehen? Was macht die App ohne Verbindung? Ein Agent stellt diese Fragen nicht von sich aus. Sie stellen zu können, kommt aus ausgelieferten Projekten und behobenen Ausfällen. Erik Schluntz betont dasselbe: Ohne die richtigen Fragen steuert man einen Agenten nicht, man ist ihm ausgeliefert.

Die Architektur. Die Grenzen zwischen den Modulen, die gemeinsamen Daten und das, was sich weiterentwickeln können muss, bilden den Stamm der Anwendung. Ein Agent übernimmt die Struktur, die er vorfindet, ob gut oder schlecht. Deshalb muss das Team sie entwerfen.

Die Definition von «erledigt». Vor jeder Aufgabe hält das Team fest, was zutreffen muss, damit sie fertig ist: die abzudeckenden Fälle, die erwarteten Ergebnisse, die zu prüfenden Bildschirme. Ein Test kann mit einem falschen Ergebnis bestehen, wenn das erwartete Ergebnis falsch ist. Der Betrag einer Rückerstattung, eine Stornoregel oder die Rechte einer Person werden deshalb mit Ihnen entschieden und dann in den Tests festgehalten. Danach schreibt der Agent den Code, der sie erfüllt.

Produktionsreifer Code

Jede Weiterentwicklung kommt getestet und auf Smartphone und Computer geprüft, mit der Adresse der Version, die Sie abnehmen. Sie prüfen das Ergebnis selbst, bevor es live geht.

Vier Fragen an Ihre Entwickler

  1. Wie belegen Ihre Agenten, was sie melden?
  2. Welche Teile meines Produkts prüft ein Mensch, und warum gerade diese?
  3. Wer legt die erwarteten Ergebnisse in den Tests fest?
  4. Was erhalte ich, um eine Weiterentwicklung abzunehmen?

Möchten Sie eine bestehende Anwendung übernehmen oder eine neue mit dieser Methode aufbauen? Sprechen wir darüber.

Quellen und Referenzen

Zurück zum BlogGaspard Chevassus · CEO, Appik Studio