David Fowler hat Anfang September einen Satz geschrieben, der hängen bleibt: „Typing code is absolutely over.“
Fowler ist Distinguished Engineer bei Microsoft und hat unter anderem an SignalR, NuGet, Kudu und ASP.NET Core gearbeitet. Heute ist er stark an Aspire beteiligt.
Wer daraus „Entwickler braucht es bald nicht mehr“ liest, springt zu weit. Softwareentwicklung bestand auch vorher nicht hauptsächlich daraus, möglichst schnell Zeichen in einen Editor zu tippen. Neu ist, wie viel Arbeit zwischen einem Issue und einem fertigen Pull Request inzwischen an Agenten abgegeben werden kann.
Der Editor ist nicht mehr zwingend der Mittelpunkt
Bei einem normalen Feature lag früher ein großer Teil der Handarbeit zwischen Repository öffnen und Pull Request erstellen: relevante Stelle finden, Code ändern, Tests laufen lassen, Fehler beheben.
GitHub beschreibt den Copilot cloud agent als Hintergrundagenten mit eigener Entwicklungsumgebung. Er kann ein Repository untersuchen, Änderungen machen, Tests und Linter ausführen und anschließend einen Pull Request oder zunächst einen Branch mit Diff zurückgeben.
Wenn ich einem Agenten ein sauber abgegrenztes Issue übergebe, besteht meine Arbeit damit nicht mehr zwangsläufig darin, jede Zeile selbst zu schreiben. Ich muss vorher klar genug beschreiben, was geändert werden soll, und hinterher beurteilen, ob der Patch technisch passt.
Aspire 13.2 ist auf Agenten-Workflows ausgelegt
Mit Aspire 13.2 kam eine CLI, die Microsoft ausdrücklich als „AI-agent-native“ bezeichnet. Agenten können eine AppHost-Umgebung starten, Ressourcen neu starten, auf Zustände warten und strukturierte Ausgaben lesen. Mit --isolated lassen sich mehrere Umgebungen parallel starten, ohne dass sich zwei Agenten gegenseitig Ports oder Secrets kaputtmachen.
Code zu erzeugen ist nur ein Teil des Workflows. Danach muss die Anwendung tatsächlich laufen. Ein Dev-Server hängt, ein Port ist belegt, eine Environment Variable fehlt oder ein Service startet nicht. Ohne Zugriff auf Laufzeit und Telemetrie sieht der Agent solche Fehler oft nur indirekt über Terminalausgaben.
Aspire versucht deshalb, auch die Umgebung selbst für Agenten zugänglich zu machen. Services, Container, Datenbanken und ihre Beziehungen liegen in einem Application Model. Logs und Telemetrie lassen sich zentral abfragen; einzelne Ressourcen können neu gestartet werden, ohne den kompletten Stack abzuschießen.
Mich interessiert daran mehr als die Frage, ob ein Modell eine Funktion fünf Sekunden schneller generiert. Ein Agent wird für echte Projekte erst dann nützlich, wenn er nach dem Schreiben auch mit der laufenden Anwendung umgehen kann.
Mehr erzeugter Code heißt mehr Review
Ein Agent kann in wenigen Minuten einen großen Diff produzieren. Bei uns würde ich danach zuerst prüfen, ob er das vorhandene Muster im Repository übernommen, nur relevante Dateien angefasst und sinnvolle Tests ergänzt hat. Neue Abhängigkeiten oder größere Architekturänderungen würden deutlich genauer geprüft.
Bei selbst geschriebenem Code kenne ich normalerweise den Gedankengang hinter einer Entscheidung. Bei einem größeren Agenten-Patch muss ich ihn teilweise erst aus dem Diff rekonstruieren.
Copilot Code Review arbeitet inzwischen agentisch und kann breiteren Repository-Kontext einbeziehen. Seit Anfang September kann Copilot in einer Public Preview Pull Requests sogar freigeben, wenn Administratoren diese Funktion ausdrücklich einschalten. Standardmäßig ist das deaktiviert.
Bei einem Kundenprojekt würde ich daraus trotzdem nicht ableiten, dass zwei Agenten hintereinander einen menschlichen Review ersetzen. Gerade bei Security, Datenmodellen, Authentifizierung oder größeren Architekturänderungen ist eine grüne CI kein Beweis dafür, dass die Lösung gut ist.
Manuelles Programmieren verschwindet trotzdem nicht
Fowlers Satz ist zugespitzt. Wörtlich würde ich ihn nicht übernehmen.
Wenn ich in einer bekannten Datei eine Condition ändern, einen Typ korrigieren oder einen kleinen Query-Parameter ergänzen will, kann ich das selbst oft schneller erledigen, als einen Agenten dafür sauber aufzusetzen.
Wer Code nicht versteht, hat außerdem beim Review ein grundsätzliches Problem. Ein Agent kann einen überzeugend aussehenden Patch liefern, der trotzdem eine schlechte Abstraktion einführt oder Sicherheitsannahmen verletzt, die im Ticket gar nicht erwähnt wurden. Ohne eigenes technisches Verständnis sieht ein sauber formatierter Diff schnell besser aus, als er ist.
Die Aussage „Entwickler müssen bald nicht mehr programmieren können“ geht deshalb an dem vorbei, was diese Tools aktuell zeigen. Code lesen, schreiben und beurteilen zu können bleibt die Grundlage dafür, Agenten sinnvoll zu kontrollieren. Was an Gewicht verliert, ist eher das manuelle Tippen als Maß für Produktivität.
Was wir bei Quavon daran messen würden
Für unsere Arbeit ist die Zahl erzeugter Codezeilen ziemlich uninteressant.
Bei unseren Repositories wären nach einem Agenten-Lauf vor allem diese Werte relevant: Ist das Issue wirklich erledigt? Sind die Tests grün? Wie viel unnötiger Diff ist entstanden? Wie lange dauern Review und Cleanup? Eingriffe während des Laufs würde ich separat zählen.
Ein Agent, der in drei Minuten 800 Zeilen schreibt und danach eine halbe Stunde Korrekturarbeit verursacht, ist nicht automatisch produktiver als jemand, der die Änderung in zwanzig Minuten sauber selbst macht.
Ein guter Lauf sieht für mich anders aus: Der Agent untersucht eine klar abgegrenzte Aufgabe, baut eine passende Änderung, führt die Tests aus und gibt einen überschaubaren Diff zurück, den ich in wenigen Minuten nachvollziehen kann.
An diesen Werten würde ich Fortschritt eher messen als an Tokens pro Sekunde oder daran, wie selten jemand die Tastatur berührt.
Der schwierige Teil bleibt
Anforderungen sind oft unklar. Bestehende Systeme haben historische Entscheidungen, die in keinem Ticket stehen. Zwei technisch korrekte Lösungen können langfristig völlig unterschiedlich teuer sein. Ein Test kann grün sein und das Produkt trotzdem falsch funktionieren.
Diese Probleme sind nicht neu. Agenten machen nur sichtbarer, wie wenig der Wert von Software Engineering an der Zahl getippter Zeilen hing.
Fowlers „absolutely over“ funktioniert als Zuspitzung. Für den Entwickleralltag würde ich es enger formulieren: Das Tippen wird billiger. Die Verantwortung für das Ergebnis nicht.
Quellen
Golem, 7. September 2026: „Typing Code is absolutely over“ https://www.golem.de/news/softwareentwicklung-typing-code-is-absolutely-over-2609-212699.html
TechSpot, 7. September 2026: „A Microsoft engineer says 'typing code is absolutely over,' here's what he means“ https://www.techspot.com/news/113752-microsoft-engineer-typing-code-absolutely-over-github-copilot.html
Microsoft Aspire Blog, 7. April 2026: „Agentic development aspirations: build, run, observe — without more Markdown“ https://devblogs.microsoft.com/aspire/agentic-dev-aspirations/
Microsoft Aspire Blog, 23. März 2026: „Announcing Aspire 13.2“ https://devblogs.microsoft.com/aspire/aspire-13-2-announcement/
GitHub Changelog, 1. April 2026: „Research, plan, and code with Copilot cloud agent“ https://github.blog/changelog/2026-04-01-research-plan-and-code-with-copilot-cloud-agent/
GitHub Changelog, 1. September 2026: „Copilot code review can now approve pull requests“ https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/