Unterstützung, die selbstständig arbeitet

Die andere Hälfte des Gebiets wartet nicht auf dich.

Du gibst einem Werkzeug ein Ziel. Es arbeitet eine Weile selbstständig und kommt mit etwas Fertigem zurück. Dieser Teil hat sich am schnellsten entwickelt, und er ist wirklich beeindruckend.

Agenten

Ein Programmieragent erhält ein Ziel und die Erlaubnis zu handeln. Er liest das Projekt, um seinen Aufbau zu verstehen, entwickelt einen Plan, bearbeitet Dateien, führt Befehle und Tests aus, liest, was fehlgeschlagen ist, und versucht es erneut. Anschließend übergibt er dir einen vollständigen Änderungsvorschlag.

Es gibt drei Formen. Im Editor, wo du ihm zusehen und ihn unterbrechen kannst. In der Befehlszeile, ausgerichtet auf einen Projektordner. Und auf einem entfernten System, wo du eine Aufgabe beschreibst, etwas anderes erledigst und später einen Änderungsvorschlag zur Prüfung vorfindest.

Du übergibst ein Stück Arbeit so, wie du es einem fähigen Kollegen übergeben würdest, der dein Produkt nicht kennt. Die beiden entscheidenden Momente sind deshalb die Übergabe und die Rückgabe.

Bots zur Codeprüfung

Damit verwandt und zunehmend alltäglich: eine KI, die vorgeschlagene Änderungen liest und kommentiert, bevor ein Mensch das tut.

Sie kann auf übersehene Probleme hinweisen: eine fehlende Reaktion auf einen Fehler, einen benannten Wert, der nie verwendet wird, ein Muster, das nicht zum restlichen Projekt passt, oder einen möglichen Sicherheitsfehler. Sie kann aber auch echte Probleme übersehen und welche melden, die gar nicht existieren. Ein Kommentar ist ein Hinweis zum Nachgehen.

Schwächer sind diese Bots bei dem, wofür menschliche Prüfung eigentlich da ist: zu fragen, ob diese Änderung überhaupt existieren sollte und ob sie zur Richtung des Produkts passt.

Vom Prompt zur Anwendung

Dann gibt es Werkzeuge, denen du eine Anwendung beschreibst, und eine funktionierende Anwendung erscheint. Ansichten, Datenbank, Anmeldung, bereitgestellt an einem Ort, an dem du sie anklicken kannst.

Um Menschen eine Idee zu zeigen, ist das bemerkenswert. Es hat das Entwickeln von Software tatsächlich für Menschen erreichbar gemacht, die sonst nie über die Einrichtungsanleitung hinausgekommen wären. Vieles, was Menschen mit Vibe Coding meinen, passiert hier.

Was entsteht, ist eine echte Anwendung. Und echte Anwendungen bringen Fragen mit: Wo werden die Daten gespeichert, wer kann darauf zugreifen, was passiert bei zwei gleichzeitigen Nutzern, und was kostet es bei tausend? Gibt es regelmäßige Sicherungen der Daten?

Überprüfung ist der Einsatzort deines Urteilsvermögens

Hier liegt die Verschiebung. Bei reinen Vorschlägen kannst du jeweils eine vorgeschlagene Änderung prüfen. Bei einem Agenten bekommst du womöglich viele Änderungen zusammen, und ihre Prüfung verlangt bewusste Aufmerksamkeit. Bei beiden Arbeitsweisen können Fehler unbemerkt bleiben.

Erzeugten Code zu überprüfen bedeutet, drei getrennte Fragen zu stellen.

War die Anfrage richtig? Selbst ein Agent, der deine Anfrage genau befolgt, kann das Falsche bauen, wenn darin eine wichtige Regel fehlt. Er kann auch eine gute Anfrage missverstehen. Prüfe sowohl, was du verlangt hast, als auch, was er tatsächlich gebaut hat.

Tut es, was es behauptet? Die Änderung läuft, und die Tests bestehen. Prüfen die Tests das Verhalten, das dir wirklich wichtig ist, oder nur das Verhalten, das der Code zufällig hat? Ein Agent, der seine eigenen Tests schreibt, kann rund um ein Missverständnis einen wunderschön grünen Testlauf erzeugen.

