Softwareentwicklung mit Coding-Assistenten und Agenten

Coding-Assistenten und Coding-Agenten

0:00 Willkommen zum ersten Modul. Wir reden in den nächsten drei Tagen über Clean Code und über KI-Werkzeuge — und das ist keine willkürliche Kombination. Beides gehört zusammen, seit sich die Arbeitsteilung beim Programmieren verschoben hat. Früher war die Frage: Wie schreibe ich guten Code? Heute lautet sie zunehmend: Wie verantworte ich Code, den ich nicht selbst geschrieben habe? Das ist eine andere Frage, und sie verlangt andere Fähigkeiten.

0:25 Dieses erste Modul legt dafür die Begriffe — was ein Assistent von einem Agenten unterscheidet, wofür sich beide eignen, und an welcher Stelle Ihre Arbeit dabei wichtiger wird statt überflüssiger.

Coding-Assistenten und Coding-Agenten

0:37 Der erste Tag beschäftigt sich mit den Grundlagen: den Werkzeugen, dem Qualitätsbegriff dahinter und der Frage, wie man eine Aufgabe so zuschneidet, dass ein Ergebnis überhaupt prüfbar wird. Wir fangen bewusst nicht mit Werkzeugen an, sondern mit dem, was sich durch sie verändert hat. Denn die interessante Verschiebung liegt nicht darin, dass Code schneller entsteht.

0:58 Sie liegt darin, dass die Prüfung nicht mitgewachsen ist. Genau dieser Punkt trägt alles, was danach kommt.

Von Code Completion zur agentischen Entwicklung

1:05 Beginnen wir mit einer kurzen Einordnung. Die Unterstützung beim Programmieren hat in wenigen Jahren drei Stufen durchlaufen, und die dritte unterscheidet sich von den beiden davor nicht graduell, sondern grundsätzlich. Es lohnt sich, diesen Bruch genau anzusehen, denn er erklärt, warum wir hier sitzen. Wer ihn übergeht, behandelt einen Agenten wie eine etwas bessere Autovervollständigung — und wundert sich, warum die vertrauten Gewohnheiten plötzlich nicht mehr tragen.

1:31 Sehen wir uns also an, was sich tatsächlich verändert hat. Stellen Sie sich den Unterschied zwischen einem Navigationsgerät und einem Taxifahrer vor. Das Navigationsgerät schlägt vor, Sie lenken. Der Taxifahrer bekommt ein Ziel und fährt selbst — und Sie merken erst am Ende, ob der Weg sinnvoll war. Ein Coding-Agent arbeitet wie der Taxifahrer: Er bekommt ein Ziel statt einer Anweisung, liest selbstständig im Repository, führt Befehle aus und ändert mehrere Dateien.

1:58 Der Mensch sieht nicht mehr zu, wie der Code entsteht. Er beurteilt ihn, wenn er fertig ist. Das ist der eigentliche Bruch — nicht die Qualität der Vorschläge, sondern der Zeitpunkt, zu dem Verantwortung überhaupt noch ausgeübt werden kann. Was diese Tabelle eigentlich zeigt, ist eine wandernde Grenze. In der ersten Zeile fällt Verantwortung beim Tippen an — Sie lesen jede Zeile, während sie entsteht, und merken sofort, wenn etwas nicht stimmt.

2:25 In der zweiten wandert sie zum Einfügen: Sie prüfen einen Vorschlag, bevor Sie ihn übernehmen. In der dritten rutscht sie ganz ans Ende, in den Review. Und ein Review ist eine Tätigkeit, die Zeit braucht, Konzentration verlangt und die man planen muss. Diese Einteilung ist übrigens unsere eigene, kein Branchenstandard — die Grenzen verschieben sich mit den Werkzeugen. Der Punkt bleibt trotzdem.

2:49 Warum ist das für einen Clean-Code-Kurs relevant? Weil vier Dinge dadurch teurer werden. Prüfung wird zur eigenen, planbaren Tätigkeit statt zu einem Nebenprodukt des Schreibens. Der Code entsteht ohne Zeugen — es gibt niemanden mehr, der ihn beim Entstehen verstanden hat, also muss das Ergebnis für sich sprechen. Struktur und Benennung entscheiden plötzlich mit, ob ein Werkzeug überhaupt die richtige Stelle findet. Und alles, was bisher implizit im Kopf blieb, muss aufschreibbar werden.

