So funktioniert strukturiertes Coding mit KI-Agenten wirklich

Die meisten Gespräche über KI-gestütztes Programmieren bleiben auf der Ebene von Eindrücken stecken. Jemand sagt, das Modell "schreibt jetzt einfach den Code" und lässt dich selbst herausfinden, was das bedeutet. Dann sitzt du Dienstagnachmittag vor einer echten Deadline und einem nicht sauberen Codebase.

Dieser Graben zwischen Demo und Disziplin ist da, wo die meisten Agenturen in Schwierigkeiten geraten. Sie schnappen sich einen Coding-Agenten, starten ein Projekt und stellen nach drei Tagen fest, dass sie einen Haufen plausibel aussehenden Code produziert haben, der keine kohärente Struktur hat. Das Modell war hilfreich. Der Prozess war es nicht.

Wie wir das bei Studio Hyra sehen, erklärt dieser Text. Phase für Phase, wie ein disziplinierter, agenten-gestützter Coding-Prozess wirklich aussieht. Basierend auf echter Client-Arbeit. Kein Tutorial. Eher Notizen aus dem Feld.

Mit einer Spezifikation beginnen, über die das Modell diskutieren kann

Der größte Fehler beim agenten-gestützten Programmieren ist, das Modell als Syntax-Suchmaschine zu behandeln. Du formulierst eine vage Absicht, es gibt dir plausiblen Code zurück, du fügst ihn ein, Wiederholung. Das funktioniert, bis es spektakulär nicht funktioniert.

Die Phase, die die meisten Teams überspringen, ist die Spezifikation. Bevor du ein Chat-Fenster öffnest, brauchst du eine schriftliche Beschreibung dessen, was du baust. Konkret genug, dass jemand widersprechen kann. Nicht ein PRD für einen Produktmanager. Ein technisches Briefing: die Datenstruktur, die Einschränkung, der Edge Case, den du bereits kennst, das, was du nicht machen wirst.

Wir schreiben diese in reines Markdown. Ein paar hundert Wörter reichen. Das Ziel ist, dem Modell etwas zu geben, das es hinterfragen kann. Wenn wir das Briefing teilen und das Modell auffordern, Lücken zu kennzeichnen, findet es fast immer eine oder zwei. Dieses Gespräch, bevor eine einzige Zeile Code geschrieben wird, ist oft der wertvollste Teil der ganzen Session.

In kleinen, überprüfbaren Schritten arbeiten

Wenn es die Spezifikation gibt, ist der erste Gedanke, alles dem Modell in die Hand zu geben und es laufen zu lassen. Widerstehe dem. Das Output wird lang sein, lokal kohärent und global verwirrt. Du wirst mehr Zeit damit verbringen zu verstehen, was es gebaut hat, als es zum Bauen brauchte.

Die Disziplin ist Granularität. Zerlege die Arbeit in Einheiten, die klein genug sind, dass du das Output jeder einzelnen in unter zehn Minuten lesen und verstehen kannst. Eine Funktion, eine Komponente, eine Migration, eine Test-Suite für ein Modul. Frag das Modell, diese Einheit zu vervollständigen, dann stop.

Überprüfe jeden Schritt wie ein Peer, nicht als Nutzer. Frag dich selbst: Löst das das richtige Problem, oder das Problem, wie ich es beschrieben habe? Das sind oft unterschiedliche Dinge. Das Modell tut genau, was du fragst. Wenn deine Frage leicht falsch war, ist der Code leicht falsch, und der nächste Schritt verstärkt diesen Fehler.

Wir führen während Sessions eine laufende Notiz-Datei. Jeden Schritt bekommt eine einzeilige Notiz: was sich geändert hat und warum. Klingt mühsam und dauert etwa neunzig Sekunden pro Schritt. Wenn drei Stunden später etwas bricht, ist die Notiz-Datei das einzige, was die Debugging-Session kurz macht.

Das Session-Grenzenproblem

Context Windows sind jetzt lang genug, dass die meisten Leute nicht mehr über Session-Grenzen nachdenken. Das ist ein Fehler.

Jede Coding-Session hat eine Form. Am Anfang hat das Modell deine Spezifikation, deinen Code, deine Gesprächshistorie und ein klares Bild der Absicht. Je länger die Session läuft, desto mehr verdünnt sich dieses Bild. Alte Annahmen bleiben im Context. Überarbeitete lagern sich darauf. Das Modell ist nicht verwirrt, genau genommen, aber es arbeitet von einem zunehmend komplizierten und teilweise widersprüchlichen Bild aus.