Gehört es in das Produkt? Ob es die richtigen Dateien betrifft, private Daten privat hält, mit allem um sich herum zusammenarbeitet und für die Person verständlich ist, die es später übernimmt. Tests können für manche dieser Fragen Belege liefern. Ein bestandener Test belegt aber nur das Verhalten, das er tatsächlich geprüft hat.

Ein konkretes Beispiel: Die Anfrage lautet „Ab einem Bestellwert von 50 Euro ist die Lieferung kostenlos.“ Ein erzeugter Rechner liefert diese Ergebnisse:

Die ersten beiden Prüfungen bestehen. Die dritte deckt einen Fehler an der Grenze auf, genau an dem Punkt, an dem sich die Regel ändert. Der Rechner prüft vielleicht „mehr als 50“ statt „50 oder mehr“. Eine Prüfung des Codes würde die Ursache feststellen. Du brauchst keine Python-Syntax, um zu erkennen, warum es nicht reichte, die ersten beiden Ergebnisse zu akzeptieren.

Prüfe nach einer Korrektur alle drei Fälle erneut. Wenn du nur 50 prüfst, könntest du einen neuen Fehler bei 40 oder 75 übersehen. Diese Beispiele beweisen weiterhin nicht, dass jede Bestellung funktioniert. Sie zeigen, wie eine ausdrücklich formulierte Regel dir hilft, nützliche Belege auszuwählen.

Nichts davon ist ein Grund, Agenten zu meiden. Es beschreibt, worauf du deine Aufmerksamkeit richtest, sobald du einen nutzt. Deshalb musst du Software, Programmierung, Hardware, Netzwerke und den Rest weiterhin verstehen.

Berechtigungen sind eine echte Entscheidung

Ein Agent, der Dateien bearbeiten, Befehle ausführen und auf das Netzwerk zugreifen kann, ist ein Programm mit deinen Zugriffsrechten. Bei den meisten Werkzeugen kannst du festlegen, wie weit das geht: nur lesen, bearbeiten, aber vor jeder Ausführung fragen, einen abgeschirmten Bereich verwenden, in dem Fehler begrenzt bleiben, oder vollständige Freiheit geben.

Passe das an seine Aufgabe an. Ein Experimentierprojekt und das System mit den Daten deiner Kunden verdienen nicht denselben Spielraum. „Bisher ging es gut“ ist kein Sicherheitskonzept. Sprachmodelle machen Fehler. Ich habe das selbst erlebt. Sie können auf unerwartete Weise Datenverlust verursachen. Ein Beispiel aus meiner eigenen Erfahrung: Ein Programmieragent führte einmal Tests gegen die Produktionsdatenbank statt gegen Testdaten aus und löschte dabei alle meine Produktionsdaten. Ich bin alt und klug genug, tägliche Sicherungen anzulegen. Deshalb verlor ich die Arbeit eines Tages, was immer noch wehtut. Daraus habe ich gelernt.

Dasselbe Werkzeug, zwei sehr unterschiedliche Ergebnisse

Ein erfahrener Entwickler gibt einem Agenten eine klar abgegrenzte Aufgabe, liest die Änderung, bemerkt, dass sie unbemerkt eine Prüfung entfernt hat, verlangt eine Korrektur und liefert nach einer Stunde etwas Gutes aus.

Jemand ohne diese Lesefähigkeit erhält dieselbe Änderung, sieht, dass die App weiterhin funktioniert, und liefert sie aus. Die entfernte Prüfung zeigt sich Monate später als Fehler, dessen Ursache niemand findet.

Dasselbe Werkzeug. Dieselbe Ausgabe. Der Unterschied liegt ausschließlich darin, was der Mensch erkennen konnte.

Deshalb gehört dieses Kapitel in einen Kurs über die Frage, ob du Programmieren lernen solltest. Und das ist die ehrliche Antwort darauf, ob diese Werkzeuge das Lernen überflüssig machen: Sie machen es wertvoller. Die letzte Lektion verbindet das mit allem anderen.