Den Code schreiben jetzt die Agenten. Das ist aus dem Beruf des Entwicklers geworden.

Die Frage kommt an jedem Esstisch auf, an dem jemand einen Entwickler in der Familie hat: Wenn die Maschine den Code schreibt, was bleibt dann?

Die ehrliche Antwort ist, dass die Frage auf den falschen Teil des Berufs zielt. Code schreiben war nie der ganze Beruf. Es war der sichtbare Teil, der Teil, der für jeden, der am Schreibtisch vorbeikam, nach Arbeit aussah. Und in den meisten Wochen war es auch der kleinste.

Was automatisiert wurde, war nie der ganze Beruf

Alles, was ausgeliefert wird, durchläuft sechs Glieder:

1. Jemand will etwas und sagt es schlecht.
2. Jemand entscheidet, dass es sich lohnt, und wann.
3. Jemand macht daraus eine Beschreibung, die präzise genug ist, um danach zu handeln.
4. Jemand baut es.
5. Jemand prüft, dass nichts anderes kaputtgegangen ist.
6. Jemand liefert es aus und sagt der Person Bescheid, die gefragt hat.

Die Agenten haben Glied vier übernommen. Sie haben es überzeugend übernommen, und sie werden darin weiter besser. Was fast niemand laut ausspricht, ist die Wirkung auf die anderen fünf: Sie werden schwerer, nicht leichter.

Der Grund ist der Durchsatz. Als Bauen zwei Wochen dauerte, hatten die fünf umliegenden Glieder zwei Wochen Zeit. Sie waren langsam, weil die Mitte langsam war, und niemandem fiel auf, dass sie langsam waren. Wenn Bauen einen Nachmittag dauert, wird alles andere auf einen Schlag zum Engpass.

Ein Glied ist eingestürzt. Die anderen fünf tragen jetzt das Gewicht, das dieses Glied verborgen hat.

Das ist die ganze Geschichte, und der Rest dieses Artikels beschreibt, wie jedes der fünf aussieht, wenn man es tatsächlich jeden Tag machen muss.

Glied 1: hören, was zu bauen ist, ohne die Hälfte zu verlieren

Der neue Fehlerfall ist präzise, und er ist teuer: Sie können alles bauen, also bauen Sie das Falsche schneller.

Wünsche kommen von überall. Eine Nachricht in einem Support-Thread. Ein Satz am Ende eines Telefonats. Eine Beschwerde in einem sozialen Netzwerk. Ein Bugreport, der in Wahrheit ein verkleideter Feature-Wunsch ist. Historisch spielte das kaum eine Rolle, denn Sie konnten ohnehin nur eine Sache alle zwei Wochen bauen, und die naheliegende war meistens die richtige. Jetzt, wo Sie fünf Dinge pro Woche bauen können, macht der Unterschied zwischen den richtigen fünf und den falschen fünf den Großteil Ihres Jahres aus.

Zwei Dinge müssen passieren, und es sind zwei verschiedene Dinge.

Erstens muss das Erfassen für die Person, die etwas will, billig sein. Wenn ein Nutzer ein Konto anlegen, ein Formular finden und sein Problem zweimal beschreiben muss, machen sich die meisten die Mühe nicht, und die, die es tun, sind keine repräsentative Stichprobe. Ein öffentliches Feedback-Board, auf dem jeder einen Wunsch einreichen, einen Screenshot anhängen und verfolgen kann, was daraus wird, nimmt diese Reibung weg. Die Leute, die das Produkt benutzen, schreiben die Wünsche selbst, in ihren eigenen Worten, mit dem Kontext im Anhang.

Zweitens muss das Sortieren automatisch laufen, denn rohes Feedback bleibt nicht lange nützlich. Zwanzig Nachrichten, die ungefähr dasselbe sagen, sehen nach zwanzig Problemen aus, bis jemand alle zwanzig liest und merkt, dass es eines ist. Genau das ist die Arbeit, für die niemand Zeit hat. Idea Radar ist unsere Antwort darauf: Rohsignale kommen unangetastet an, gruppieren sich von selbst zu Themen, Duplikate werden zusammengeführt, bevor daraus zwei Bauaufträge werden, und jede Idee trägt die Zahl der verschiedenen Personen, die sie sich gewünscht haben. Der Wortlaut wird nie umgeschrieben, denn die genauen Worte, die jemand benutzt hat, sind die Daten.

