Für einen Großteil der Menschheitsgeschichte haben wir Codequalität per Code-Review bewertet: Jemand liest, was du geschrieben hast, und stellt sicher, dass es sauber, durchdacht, schnell, verständlich und gut getestet ist. Bei Agenten skaliert dieser Ansatz nicht gut; es gibt einfach zu viel Code, als dass ihn jemand lesen könnte. Infolgedessen müssen immer mehr unserer Qualitätsprüfungen im Harness, in der Umgebung und im Betriebssystem rund um den Agenten stattfinden. Ich lese und überprüfe Code immer noch, bin aber sehr bewusst darin, wo ich Einschränkungen als Prüfung akzeptiere.
Softwarequalität hängt heute von den Einschränkungen ab, die du um deine Agenten setzt.
Guillermos Liste ist ein guter Test dafür, ob du es dir leisten kannst, das Lesen auszulassen. Beachte, dass jedes „Ja“ eigentlich eine Aussage darüber ist, wie gering das Risiko ist – keine Nutzer, Wegwerfcode, Prototyp. Sobald das Risiko steigt, muss etwas den Code lesen. Wenn du es nicht bei jedem Diff bist, dann müssen es die Einschränkungen sein.
Einschränkungen definieren, was das System tun darf, indem sie Tests und deterministische Einschränkungen gegen die Vorschläge eines Agenten werfen. Indem wir diese Einschränkungen setzen und aufrechterhalten, bauen wir Schleifen, die zuverlässig hochwertige Produktionssoftware liefern, selbst wenn Agenten jeden Tag Hunderttausende oder Millionen von Änderungen erzeugen.
Wir nennen diese Einschränkungen Qualitäts-Gates, und sie haben viele Formen.
Dazu gehören herkömmliche Unit-Tests, Property-Tests und Abnahmetests. Dazu gehören Mutationstests, bei denen wir Codevarianten erzeugen, sie gegen dieselben Tests laufen lassen und sicherstellen, dass niemand Fehler einschmuggelt, die uns entgehen. Dazu gehören Metriken zur Codequalität wie zyklomatische Komplexität und Zeilenlänge, die helfen, die Lesbarkeit zu erhalten.
Zwei Menschen können unterschiedlicher Meinung darüber sein, ob man den Code lesen sollte, und sich trotzdem auf den Mechanismus einigen. Guillermo liest ihn. Bob liest nichts davon. Beide beschreiben einen Hürdenlauf – der Unterschied ist nur, ob ein Mensch darin sitzt (ich unterstütze Bobs andere Ansichten nicht).
Einschränkungen spielen auch eine wichtige Rolle dabei, welche Vorschläge das System als Codeänderungen annimmt und anwendet. Wenn ein Änderungsvorschlag vom Interpreter, der den Agenten ausführt, zum Agent-Controller und weiter in die Produktion gelangt, haben wir genügend Prüfungen durchgeführt, um sicher zu sein, dass er sicher ausgeliefert werden kann und die Auswirkung der Änderung deutlich im Rahmen des Agenten liegt.
Ein Agent kann alles vorschlagen. Deine Einschränkungen entscheiden, ob ein Vorschlag sicher genug, korrekt, im Rahmen und nützlich ist, um von dir und deinem Team ausgeliefert zu werden.
Dieses Modell bietet viel, lässt aber auch viele Teile aus, und diese Auslassungen sind es wert, heute darüber nachzudenken. Ein Thema ist Autonomie; Agenten mögen ihre Absichten gut umsetzen, scheitern aber möglicherweise, wenn Informationen fehlen oder wenn das, was sie versuchen, mehrdeutig ist. Das gilt sowohl für die Aufgabe selbst als auch dafür, wie sie vom Harness, der Umgebung und anderen Komponenten parametrisiert wird.
Viele der Gründe, warum Menschen es nicht schaffen, großartigen Code auszuliefern, gelten auch für Agenten: fragile Umgebungen, die unter skriptgesteuertem Stress nicht standhalten, nichtdeterministische Builds, fehlende Berechtigungen und schwache Tests. Das spricht für eine bessere Umgebung, die Agenten vertrauenswürdiges Feedback gibt, schadensarme Fehlermodi erlaubt und es einfacher macht, Erfolg schrittweise aufzubauen.
Die Umgebung, die wir anstreben, ist eine, in der ein Agent echte Arbeit leisten, Feedback bekommen, dem er vertrauen kann, und scheitern kann, ohne großen Schaden anzurichten.
Das andere wichtige Thema ist Vertrauen. Wir können Absichten nicht gutgläubig an etwas übergeben, das selbst so intelligent und robust wie ein moderner Agent ist, ohne die Korrektheit zu überprüfen. Wir beginnen mit Vertrauen, aber es muss hart erarbeitet sein.
Einige Einschränkungen formen die Arbeit, bevor sie beginnt. Andere geben Feedback, während der Agent arbeitet. Wieder andere entscheiden, ob seine Ausgabe überhaupt die Produktionsgrenze überschreiten darf.
Es gibt viele Möglichkeiten zu modellieren, wie wir eine Verifikationsstruktur um ein System legen.
Meiner Erfahrung nach hilft es, eine breitere, aber bewusst gewählte Reihe von Prüfungen für deine Einschränkungen zu haben, anstatt dich nur auf Unit-Tests zu verlassen. Die Idee ist, dass jede Prüfung eine eigene Verantwortung hat, die von Typsicherheit und Leistung bis zum Security-Scan in späteren Phasen reichen kann. Leute können auch ihre eigenen Einschränkungen definieren, einschließlich Architekturregeln, die Linting-Tools wie ESLint durchsetzen können. Viele dieser Tools haben eingebaute Hooks, mit denen sich Agenten oder Menschen einbinden lassen, wenn etwas schiefgeht.
Derzeit läuft ein Großteil des Unterschieds zwischen nützlicher Agenten-Ausgabe und Schrott auf die Fähigkeiten des Teams hinaus, das die Schleife betreibt.
KI liefert uns Codegenerierung und Geschwindigkeit in hohem Volumen, aber das kann auch bedeuten, dass es für Menschen schwieriger wird, jede einzelne Änderung zu überprüfen. Du musst stattdessen bewusst damit umgehen, worauf ihre Aufmerksamkeit gerichtet ist. Wenn du eine menschliche Prüfung in ein System einbaust, das sich ansonsten mit Maschinengeschwindigkeit bewegt, wundere dich nicht, wenn das die Produktivität beeinträchtigt. Menschliche Aufmerksamkeit ist knapp und wertvoll, also sollten wir sie proaktiv auf die nuanciertesten Probleme richten, die unser Urteilsvermögen erfordern. Nachgelagerte Menschen sollten nur dann hinzugezogen werden, wenn die automatisierten Leitplanken für Einschränkungen versagen.
Menschliches „Code-Review“ wird in Zukunft ganz anders aussehen
Korrektheit ist eine wichtige Dimension, aber dir könnten auch andere wichtig sein, wie Wartbarkeit, Leistung, Sicherheit, Effizienz und Verständlichkeit. So wie sich Korrektheit in viele Signaltypen zerlegt, gilt das auch für den Rest der Qualität. Und während es wichtig ist, wie viele Einschränkungen wir haben, ist es wichtiger, ob sie anspruchsvoll genug sind, um unsere Messlatte für Qualität und Produktionsreife zu erfüllen.
Softwarequalität ist keine einzelne Metrik. Betrachte sie als eine Sammlung von Signalen mit unterschiedlicher Wichtigkeit für dich und dein Team.
Gegendruck lässt sich über viele Werkzeuge umsetzen: Compiler, die ungültigen Code ablehnen, fehlschlagende Tests, Sicherheitsrichtlinien, die schlechte Praktiken blockieren, CI, die das Deployment verweigert. Idealerweise existiert er in der gesamten Schleife, nicht als einzelne Überprüfung am Ende der gesamten Arbeit.
Dex Horthys Karte desselben Loops, aus Why Software Factories Fail. Die grüne Box ist sein Argument, dass die menschliche Überprüfung wieder in den Loop gehört, anstatt durch ihn ersetzt zu werden.
Einschränkungen und Gegendruck lassen Agenten schlechte Arbeit erkennen, bevor sie zum Problem wird
Was passiert, wenn wir die Einschränkung nicht anwenden können, weil die Menge der Änderungen höher ist, als unsere Werkzeuge verarbeiten können? Wir bauen am Ende eine Warteschlange auf und verlassen uns auf ein Verifikationssystem, das sich mit menschlicher Geschwindigkeit bewegt. Um zu skalieren, wollen wir so viel wie möglich in die Verifikationsschleife hineindrücken, und zwar über den gesamten Verlauf, nicht erst am Ende. Wenn wir innerhalb unserer automatisierten Prüfungen skalieren können, können wir die Geschwindigkeit und den Durchsatz unseres gesamten Auslieferungssystems erhöhen. Wenn uns in der Verifikationsschleife der Platz ausgeht, müssen wir eines von mehreren Dingen tun.
Erstens können wir unser Verifikationssystem skalieren und mehr Kapazität schaffen, um eingehende Änderungen einzuschränken und zurückzudrängen. Zweitens können wir die Rate reduzieren, mit der Agenten neue Änderungen erzeugen, damit die Verifikation mit dem Arbeitsvolumen Schritt halten kann. Drittens können wir unsere Qualitätslatte senken, damit die Verifikation nicht so stark zurückdrängt, wie sie es sonst tun würde. Aus Skalierungsperspektive müssen wir bereit sein, all diese Dinge zu tun. Gleichzeitig sollten wir nicht davor zurückschrecken zu erkennen, dass wir tatsächlich mehr erreichen könnten, wenn wir in einigen Richtungen Einschränkungen lockern. Vielleicht können wir die Geschwindigkeit agentengenerierter Änderungen erhöhen, indem wir Schwärme von Agent-Entwicklern oder automatisierte Softwarefabriken bereitstellen, die Änderungen erzeugen, ohne auf unsere Überprüfung jeder einzelnen zu warten.
Und an manchen Stellen möchten wir ihnen vielleicht mehr Freiheit geben, solange wir an anderen Stellen strengere Einschränkungen beibehalten. Indem wir dort strengere Einschränkungen setzen, wo es uns am wichtigsten ist, können wir unseren Durchsatz maximieren, ohne Qualität zu opfern. Bei diesen Entscheidungen gibt es viele Optionen. Am offensichtlichsten müssen wir zwischen verschiedenen Qualitätsdimensionen abwägen. Wie wir betont haben, ist Sicherheit sehr wichtig, aber wir mussten auch zwischen Sicherheit und pünktlicher Produktauslieferung abwägen. Es gibt ein Spektrum von innovationsorientiert an einem Ende bis qualitätsorientiert am anderen. Irgendwo auf diesem Spektrum müssen wir entscheiden, wo wir stehen wollen.
Wir wollen klares Feedback aus der Umgebung und dem System zurück an unsere Agenten oder Teams senden, damit sich Menschen auf die subjektiveren Fragen von Geschmack, Absicht und Architektur konzentrieren können. Wenn wir Menschen helfen können, sich im sicheren Bereich der Einschränkungen zu bewegen, können wir vermeiden, dass sie hart arbeiten müssen, um herauszufinden, wo etwas schiefgelaufen ist.
Softwarequalität umfasst mehr als nur Korrektheit. Softwarequalität bedeutet auch Wartbarkeit, gute Leistung, Sicherheit, Effizienz und leichte Verständlichkeit. Alle Einschränkungen, die uns helfen, diese Standards zu erfüllen und unsere Produktion am Laufen zu halten, erzeugen Gegendruck in unserer Auslieferungs-Pipeline.
Wir müssen bewusste Entscheidungen darüber treffen, wo wir starke Einschränkungen anwenden und wo wir sie entfernen oder lockern. Wende starke Einschränkungen dort an, wo sie beiden Zielen dienen. Unterstütze sie nicht, wenn sie nicht eines oder beide Ziele fördern. Sei bereit, Standards je nach Bedarf anzuheben oder zu senken. Und denke daran: Diese Einschränkungen an verschiedenen Stellen im Softwaresystem sind es, die Softwarequalität durchsetzbar machen.
Wir sollten starke Einschränkungen dort anwenden, wo sie diesem doppelten Zweck am besten dienen, und erwägen, Einschränkungen zu entfernen oder zu lockern, die keinen der beiden Zwecke gut erfüllen. Wir sollten auch bereit sein, Qualitätsstandards bei Bedarf anzuheben oder zu senken. Im Endeffekt sind diese Einschränkungen an verschiedenen Stellen unseres Softwaresystems das, was der Qualität Biss verleiht. In vielen Fällen können wir mehr Gegendruck und mehr Einschränkungen erzeugen, indem wir neue Werkzeuge einsetzen oder bereits vorhandene Werkzeuge stärken. All diese Dinge können genutzt werden, um die meisten Änderungsanfragen zurückzudrängen. Wir wollen sie in der gesamten Pipeline aufbauen.
Wir wollen nicht bis zum Ende der Pipeline warten, wenn unser CI-System uns einfach mitteilt, dass wir ohne das Beheben von Problemen nicht deployen dürfen. Wir wollen diese Signale so früh wie möglich nutzen, über jeden möglichen Weg. Die ultimative Einschränkung in diesem System ist die, die wir uns selbst auferlegen, um hinter den Entscheidungen und Handlungen zu stehen, mit denen wir das System gebaut haben und betreiben. Aber wie bei allen anderen Einschränkungen müssen wir sorgfältig abwägen, wie stark wir unser eigenes Urteilsvermögen als Barriere, als Gegendruck und als letzte Kontrolle einsetzen wollen.
Qualität liegt in den Einschränkungen, die wir um unsere Agenten setzen. Wenn du also über Qualität für deine eigenen Apps nachdenkst, nimm dieses Problemverständnis und entwickle deinen eigenen einschränkungsgetriebenen Plan.
Apropos Qualität: Agenten schreiben deinen Code. Sonar gibt dir die Qualitäts-Gates, um ihn auslieferungsfähig zu machen. Er führt bei jedem Commit dieselbe vollständige Prüfung durch: eine tiefgehende dateiübergreifende Analyse, eine Karte davon, wo die Risiken liegen, und ein Qualitäts-Gate, das jeden Menschen und jeden Agenten an dieselbe Messlatte legt.
Dieser Artikel wurde als 100 % menschlich geschrieben von Pangram 4 eingestuft.