3:18 Nichts davon ist neu erfunden. Es war nur bisher billiger, es zu vernachlässigen.

Chat, IDE-Assistent und Coding-Agent unterscheiden

3:23 Damit zur ersten praktischen Unterscheidung. Diese drei Werkzeugarten werden im Alltag ständig in einen Topf geworfen, und das führt zuverlässig zur falschen Wahl. Dabei lösen sie ganz unterschiedliche Probleme und verdienen entsprechend unterschiedliches Vertrauen. Die Frage ist nicht, welches das beste Werkzeug ist — die Frage ist, welches zu der Aufgabe passt, die gerade vor Ihnen liegt.

3:46 Sehen wir uns an, was jede Art eigentlich weiß, denn davon hängt alles Weitere ab. Die entscheidende Spalte ist die zweite: Was kennt das Werkzeug überhaupt? Davon hängt alles andere ab. Ein Chat kennt nur, was Sie hineinschreiben — er ist deshalb stark bei allgemeinen Konzepten und schwach überall dort, wo die Besonderheiten Ihres Projekts entscheiden.

4:06 Der Assistent in der Entwicklungsumgebung sieht die offenen Dateien und arbeitet am kurzen Zügel. Der Agent sieht das Repository und kann Dateien finden, die Sie selbst übersehen hätten — aber in derselben Bewegung auch Dinge anfassen, die niemand angefasst haben wollte. Merken Sie sich vor allem eines: Der Agent ist nicht die gehobene Variante des Chats. Es sind verschiedene Werkzeuge für verschiedene Fragen.

4:29 Diese vier Fehler passieren aus einem gemeinsamen Grund: Man wählt das Werkzeug nach Gewohnheit oder Verfügbarkeit statt nach dem Zuschnitt der Aufgabe. Wer den Agenten für eine Frage einsetzt, die ein Blick in die Dokumentation beantwortet hätte, verbrennt Zeit und Aufmerksamkeit. Wer umgekehrt den Chat mit einer Änderung beauftragt, die den halben Projektkontext voraussetzt, bekommt eine Antwort, die überzeugend klingt und am Projekt vorbeigeht.

4:55 Der dritte Punkt ist der gefährlichste: Dem Agenten dieselbe beiläufige Aufsicht zuzutrauen wie der Zeilenvervollständigung. Das geht so lange gut, bis es einmal nicht gut geht.

Geeignete Aufgaben für KI-Unterstützung

5:05 Kommen wir zur Frage, die im Alltag am meisten bringt: Wofür eignen sich diese Werkzeuge eigentlich? Die Antwort ist erfreulich konkret — aber sie lautet nicht pauschal ja oder nein. Sie hängt am Aufgabentyp, und zwar deutlich stärker, als die meisten erwarten. Wer hier sauber unterscheidet, spart sich die Grundsatzdebatte, die in vielen Teams immer noch geführt wird, und kann stattdessen im Einzelfall begründen, warum ein Werkzeug hier hilft und dort schadet.

5:31 Wenn Sie eine Sache aus diesem Kapitel mitnehmen, dann diese: Programmieren ist kein Aufgabentyp. Es sind mindestens sieben verschiedene, und die Eignung schwankt zwischen ihnen stärker als zwischen den Werkzeugen. Deshalb führen pauschale Urteile in beide Richtungen in die Irre. Wer grundsätzlich ablehnt, verschenkt die starken Fälle. Wer grundsätzlich zustimmt, überdehnt die schwachen.

5:54 Und jede Eignung hat eine Bedingung — fällt sie weg, kippt der Nutzen ins Gegenteil. Wer diese Landkarte im Kopf hat, muss die Grundsatzfrage gar nicht mehr stellen. Schauen Sie weniger auf die mittlere Spalte als auf die rechte. Die Bedingung ist das Interessante, denn sie entscheidet, ob die Eignung überhaupt eintritt.

6:13 Erklären und Erkunden steht oben, weil es rein lesend ist und damit kein Risiko trägt — vorausgesetzt, Sie prüfen die Aussagen am Quellcode gegen. Planen ist stark, solange der Plan wirklich gelesen und nicht bloß abgenickt wird. Und ganz unten steht das Aushandeln der Anforderung: Das bleibt beim Menschen, weil nur er die Beteiligten fragen kann. Ein Sonderfall ist das Testen.