Was dieses Glied hervorbringt, ist kein Backlog. Es ist ein Korpus, den man lesen kann.

Glied 2: entscheiden, die inzwischen knappe Ressource

Ein Ideen-Board ist kein Plan. Aus dem einen das andere zu machen, ist die Ermessensentscheidung, die früher dünn über ein Quartal verteilt war und jetzt jede Woche fallen muss.

Zwei Handgriffe zählen hier.

Die Beförderung ist bewusst. Eine Idee wird zu einem Backlog-Ticket, wenn jemand entscheidet, dass sie es wert ist, gebaut zu werden, nicht wenn sie eingereicht wird. Alles andere bleibt auf dem Radar sichtbar, mit der Zahl derer, die danach gefragt haben, und das ist der ehrliche Stand der Dinge: gehört, nicht eingeplant. Ein Backlog, in dem achtzig Prozent der Zeilen nie gebaut werden, ist kein Plan, sondern ein Archiv mit einem täuschenden Layout.

Das Zuschneiden passiert vor dem Bauen, nicht währenddessen. Aus unscharfem Feedback wird ein abgenommenes Mockup, das die Person, die gefragt hat, ansehen und bestätigen kann. Fünf Minuten Bestätigung schlagen einen Nachmittag, an dem der falsche Bildschirm gebaut wird, und dieser Handel ist dramatisch besser geworden, seit aus dem Nachmittag Bauzeit ein Nachmittag Agentenzeit wurde, den Sie für etwas anderes hätten einsetzen können.

Glied 3: briefen, das Handwerk, das die Tipparbeit ersetzt hat

Hierhin ist das eigentliche Können gewandert.

Ein Agent widerspricht einer mehrdeutigen Anweisung nicht so, wie ein Kollege es tut. Er wird nicht sagen: „Moment, welchen der beiden Bezahlvorgänge meinst du?“ Er füllt die Lücke mit einer plausiblen Vermutung und reicht Ihnen etwas Stimmiges und Falsches. Die Kosten der Mehrdeutigkeit waren früher ein Gespräch. Jetzt sind sie ein Diff.

Was Leute, die gute Ergebnisse bekommen, von Leuten trennt, die den ganzen Tag mit ihren Agenten kämpfen, ist keine Cleverness im Prompt. Es ist wiederverwendbarer Kontext. Vier Sorten, in absteigender Reihenfolge dessen, was sie zurückzahlen.

Kontext, den die Agenten lesen, bevor sie zu suchen anfangen. Versionierte Konventionsdateien (CLAUDE.md, AGENTS.md) und ein Projektgedächtnis, das Architekturentscheidungen, vergangene Fallen und den Grund festhält, warum die Dinge so sind, wie sie sind. Einmal geschrieben, von jedem Agenten auf jeder Maschine gelesen, für immer. Das ist der Text mit dem höchsten Hebel, den ein Entwickler heute schreibt, und fast niemand plant Zeit dafür ein.

Prozeduren, gespeichert als Prozeduren. Beim zehnten Mal, wenn Sie Ihre Release-Checkliste erklären, briefen Sie nicht mehr, Sie tippen ab. Eine Skills-Bibliothek macht aus einer wiederkehrenden Prozedur etwas, das ein Agent lädt, sobald die Aufgabe passt, und eine Prompt-Bibliothek tut dasselbe für die Briefings selbst.

Zeigen statt beschreiben. Ein Absatz, der einen verrutschten Button beschreibt, ist schlechter als ein Bild des verrutschten Buttons. Schicken Sie einen Bildschirmausschnitt direkt, oder zeichnen Sie darauf, um auf die Sache zu deuten, die Sie meinen. Bei einer Webseite schlägt es jedes Mal, dem Agenten das lebende DOM zu geben, statt es zu beschreiben.

