Ask HN: Wie gehe ich damit um, KI-generierten Code auszuliefern, den ich nicht verstehe?

Ich habe mit https://getchronosphere.com herumgespielt. Es wird (versuchen), einen PR in einer zusammenhängenden Reise statt als massiven Klumpen wieder aufzubauen. Bisher war es einigermaßen hilfreich und wird noch besser.

Technisch gesehen ist es nur ein Rollenwechsel. Du bist jetzt der Projektmanager oder so, nicht der Entwickler. Es ist nicht die Aufgabe eines Projektmanagers, den Code zu verstehen, sondern nur sicherzustellen, dass er tut, was er soll, und nicht tut, was er nicht soll. Und sicherzustellen, dass die Entwickler usw. nicht blockiert sind und gute Arbeit leisten. Nimm die neue Rolle an.

So fühlt sich jeder Produktmanager jeden Tag.

Wenn du als LLM-Prompter Produkte auslieferst, sind deine Ergebnisse eher mit denen eines Produktmanagers vergleichbar, nicht mit denen eines Softwareentwicklers.

Ich komme langsam zu der Ansicht, dass ich damit zufrieden bin, wenn es funktioniert. Früher habe ich auch nicht persönlich die Arbeit all meiner Kollegen überprüft, ich habe einfach darauf vertraut, dass sie gute Arbeit geleistet haben.

Das heißt nicht, dass ich einem LLM blind vertraue – mein Projekt ist ein autovektorisierender Compiler. Ich lasse es eine Unmenge an Tests schreiben, und ich habe echte, nicht-triviale Programme, die es kompiliert hat. Ich lasse es vor Releases ein 'Gate' durchlaufen, das buchstäblich Stunden auf 5 verschiedenen Architekturen dauert. Zu sagen, dieser Code sei getestet, ist … eine maßlose Untertreibung.

Ich denke, was hilft, ist eine lange Planungssitzung, ins Detail gehen, Randfälle ausarbeiten, Testfälle entwerfen, na ja, Arbeit und Mühe. Wenn das erledigt ist, ist es einfacher, es die Nacht durcharbeiten zu lassen und ein wichtiges Produktionsfeature umzusetzen.

Ich überprüfe den Code immer noch, aber Hand aufs Herz, ich könnte nicht sagen, dass ich alles überprüft hätte, manchmal übersehe ich etwas in einem komplizierten Check-in. Ich versuche, Check-ins klein und überschaubar zu halten, aber manchmal ist das neben der Regel "nichts kaputt machen" nicht leicht zu bewerkstelligen.

Also läuft es darauf hinaus: Ich arbeite seit etwa 6 Monaten daran, und bisher hat es für mich funktioniert. So ähnlich, wie man sich über einen längeren Zeitraum an die Eigenheiten eines Kollegen gewöhnt.

Ich muss sagen, dass die Codequalität meiner Erfahrung nach ziemlich hoch ist. Vielleicht liegt das an der vorherigen Anstrengung in der Planungsphase, ich weiß es nicht, aber ich scheine nicht unter dem 'Slop' zu leiden, über den sich die Leute beschweren. YMMV.

Es ist nicht unähnlich dem Leben als Principal-Level-Engineer vor der KI. Du beaufsichtigst technisch die Arbeit vieler Ingenieure an ihren eigenen Systemen, aber du könntest unmöglich den gesamten Code selbst überprüfen. Du erkennst an, dass menschliches Code-Review die Anzahl und Schwere der in die Produktion ausgelieferten Fehler reduziert, aber nicht beseitigt. Du hast nicht die Details auf niedriger Ebene im Kopf, nur die auf hoher Ebene. Du gestaltest, wie all diese Ingenieure miteinander interagieren, ohne jemandem auf die Füße zu treten.

Die Zeit wird zeigen, ob es richtig war, von einem System, in dem wir Menschen das Verständnis des Systems auf niedriger Ebene zutrauten, zu einem zu wechseln, in dem wir ausgeklügelten Taschenrechnern vertrauen. Aber bisher funktioniert es.

Testgetriebene Entwicklung und die Testpyramide.

Wenn der Agent Tests geschrieben und – entscheidend – gesehen hat, wie sie fehlschlagen, bevor er mit der Arbeit begann, sie zum Laufen zu bringen, hast du viel Vertrauen.

Die Überprüfung deiner eigenen Arbeit ist auch einfacher – Test- und Produktionscode spiegeln sich oft gegenseitig, was dir ein viel vollständigeres Bild gibt. Verwirrt vom Produktionscode? Lies eine Weile seine Tests und komm dann zurück.

Es ist auch einfacher, die Änderung zu verstehen, wenn du beim Build dabei warst, das Transkript beobachtet und ab und zu reingeschaut hast. Es muss nicht deine Hauptaufgabe sein – lass es auf einem zweiten Monitor laufen, es wird dir von selbst ins Auge fallen.

Und schließlich, zusätzlich zur testgetriebenen Entwicklung, lass den Agenten zuerst (vor dem ersten testgetriebenen Entwicklungszyklus) einen End-to-End-Test erstellen, der die Arbeit abdeckt, die er erledigen wird. Sobald dieser Test grün ist (testgetriebenes Wort für "besteht"), bist du mit deiner Arbeit fertig und kannst nach Belieben aufräumen.

Spiel damit herum, bevor du es auslieferst, mach es richtig schön. Es war noch nie so einfach, technische Schulden zu bereinigen und die UI perfekt zu machen.

Irgendwann bist du bereit, es in einen PR zu packen!

Jetzt kannst du Agenten nutzen und kreativ werden. Bring deine Kollegen dazu, vor Begeisterung zu schäumen, deine Arbeit zu überprüfen. Erwäge, ein Loom-Video zu machen, um sie durchzuführen. Erwäge, es in eine Commit-Serie umzuarbeiten; es dauert nur ein paar Sekunden für deinen Agenten und du kannst eine Geschichte für Menschen erzählen. Vielleicht möchtest du es nach deinen Kämpfen sequenzieren; vielleicht ist es besser, zu zeigen, wie die verschiedenen Schichten mit jedem Commit entstehen – […]

Formale Verifikation, wähle eine Sprache, die sie integriert hat, und beweise relevante Nachbedingungen.

KI weiß immer noch nicht einmal, wie man Code schreibt, der unmögliche Zustände undarstellbar macht, also wird Testen nicht helfen.