6:35 Es ist heikel, weil Tests, die aus vorhandenem Code abgeleitet werden, das aktuelle Verhalten festschreiben — Fehler eingeschlossen. Darauf kommen wir in Modul sieben ausführlich zurück.

Wo Coding-Agenten scheitern

6:47 Nach den Stärken jetzt die Schwächen — und zwar nicht als Warnung, sondern als Arbeitsgrundlage. Denn das Nützliche an diesen Fehlerbildern ist ihre Regelmäßigkeit. Sie wiederholen sich so zuverlässig, dass man sie erwarten und gezielt danach suchen kann. Ein Review, das weiß, wonach es sucht, findet erheblich mehr als eines, das nur allgemein aufmerksam ist. Fünf Muster sind es, und beim fünften wird es besonders interessant.

7:13 Diese vier Muster werden Sie wiedererkennen. Unvollständiger Kontext heißt: Die eine Datei mit der entscheidenden Regel wurde nicht gelesen, und daneben entsteht eine zweite, widersprüchliche Regel. Unmarkierte Annahmen erschweren das Prüfen, weil eine Vermutung wie eine Tatsache formuliert wird. Lokale Optimierung macht die angefasste Funktion schöner und die Struktur ringsum schlechter.

7:36 Und der vierte: Die Änderung wächst, weil unterwegs weitere Verbesserungen mitgenommen werden. Wichtig ist die Einordnung — das sind Erfahrungswerte, keine Messungen. Beim fünften Muster ist das anders, und darum geht es gleich. Hier haben wir ausnahmsweise Zahlen. Sprachmodelle erfinden Paketnamen, die es nicht gibt, und das ist zweimal gemessen worden.

7:57 Die gute Nachricht steht in der zweiten Zeile: Die Rate ist deutlich gesunken, von einer breiten Spanne auf wenige Prozent. Die schlechte steht in der dritten — und die ist der eigentliche Punkt. Über hundert Namen wurden von allen geprüften Modellen identisch erfunden, und ein Teil davon war noch registrierbar. Genau das macht die Sache gefährlicher, nicht harmloser: Ein reproduzierbar erfundener Name ist für einen Angreifer wertvoll, weil er ihn registrieren und warten kann.

8:25 Weniger Fehler, aber verlässlichere. Und jetzt die Einordnung, die mir wichtig ist: Keines dieser Muster ist ein Argument gegen den Einsatz von Agenten. Sie sind das Argument für eine bestimmte Arbeitsweise. Aufgaben klein schneiden, damit die Änderung prüfbar bleibt. Kontext bewusst bereitstellen, statt darauf zu hoffen, dass er gefunden wird.

8:46 Und jedes Ergebnis am Diff prüfen, nicht an der Begründung, die daneben steht. Diese drei Sätze sind im Grunde die Zusammenfassung der nächsten drei Tage — alles Weitere ist Ausarbeitung, Vertiefung und Übung. Wenn Sie sonst nichts mitnehmen, nehmen Sie diese drei mit.

Die veränderte Rolle der Entwickler

9:02 Damit zu einer Frage, die viele umtreibt, und zwar nicht nur fachlich: Was bleibt eigentlich übrig, wenn die Codeerzeugung billiger wird? Die Sorge dahinter ist verständlich, und man sollte sie ernst nehmen statt sie wegzureden. Die Antwort fällt allerdings beruhigender aus als befürchtet — sie verlangt aber eine Verschiebung dessen, was man unter der eigenen Arbeit versteht.

9:23 Vier Aufgaben bleiben, und sie sind anspruchsvoller als das Tippen. Wenn das Erzeugen billig wird, verschiebt sich der Wert auf das, was drumherum liegt. Vier Aufgaben bleiben beim Menschen, und sie werden wichtiger, nicht unwichtiger. Das Interessante daran: Es sind keine neuen Aufgaben. Sie waren immer Teil guter Entwicklungsarbeit, blieben aber oft implizit, weil derselbe Mensch beide Rollen ausfüllte — er dachte sich das Ziel, während er tippte.