Sprechen statt tippen. Ein gesprochenes Briefing aus drei Sätzen transportiert mehr Nuance als der eine Satz, den Sie sich zu tippen die Mühe gemacht hätten. Sprachdiktat für eine schnelle Anweisung, Voice Mode, wenn Sie das Hin und Her wollen, ohne die Tastatur anzufassen. Das klingt nach Komfortfunktion. In der Praxis ist es eine Frage der Bandbreite: Menschen sagen mehr, als sie tippen, und Agenten sind durch das begrenzt, was Sie ihnen sagen.

Die ersten drei werden pro Aufgabe bezahlt. Der vierte wird einmal bezahlt und für immer eingesammelt.

Glied 4: die Arbeit steuern, auf der richtigen Maschine

Ein Agent ist ein Werkzeug. Mehrere Agenten sind ein System, und ein System braucht jemanden, der es bedient.

Die praktischen Fragen sind nicht glamourös, und sie sind der Beruf. Was kann parallel laufen, ohne dass zwei Agenten dasselbe Modul bearbeiten? Welche Aufgabe verdient Ihre Aufmerksamkeit, während sie läuft, und welche nicht? Was soll laufen, während Sie schlafen?

Die letzte Frage entscheidet, wo die Arbeit ausgeführt wird. Alles, was Sie unterwegs unterbrechen, korrigieren oder umlenken müssten, gehört auf die Maschine vor Ihnen. Lange, gut spezifizierte Arbeit ohne Grauzonen gehört woandershin: auf einen anderen Computer, der Ihnen gehört, oder auf einen Server über SSH, damit ein Zwei-Stunden-Job nicht Ihren Laptop als Geisel nimmt. Wiederkehrende Arbeit gehört auf einen Zeitplan. Die entscheidende Frage ist nie die reine Rechenleistung, sondern wie wahrscheinlich es ist, dass Sie eingreifen müssen.

Wenn ein Arbeitspaket Phasen hat, die sich wirklich unterscheiden, ist ein einzelner Agent die falsche Form dafür. Ein Bau, der getestet und danach geprüft werden muss, sind drei Jobs mit drei verschiedenen Kompetenzen, und Agenten-Teams lassen Sie diese Übergabe ausdrücklich zeichnen, statt bei jedem Schritt den Kontext neu zu erklären.

Und weil nichts davon verlangt, dass Sie dabeisitzen, hört die Steuerung vom Handy aus auf, eine Spielerei zu sein. Die Frage eines Agenten zu lesen und sie aus dem Zug heraus in zwanzig Sekunden zu beantworten, ist der Unterschied zwischen einer Aufgabe, die fertig wurde, und einer Aufgabe, die vier Stunden auf Sie gewartet hat.

Glied 5: prüfen, wo die Verantwortung sitzt

Das ist das Glied, das sich nicht delegieren lässt, und der Grund dafür ist nicht technisch.

Die Agenten haben das Lesen der meisten Zeilen bereits ersetzt. Was sie nicht übernehmen können, ist die Unterschrift. Verantwortung geht nicht auf ein Modell über. Wenn eine Migration in der Produktion eine Spalte löscht, ist „der Agent hat das geschrieben“ kein Satz, den irgendjemand akzeptiert, und das soll auch so bleiben.

Was sich ändert, ist die Form der Überprüfung, nicht ihre Existenz. Jede Zeile zu lesen überlebt den Kontakt mit fünf parallel laufenden Agenten nicht, und ein Mensch, der um sechs Uhr abends ein neunhundertzeiliges Diff überfliegt, produziert eine Unterschrift, ohne Wissen zu produzieren. Die Regel, die hält, lautet: prüfen im Verhältnis zum Blast-Radius. Texte und Styling werden überflogen, während Authentifizierung, Zahlungen, Berechtigungen, persönliche Daten und Migrationen jedes Mal zeilenweise gelesen werden, von jemandem, der sie selbst hätte schreiben können.

Zwei Dinge machen das praktikabel. Ein Diff pro Agent zu sehen statt eines zusammengeworfenen Haufens sagt Ihnen, wer was geändert hat, wenn drei von ihnen im selben Repository gearbeitet haben. Und die Konversation an den Commit zu hängen beantwortet die Frage, die sechs Monate später tatsächlich Zeit kostet, und die lautet nie „was hat sich geändert“, sondern „warum“.