Wir behandeln das Ende einer Session als Zwangsmechanismus. Bevor wir schließen, bitten wir das Modell, eine Zusammenfassung dessen zu schreiben, was gebaut wurde, welche Entscheidungen getroffen wurden und was noch offen ist. Das geht in eine Datei namens HANDOFF.md im Projekt-Root. Die nächste Session öffnet sich, indem sie diese Datei liest.

Die Handoff-Notiz ist auch nützlich für den Menschen. Es gibt eine bestimmte Art von kognitiver Ermüdung, die aus langen Agent-Sessions kommt, bei denen du dich produktiv fühlst, weil viel passiert ist, aber du vergessen hast, warum die frühen Entscheidungen getroffen wurden. Die Handoff-Notiz ist ein Aufzeichnung deines Denkens, nicht nur des Model-Outputs.

Wenn das Modell selbstbewusst und falsch wird

Das Schwierigste bei jedem Coding-Modell ist die Kalibrierung des Confidence-Signals. Das Modell schreibt im gleichen Ton, egal ob es eine Lehrbuch-Lösung produziert oder eine halluzinierte API, die es gar nicht gibt. Es gibt keine Unsicherheit in der Stimme.

Das ist kein Fehler, den man durch Engineering umgehen kann. Es ist eine Eigenschaft des Systems. Die Milderung kommt durch Prozess, nicht durch Prompting.

Zwei Praktiken helfen. Erstens. Wenn das Modell eine Bibliothek, ein Pattern oder eine Third-Party-Integration vorschlägt, die du selbst noch nicht verwendet hast, überprüfe es bevor du darauf aufbaust. Nicht die Dokumentation, das echte Verhalten. Schreib einen kleinen isolierten Test. Fünf Minuten Überprüfung können einen Tag Entwirren sparen.

Zweitens. Frag das Modell, gegen seinen eigenen Vorschlag zu argumentieren, bevor du ihn akzeptierst. Etwa so: "Was sind die Hauptgründe, warum dieser Ansatz für diesen Kontext falsch sein könnte?" Die Antworten sind manchmal defensiv und dünn. Aber manchmal deckt das Modell ein echtes Risiko auf, das es heruntergespielt hatte. Diese Asymmetrie ist ein paar Extra-Prompts wert.

Agenturen, die mit diesen Tools schnell vorgehen, bauen üblicherweise einen dedizierten Review-Punkt am Ende jeder Phase ein, wo jemand, der den Code nicht geschrieben hat, ihn kalt liest. Nicht um Bugs zu finden, zwingend. Um die Stellen zu finden, wo der Code technisch richtig und konzeptuell daneben ist. Das Modell ist gut beim ersten. Es braucht Hilfe beim zweiten.

Was das für die Besetzung deiner Projekte bedeutet

Agenten-gestütztes Programmieren verändert die Rolle mehr als die Kopfzahl, zumindest kurzfristig.

Die Person, die das Modell lenkt, muss technisch versiert genug sein, um Output auf der Logik-Ebene zu überprüfen, nicht nur auf der visuellen Ebene. Sie muss kein Senior Engineer sein. Aber sie muss verstehen, was der Code tun soll, und sie muss bemerken, wenn er stattdessen etwas Ähnliches tut.

Was bei Agenturen oft schiefgeht, ist, dass das Modell an jemanden gegeben wird, dessen Stärke woanders liegt. Ein Designer, der ein bisschen programmiert, ein PM, der technisch neugierig ist. Das sind keine schlechten Menschen. Sie sind in der falschen Rolle. Das Modell wird flüssigen, zerbrochenen Code produzieren und sie wissen es nicht, bis ein Client ihn anstarrt.

Die praktische Konsequenz. Halte eine technisch fundierte Person bei jedem agenten-gestützten Build in der Nähe, auch wenn sie selbst keinen Code schreiben. Ihre Aufgabe ist nicht zu tippen. Ihre Aufgabe ist zu lesen, was das Modell produziert hat, und zu entscheiden, ob die Richtung stimmt.

Das ist letzten Endes, worauf der ganze Prozess hinausläuft. Das Modell erledigt die Arbeit schnell. Das Handwerk liegt darin, es präzise zu lenken, es ehrlich zu überprüfen und zu wissen, wann man stoppen und neu spezifizieren muss, anstatt weiterzumachen. Dieser Teil hat sich gar nicht geändert.