9:50 Diese Bequemlichkeit ist weg. Was vorher im Kopf passieren konnte, muss jetzt gesagt werden. Das fühlt sich zunächst nach Bürokratie an und ist in Wahrheit nur sichtbar gewordene Denkarbeit. Diese vier Punkte bilden zusammen einen Ablauf, und die Reihenfolge ist kein Zufall. Erst das Ziel: Was soll nach der Änderung wahr sein, was vorher nicht wahr war?

10:11 Dann der Kontext: Welche Regeln muss jemand kennen, um das richtig zu lösen? Dann die Grenzen — und die vergisst fast jeder: Was darf angefasst werden, und was ausdrücklich nicht? Und schließlich die Verifikation: Woran erkennen wir, dass es stimmt, unabhängig davon, wie überzeugend es formuliert ist. Behalten Sie diese vier im Kopf.

10:31 Sie kommen in Modul vier als Aufgabenzuschnitt und in Modul sechs als Projektanweisung wieder.

Geschwindigkeit gegen Prüfkapazität

10:38 Jetzt kommt der unbequemste Teil dieses Moduls, und ich möchte ihn nicht beschönigen. Es geht um eine Kopplung, die jahrzehntelang so selbstverständlich war, dass sie niemand aussprechen musste — und die gerade zerbrochen ist. Die Folgen davon haben viele Teams noch vor sich, weil sie sich erst nach einigen Monaten zeigen. Wer sie kennt, kann gegensteuern, solange das noch billig ist.

11:00 Solange Entwickeln und Prüfen dieselbe Person mit derselben Geschwindigkeit erledigte, hielten sich beide Seiten von allein die Waage. Man konnte gar nicht mehr Code produzieren, als man selbst durchdacht hatte. Diese Kopplung ist weg. Und die Folge ist unangenehm: Ein Team kann heute sehr viel mehr Code erzeugen, als es prüfen kann.

11:19 Wer die Erzeugung vervielfacht und die Prüfung unverändert lässt, löst kein Problem, sondern verschiebt es nach hinten — in Reviews, die niemand mehr gründlich macht, und in eine Codebasis, deren Zustand niemand mehr überblickt. Sehen wir uns an, was dazu tatsächlich belegt ist — und achten Sie dabei besonders auf die rechte Spalte.

11:38 Die METR-Studie ist ein randomisierter Versuch: Erfahrene Entwickler brauchten mit KI neunzehn Prozent länger und glaubten hinterher, zwanzig Prozent schneller gewesen zu sein. Sechzehn Teilnehmer, eigene, seit Jahren vertraute Projekte — also der Fall, in dem KI am wenigsten beitragen kann. Der DORA-Bericht findet steigenden Durchsatz bei sinkender Stabilität, sagt aber selbst, dass das eine Korrelation ist.

12:02 Und die Stack-Overflow-Umfrage misst Einstellungen, keine Ergebnisse. Der Kern ist nicht die Zahl neunzehn. Der Kern ist die Lücke zwischen gefühlt und gemessen — rund neununddreißig Prozentpunkte, und niemand hat es bemerkt. Gerade weil die Zahlen eindrücklich sind, lohnt sich Vorsicht bei der Interpretation. Die neunzehn Prozent belegen nicht, dass KI generell langsamer macht — das sagen die Autoren ausdrücklich selbst.

12:27 Der zweite Punkt ist der praktisch wichtigste: Die eigene Einschätzung der Beschleunigung ist keine Messung, und wir wissen jetzt, dass sie systematisch danebenliegt. Die richtige Konsequenz ist trotzdem nicht, langsamer zu erzeugen. Sie besteht darin, das Prüfen zu automatisieren, wo es geht, und die einzelne Änderung so klein zu halten, dass ein Mensch sie noch mit Verstand lesen kann.

Grundsatz: Vorschlag statt Vertrauensbeweis

12:49 Zum Abschluss des theoretischen Teils ein Grundsatz, der klingt wie eine Selbstverständlichkeit und trotzdem täglich verletzt wird — von erfahrenen Leuten, nicht von Anfängern. Er ist der rote Faden dieser drei Tage, und alle weiteren Module lassen sich als Ausarbeitung dieses einen Satzes lesen. Er ist unbequem, weil er eine Bequemlichkeit wegnimmt, an die wir uns schnell gewöhnt haben.