Bei allem, was eine Oberfläche hat, hört die Kontrolle nicht beim Diff auf. Ein Agent, der einen echten Browser steuert, kann den Ablauf durchgehen, den er gerade gebaut hat, und berichten, was er gesehen hat. Das fängt die Sorte Bug, die sich im Quelltext tadellos liest.

Wohin diese Aufmerksamkeit gehört, haben wir in einem eigenen Artikel behandelt: sollten Sie den Code Ihres KI-Agenten noch überprüfen.

Glied 6: ausliefern und die Schleife schließen

Ausliefern ist die leichte Hälfte dieses Glieds. Die Hälfte, die übersprungen wird, ist, der Person Bescheid zu sagen, die gefragt hat.

Es ist auch die Hälfte mit dem höchsten Ertrag. Ein Nutzer, der etwas meldet und später erfährt, dass es ausgeliefert wurde, meldet auch das Nächste. Ein Nutzer, der ins Schweigen hinein meldet, hört auf zu melden, und Sie verlieren den Zufluss, der Glied eins gespeist hat. Wenn ein Ticket geschlossen wird, das aus einem öffentlichen Wunsch entstanden ist, sollte die Person, die ihn eingereicht hat, davon erfahren, ohne dass jemand daran denken muss, eine E-Mail zu schicken.

Davor gibt es meistens jemanden, der es funktionieren sehen muss und Ihre Entwicklungsumgebung nicht hat: einen Kunden, eine Designerin, einen Kollegen auf einem anderen Kontinent. Eine öffentliche HTTPS-URL, die auf Ihre lokale Maschine zeigt, macht daraus statt eines Deployments einen Link, und das Feedback, das zurückkommt, geht direkt in Glied eins.

Die Kette schließt sich. Genau das macht daraus einen Beruf und keine Warteschlange.

Was wirklich geschrumpft ist und was wirklich gewachsen ist

Lesen Sie diese Tabelle ehrlich, und die Angst ändert ihre Form. Die Teile, die geschrumpft sind, sind die Teile, für die man am leichtesten einstellen konnte. Die Teile, die gewachsen sind, sind die, für die jemand nötig ist, der das System, die Nutzer und die Konsequenzen versteht. Das ist ein schwierigerer Beruf, kein kleinerer, und er ist erheblich weniger einsam als die Version, in der man den ganzen Tag getippt hat.

Wo AgentsRoom in all dem sitzt

Wir bauen das Werkzeug, das die ganze Kette zusammenhält, denn die Alternative sind sechs Werkzeuge, die nichts voneinander wissen.

Das heißt: Die Wünsche landen auf einem Board, sortieren sich zu Ideen, werden zu Tickets befördert, werden zu etwas zugeschnitten, das ein Agent nicht falsch lesen kann, werden von einem Agenten oder einem Team davon auf Ihrer Maschine oder auf einer entfernten ausgeführt, werden pro Agent mit angehängter Konversation geprüft, und werden geschlossen, wobei die Person, die gefragt hat, Bescheid bekommt. Ein Fenster, ein Ort, an dem der Stand der Arbeit stimmt.

Die einzelnen Teile gibt es anderswo. Die Verbindungen dazwischen hat niemand ausgeliefert, und die Verbindungen sind die Stelle, an der die Arbeit versickert.

Fragen, die wirklich gestellt werden

Wird KI Softwareentwickler ersetzen?

Sie hat das Tippen ersetzt, nicht den Beruf. Code zu schreiben ist ein Glied in einer Kette, zu der auch gehört: hören, was Nutzer brauchen, entscheiden, was gebaut werden soll, es präzise spezifizieren, die Arbeit steuern, sie prüfen und sie ausliefern. Die Agenten haben die Kosten eines einzigen Glieds zum Einsturz gebracht, und damit sind die anderen fünf zum Engpass geworden. Weniger Menschen werden dafür bezahlt, Zeilen zu produzieren. Mehr Menschen werden dafür bezahlt, zu entscheiden, welche Zeilen existieren sollen, und dafür geradezustehen, sobald sie live sind.

