Donn Felker, AI Platform Lead bei Polygon, zuvor bei Tinder und seit zehn Jahren Android-Spezialist, veröffentlicht am 14. September 2026 einen Essay über das Verschwinden des Software-Engineering, wie er es praktiziert hat. Er datiert seine Erkenntnis auf Juli 2025, gestützt auf drei Tatsachen. Er baute ein vollständiges SaaS, ohne eine Zeile Code zu schreiben. Bei Tinder führte ein zweitausend Wörter langer Prompt in zehn Minuten fehlerfrei eine Migration einer Threading-Bibliothek aus, die früher sechs bis acht Stunden pro Instanz dauerte. Schließlich sah er fachfremde Personen reale Produkte ausliefern: Ein CFO baute sein Finanz-Operations-Tool mit der Claude-App, ein Fitnessstudio-Manager seine Coaching-Plattform. Seine Schlussfolgerung: Es ging nie um das Programmieren, sondern um das Ausführen — Code war nur ein Wegezoll.
Der Essay erklärt dann die Angst der Ingenieure anhand zweier sozialpsychologischer Konzepte. Occupational categorization reduziert eine Person auf ihren Beruf; professional identity centrality macht diesen Beruf zur Grundlage ihres Werts. Verschiebt sich die Alltagsarbeit auf einen Agenten, gerät die Identität ins Wanken: entweder zurückfallen oder den eigenen Ersatz trainieren.
Felker schlägt das Bild eines Hebel-Pendels zwischen Produkt und Engineering vor. Der Agent verschiebt den anfänglichen Hebel zum Produkt hin, das an einem Nachmittag einen Prototyp erhält. Doch Komplexität und Skalierung ziehen den Hebel zurück zum Engineering: ein CFO, der nach zwei Monaten in derselben Claude Cowork-Sitzung feststeckt, ohne zu wissen, wo sein Code liegt; ein Fotograf, dessen Base44-App seine Medien auf Google Drive speicherte, zu nicht tragbaren Übertragungskosten. Der Ingenieur behebt das Problem, richtet Architektur und Guardrails ein und gibt die Kontrolle dann zurück. Jede Schwingung dämpft sich ab, bis zur nächsten Modellversion.
Die Rolle, die sich am Gleichgewichtspunkt herausbildet, ist der agentic builder, eine Mischform aus Ingenieur und Product Lead. Reine Spezialisten an beiden Extremen werden als gefährdet dargestellt. Der vorgeschlagene Weg hat zwei Schritte: erstens das eigene Wissen in Skills und Verfahren kodifizieren, die von Agenten ausführbar sind, was das Individuum skalierbar macht und es vom Operator zum Orchestrator verschiebt; zweitens systemisches Denken übernehmen — Business-Denken für den Ingenieur, Engineering-Denken für die fachfremde Person — mit einer Liste von sechs Anforderungen an den Agenten: Architektur, Guardrails, Backups, Versionierung, Governance, Observability.
Der Autor setzt einen Horizont von sechs Monaten für den Übergang und schließt mit der Figur des Builders, der sowohl eine Bilanz als auch einen Execution Trace lesen kann.