13:11 Eine KI-Ausgabe ist ein Änderungsvorschlag. Nicht mehr. Sie ist kein Beleg dafür, dass die Änderung richtig ist. Das Tückische daran ist psychologisch: Flüssig formulierter Code mit überzeugender Begründung sendet genau die Signale, an denen wir bei Menschen Kompetenz ablesen. Wer souverän erklärt, weiß meistens, wovon er redet — das ist eine brauchbare Heuristik unter Menschen. Bei einem Sprachmodell sind diese Signale entkoppelt.

13:37 Fließende Erklärung und fachliche Richtigkeit haben wenig miteinander zu tun. Deshalb übernimmt man Fehler nicht trotz ihrer guten Verpackung, sondern wegen ihr. Hier sehen Sie genau das in Aktion. Ein Assistent soll prüfen, ob eine neue Buchung mit einer bestehenden kollidiert. Was da steht, sieht vernünftig aus: Es wird über den Bestand gelaufen und geprüft, ob sich Zeiträume überschneiden. Die Logik der Überschneidung selbst ist sogar korrekt.

14:04 Und trotzdem stecken zwei Fehler darin. Erstens wird nirgends verglichen, ob es überhaupt dasselbe Fahrzeug ist — die Prüfung würde also völlig unbeteiligte Buchungen ablehnen. Zweitens fehlt die Ausnahme für Werkstatttermine, in denen eine Überschneidung zulässig ist. Beides fällt beim Überfliegen nicht auf. Und wenn die Testdaten nur ein Fahrzeug enthalten, fällt es auch den Tests nicht auf.

14:28 Der erste Punkt ist der verbreitetste: Man liest die Begründung statt den Code, weil die Begründung angenehmer zu lesen ist. Der zweite betrifft genau das Beispiel von eben — fast richtige Lösungen sind der teuerste Fehlertyp, weil sie das Überfliegen überleben. Der dritte ist die Falle mit den grünen Tests, die zufällig nur den einfachen Fall abdecken. Und der vierte ist der elegante: Nachfragen, ob es stimmt.

14:52 Das fühlt sich nach Prüfung an, ist aber keine — die Antwort ist wieder nur ein Vorschlag.

Übung: Arbeitsteilung an einer Fahrtenbuch-Aufgabe

14:58 Genug Theorie für dieses Modul. Zum Abschluss eine Übung, in der Sie das Gelernte auf eine konkrete Aufgabe anwenden — und zwar auf das Fahrtenbuch, das uns durch die gesamten drei Tage begleiten wird. Sie werden dieselbe Anwendung in jedem Modul wiedersehen, mit wachsender Vertrautheit. Das ist Absicht: Am bekannten Gegenstand fallen die Unterschiede zwischen den Vorgehensweisen deutlicher auf als an zwölf verschiedenen Beispielen.

15:22 Zum Hintergrund: Das Fahrtenbuch ist die Fuhrparkverwaltung eines Handwerksbetriebs mit rund vierzig Fahrzeugen an drei Standorten. Gewünscht ist, dass Fahrten nachträglich korrigiert werden können, solange die Monatsabrechnung noch nicht freigegeben ist. Ihre Aufgabe ist nicht, das umzusetzen. Ihre Aufgabe ist, die Arbeit zu verteilen — und zwar begründet.

15:42 Der eigentliche Reiz liegt im letzten Teil: Für jeden Schritt sollen Sie ein Warnsignal benennen, an dem Sie merken würden, dass die Zuordnung falsch war. Das zwingt dazu, die Entscheidung überprüfbar zu machen statt nur plausibel. Der Ablauf ist geradlinig. Notieren Sie zunächst die sieben Arbeitsschritte einzeln — vom Klären der Anforderung bis zum Dokumentieren.

16:04 Entscheiden Sie dann je Schritt, ob er beim Menschen liegt, an einen Agenten geht oder gemeinsam bearbeitet wird, und schreiben Sie die Begründung dazu. Danach das Warnsignal. Im Plenum vergleichen wir anschließend nicht die Schritte, bei denen alle einig sind, sondern die strittigen — dort steckt der Lerngewinn. Und heben Sie Ihre Zuordnungen auf: In Modul fünf prüfen wir sie gegen den vollständigen Entwicklungszyklus.