Was macht ein Entwickler eigentlich, wenn die Agenten den Code schreiben?

Sechs Dinge, und nur eines davon war früher auf einem Bildschirm voller Code zu sehen. Sie sammeln ein, was die Leute sich wünschen, Sie entscheiden, was gebaut wird und in welcher Reihenfolge, Sie briefen die Arbeit so präzise, dass ein Agent sie nicht falsch lesen kann, Sie steuern mehrere Arbeitspakete gleichzeitig, ohne den Überblick zu verlieren, Sie prüfen im Verhältnis dazu, was jede Änderung brechen kann, und Sie liefern aus und sagen der Person Bescheid, die gefragt hat. Das Handwerk hat sich von der Produktion der Änderung zu ihrer Spezifikation und der Verantwortung dafür verschoben.

Muss man immer noch programmieren können?

Ja, und zum Lesen sogar mehr als früher. Sie müssen sich die Syntax einer Sprache, die Sie zweimal im Jahr anfassen, nicht mehr merken, denn der Agent schreibt sie. Sie müssen ein Diff öffnen und innerhalb von Sekunden wissen, ob eine Migration umkehrbar ist, ob eine Authentifizierungsprüfung verschoben wurde, ob eine Query beim zehnfachen Traffic noch hält. Wer keinen Code lesen kann, kann keinen Agenten prüfen, und wer keinen Agenten prüfen kann, steuert ihn nicht, sondern hofft nur.

Was bricht als Erstes, wenn man das Programmieren an Agenten abgibt?

Die Priorisierung. Wenn Bauen einen Nachmittag statt zwei Wochen dauert, verschwinden die Kosten dafür, das Falsche zu bauen, aus dem Blick, also wird es gebaut. Teams landen bei mehr ausgelieferten Features und keinem einzigen zusätzlich gelösten Problem. Das Zweite, was bricht, ist die Rückkopplung: Wünsche der Nutzer kommen schneller herein, als irgendjemand sie sortieren kann, also stapeln sie sich in Chat-Threads und gehen verloren, und derselbe Wunsch wird zweimal gebaut, weil niemand gemerkt hat, dass es derselbe war.

Was ist die schwierigste Fähigkeit in diesem neuen Ablauf?

Ein Briefing zu schreiben, das ein Agent nicht falsch lesen kann. Ein Agent widerspricht einer mehrdeutigen Anweisung nicht so, wie ein Kollege es tut, also füllt er die Lücken mit einer plausiblen Vermutung und liefert etwas Stimmiges und Falsches. Wer gute Ergebnisse bekommt, hat keine cleveren Prompts, sondern hält wiederverwendbaren Kontext bereit: versionierte Konventionsdateien, eine gespeicherte Prozedur pro wiederkehrender Aufgabe, ein Projektgedächtnis, das die Agenten lesen, bevor sie zu suchen anfangen, und Screenshots oder Skizzen statt Absätzen, die einen Bildschirm beschreiben.

Sollen Coding-Agenten auf der eigenen Maschine laufen oder auf einer entfernten?

Beides, entschieden pro Aufgabe. Alles, was Sie mitverfolgen, unterbrechen oder unterwegs korrigieren wollen, gehört auf die Maschine vor Ihnen. Lange, gut spezifizierte Arbeit ohne Grauzonen gehört auf eine andere Maschine, die Ihnen gehört, oder auf einen Server über SSH, damit ein Zwei-Stunden-Job nicht Ihren Laptop als Geisel nimmt. Die entscheidende Frage ist nicht die Rechenleistung, sondern wie wahrscheinlich es ist, dass Sie eingreifen müssen.

Die Kurzfassung

Der Beruf ist nicht verschwunden. Er ist aus dem Editor heraus in die Kette drumherum gezogen.

Wenn Sie diesen Monat nur eine Sache ändern wollen, nehmen Sie Glied eins. Alles, was danach kommt, ist verschwendete Mühe, sobald es auf das falsche Problem zeigt, und es ist das einzige Glied, in dem eine Stunde Ihrer Aufmerksamkeit eine Stunde Agentenzeit noch um einen Faktor schlägt, den niemand messen kann.