Future{hacks}: Wenn der Code nicht mehr das Problem ist
Trending Topics auf Google als bevorzugte Nachrichtenquelle festlegen.
Noch nie war es so einfach, Software zu bauen. Und selten war so unklar, wofür man einen Entwickler eigentlich noch braucht.
Coding Agents schreiben heute in Minuten Funktionen, für die früher Stunden oder Tage draufgingen. Laut der aktuellen Developer Ecosystem Survey von JetBrains nutzen 90 Prozent der professionellen Entwickler solche Tools zumindest wöchentlich, 68 Prozent täglich. Rund ein Drittel zählt JetBrains inzwischen zu den sogenannten Agentic Coders. In dieser Gruppe werden nach eigener Einschätzung durchschnittlich 84 Prozent des Codes vollständig von Agents erzeugt.
Das verändert mehr als unseren Werkzeugkasten. Es verändert langsam auch das Selbstverständnis des Berufs.
Softwareentwickler haben solche Verschiebungen schon öfter erlebt. Aus Generalisten wurden Spezialisten, aus Problemlösern in vielen Projekten klar definierte Ressourcen, die nach Rolle, Verfügbarkeit und Tagessatz eingekauft wurden. Jetzt trifft AI ausgerechnet jenen Teil der Arbeit, der sich besonders gut beschreiben, standardisieren und delegieren lässt.
Deshalb wird gerade eine andere Frage interessant: Wenn Code selbst immer leichter verfügbar wird, wo liegt dann künftig der eigentliche Wert eines Entwicklers?
Als Entwickler noch mehr vom Problem kannten
Die frühen Phasen der Softwareentwicklung sollte man nicht romantisieren. Systeme waren kleiner, Anforderungen überschaubarer und viele der heutigen Sicherheits-, Skalierungs- und Compliance-Fragen existierten in dieser Form schlicht nicht.
Trotzdem war die Rolle oft breiter. Wer eine Anwendung baute, kannte meist einen größeren Teil des Systems, sprach direkt mit Nutzern, verstand die Daten und sah relativ schnell, ob die eigene Lösung im Alltag funktionierte.
Mit dem Wachstum der Branche wurde diese Arbeitsweise schwieriger. Unternehmen brauchten größere Systeme, mehr Geschwindigkeit und höhere Verfügbarkeit. Spezialisierung war deshalb eine logische Entwicklung und in vielen Bereichen schlicht notwendig. Ein Spezialist für Datenbanken muss kein hervorragender Frontend-Entwickler sein. Security erfordert anderes Wissen als Produktentwicklung. Niemand möchte, dass derjenige, der am Nachmittag eine Benutzeroberfläche umbaut, am Vormittag nebenbei die Kryptografie eines Zahlungssystems entwirft.
Mit jeder zusätzlichen Spezialisierung entstand aber auch eine neue Schnittstelle. Das Geschäftsproblem wurde aufgenommen, analysiert, priorisiert, in Tickets übersetzt, technisch spezifiziert und anschließend umgesetzt. Je größer die Organisation, desto leichter konnte der Entwickler am Ende dieser Kette landen und nur noch einen kleinen Ausschnitt davon sehen.
Aus dem Menschen, der ein Problem möglichst vollständig versteht und löst, wurde in vielen Projekten jemand, der eine klar abgegrenzte Aufgabe implementiert.
Dann wurde der Entwickler zur Kapazität
Auch wir Softwaredienstleister haben diese Entwicklung mitgetragen.
Kunden kauften Entwicklerkapazität ein, weil sie selbst nicht genug davon hatten. Das konnte als klassisches Projekt passieren, als Freelancer-Modell oder über Arbeitnehmerüberlassung. Für viele Unternehmen war das pragmatisch und wirtschaftlich sinnvoll.
Der Einkauf war außerdem angenehm konkret. Zwei Backend-Entwickler, ein Frontend-Spezialist und eventuell noch jemand für DevOps. Die Rollen ließen sich ausschreiben, Tagessätze vergleichen und relativ einfach in ein Projektbudget übersetzen.
Dadurch verschob sich aber auch die Wahrnehmung von Entwicklungsleistung. Eigentlich wollte der Kunde ein Geschäftsproblem lösen. Gekauft wurde sehr oft eine bestimmte Menge technischer Arbeitszeit.
Wer lange genug in dieser Branche arbeitet, kennt die Konsequenz. Ein Entwickler kann monatelang bei einem Kunden sitzen, jeden Sprint zuverlässig Tickets abschließen und trotzdem kaum verstehen, warum das Produkt überhaupt existiert. Das liegt nicht zwingend am Entwickler. Häufig wurde er genau für diese Rolle eingekauft.
AI trifft nun besonders jene Tätigkeiten, die sich bereits sauber in Aufgabenpakete zerlegen lassen.
Plötzlich kann jeder eine App bauen
Wer heute einem modernen Coding Agent eine klar beschriebene Aufgabe gibt, bekommt teilweise Ergebnisse, für die früher mehrere Tage Entwicklungsarbeit nötig gewesen wären.
Eine Login-Maske, Datenbanktabellen, ein Dashboard und einige Geschäftsregeln lassen sich in erstaunlicher Geschwindigkeit erzeugen. Aus einer Idee entsteht innerhalb kurzer Zeit etwas, das aussieht und sich anfühlt wie echte Software.
Aus Kundensicht liegt eine Schlussfolgerung nahe: Wenn ich die Anwendung selbst beschreiben kann und AI daraus funktionierenden Code erzeugt, warum brauche ich dann überhaupt noch ein Entwicklungsteam?
Bei einem Prototyp kann diese Rechnung inzwischen durchaus aufgehen. Kritisch wird es meist dort, wo aus der Demo ein belastbares System werden soll.
Nehmen wir einen Vertriebsprozess. Ein Kunde möchte eine Anwendung, die Angebote automatisch erzeugt. Kundendaten auswählen, Produkte hinzufügen, Preis berechnen, PDF generieren. Für diesen ersten Schritt braucht es heute oft erstaunlich wenig Zeit.
Dann kommen die Details. Welche Rabatte darf welcher Verkäufer geben? Welche Preislisten gelten bei internationalen Kunden? Was passiert mit bestehenden Sondervereinbarungen? Warum berechnet das alte ERP bei bestimmten Produktkombinationen einen anderen Preis? Welche Daten dürfen überhaupt in das neue System? Wer genehmigt einen Preis unter einer bestimmten Marge? Und welche Ausnahme kennt jeder im Vertrieb, obwohl sie nie irgendwo sauber dokumentiert wurde?
An diesem Punkt fehlt selten nur noch eine zusätzliche Funktion. Meist fehlt Wissen über den tatsächlichen Prozess.
Das schwierigste Wissen steht in keinem Prompt
Unternehmenskontext liegt fast nie vollständig an einem Ort.
Er steckt in Datenbanken, Tickets, Architekturentscheidungen, Verträgen, E-Mails und alten Schnittstellen. Ein Teil liegt in Confluence, ein anderer in einem Excel-Sheet, das angeblich niemand mehr verwendet. Besonders kritisches Wissen steckt oft in den Köpfen jener Mitarbeiter, die seit Jahren wissen, welche Ausnahme wann gilt.
Dazu kommt, dass dieses Wissen nicht immer widerspruchsfrei ist. Vertrieb und Finance beschreiben denselben Prozess unterschiedlich. Der Fachbereich fordert etwas, das technisch längst durch eine andere Entscheidung überholt wurde. Eine Schnittstelle sieht im API-Handbuch sauber aus, verhält sich im Produktivbetrieb aber seit Jahren anders.
Ein Coding Agent kann mit gutem Kontext enorm viel leisten. Die eigentliche Arbeit beginnt deshalb immer häufiger damit, diesen Kontext überhaupt zusammenzubringen und beurteilen zu können, was davon relevant, veraltet oder widersprüchlich ist.
Genau in diese Richtung verschiebt sich auch die aktuelle Forschung. Google Research untersucht 2026 beispielsweise nicht mehr nur, ob ein Software-Agent eine einzelne Programmieraufgabe korrekt löst. Untersucht wird auch, ob er bestehende Standards versteht, Prozesse einhält und sinnvoll mit Entwicklern zusammenarbeitet.
Für Entwickler verändert sich dadurch der Schwerpunkt. Früher musste man einen Lösungsweg vollständig selbst im Code formulieren. Heute muss man zusätzlich dafür sorgen, dass ein Agent genügend brauchbares Wissen bekommt, um überhaupt einen sinnvollen Vorschlag machen zu können. Danach braucht es weiterhin jemanden, der erkennt, ob das Ergebnis fachlich und technisch passt.
Mit klassischem Prompt Engineering hat das nur begrenzt zu tun. Gemeint ist eher die Fähigkeit, ein unscharfes Problem so weit zu verstehen, dass daraus eine belastbare technische Entscheidung entstehen kann.
Erfahrung bekommt dadurch einen neuen Hebel
Dass ein Junior mit einem Coding Agent heute Dinge umsetzen kann, für die früher deutlich mehr Erfahrung nötig war, ist zunächst einmal ein Fortschritt. Die Einstiegshürde in Softwareentwicklung sinkt und viele Tätigkeiten werden schneller zugänglich.
Gleichzeitig wird eine andere Art von Erfahrung wichtiger. Man muss erkennen können, wann eine vorgeschlagene Lösung zwar plausibel aussieht, im konkreten System aber trotzdem falsch ist.
Ein erfahrener Entwickler sieht möglicherweise, dass eine Datenstruktur in sechs Monaten Probleme verursachen wird. Er fragt nach, warum eine Berechtigung genau so modelliert wurde. Er kennt die Folgen einer scheinbar kleinen Architekturentscheidung oder merkt, dass ein Kunde gerade eine technische Lösung für ein organisatorisches Problem bestellt.
Diese Fähigkeiten waren schon immer wertvoll. Durch AI werden sie nur deutlicher sichtbar, weil die reine Umsetzung weniger exklusiv wird.
Wer seinen Wert bisher hauptsächlich darüber definiert hat, schneller Code schreiben zu können als andere, wird sich deshalb neu orientieren müssen. Erfahrung zeigt sich künftig stärker darin, bessere Entscheidungen zu treffen und Probleme früher zu erkennen.
Und plötzlich heißt der Freelancer „Forward Deployed Engineer“
An diesem Punkt wird auch der derzeit populäre Begriff Forward Deployed Engineer interessant.
OpenAI, Anthropic und andere AI-Unternehmen bauen solche Rollen aktuell sichtbar aus. OpenAI beschreibt den Forward Deployed Engineer als jemanden, der eng mit Kunden arbeitet, Probleme identifiziert, Lösungen entwickelt und sie bis in den produktiven Betrieb begleitet. Anthropic sucht ähnliche Profile mittlerweile auch in München.
Der Titel klingt neu, die Grundidee ist es deutlich weniger.
Wer früher als erfahrener Freelancer oder externer Entwickler direkt beim Kunden gearbeitet hat, kennt viele Bestandteile dieser Rolle. Man sitzt nicht irgendwo weit entfernt in einer Delivery-Struktur und bekommt ein fertiges Ticket. Man spricht mit dem Fachbereich, versteht das Problem, baut eine Lösung und erlebt anschließend, ob sie im Alltag tatsächlich funktioniert.
Auch bei Arbeitnehmerüberlassung konnte genau dieser Effekt entstehen. Der Entwickler wurde Teil des Kundenteams und bekam dadurch Kontext, den ein externes Projektteam oft erst über Wochen oder Monate aufbauen musste.
Neu ist heute vor allem der technische Hebel. Ein erfahrener Entwickler mit modernen Coding Agents kann einen deutlich größeren Teil der Umsetzung selbst übernehmen. Dadurch wird die Nähe zum Problem wirtschaftlich noch interessanter.
Vielleicht beschreibt der Forward Deployed Engineer deshalb weniger eine völlig neue Rolle als eine alte Stärke unter neuen technischen Bedingungen: technische Kompetenz möglichst nah an das reale Problem zu bringen.
Was Kunden künftig eigentlich einkaufen sollten
Für Kunden folgt daraus eine unangenehme Konsequenz.
AI macht technische Kapazität leichter verfügbar. Damit verliert reine Kapazität als alleiniges Einkaufskriterium an Aussagekraft.
Die Frage „Wie viele Entwickler bekomme ich für mein Budget?“ wird natürlich nicht verschwinden. Spannender wird aber, wie schnell ein Team den notwendigen Kontext aufbauen kann. Versteht es die Domäne? Erkennt es widersprüchliche Anforderungen? Kann es mit bestehenden Systemen umgehen? Hinterfragt es eine Anforderung, wenn sie offensichtlich nicht zum eigentlichen Ziel passt?
Das betrifft auch uns als Softwaredienstleister.
Wenn wir AI einsetzen und dadurch schneller entwickeln können, muss ein Kunde davon irgendwann etwas merken. Dieselbe Teamgröße lediglich mit besseren Werkzeugen weiterzuverkaufen, wird auf Dauer keine besonders überzeugende Geschichte sein.
Ebenso wenig reicht das gegenteilige Versprechen, drei Entwickler mit AI würden künftig automatisch die Arbeit von zehn übernehmen. Drei Menschen können heute sehr viel schneller Software produzieren. Sie können dadurch auch sehr viel schneller die falsche Software produzieren.
Der Unterschied liegt weiterhin darin, wie gut sie das Problem verstehen.
Unser Future{hacks} Fazit
Softwareentwickler haben ihren Beruf schon mehrfach verändert. Aus Generalisten wurden Spezialisten, aus Problemlösern in manchen Projekten austauschbare Ressourcen, aus Freelancern werden heute teilweise Forward Deployed Engineers.
AI wird diese Entwicklung weiter beschleunigen. Ein Teil der Arbeit, für die Entwickler bisher bezahlt wurden, lässt sich bereits automatisieren und dieser Anteil dürfte wachsen. Den eigenen Wert weiterhin hauptsächlich über die Menge geschriebenen Codes zu definieren, wäre deshalb eine riskante Wette.
Je leichter die technische Umsetzung wird, desto mehr zählt der Kontext, in dem sie stattfindet. Unternehmen brauchen Menschen, die erkennen, welche Informationen fehlen, welche Entscheidung getroffen werden muss und wann eine technisch elegante Lösung am eigentlichen Problem vorbeigeht.
Vielleicht führt uns AI damit tatsächlich zu einer älteren Form von Softwareentwicklung zurück: Entwickler sitzen wieder näher am Nutzer, verstehen mehr vom Problem und tragen einen größeren Teil der Verantwortung für das Ergebnis.
Der Unterschied zu früher ist nur, dass heute noch ein ziemlich leistungsfähiger Kollege mit im Raum sitzt, der niemals müde wird und trotzdem erstaunlich oft nicht weiß, worum es eigentlich geht.
Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.
