90 Prozent Einsparungen – wie das?
Noch vor einem Jahr war ich sehr skeptisch, was KI-Programmiertools angeht – und bei vielen bin ich es immer noch. Zum Beispiel fühlten sich Plattformen wie Loveable und Bolt eher wie glorifizierte Low-Code-Tools an, und diverse VS-Code-Forks warten zwar mit einer teilweise nützlichen, oft aber nervigen Autovervollständigung auf.
Wie ist das aber nun mit den aktuellen Tools?
Nehmen wir als Beispiel ein konkretes, 08/15-Projekt: In einem Unternehmen soll ein internes Tool entwickelt werden. Die Datenmodellierung ist weitgehend abgeschlossen, die Entwickler müssen nun eine Webanwendung zur Widget-Verwaltung implementieren.
Früher kümmerte sich ein kleines Team um die Einrichtung von CI/CD, die Entwicklung von Datenzugriffsmustern und den Aufbau der Kernservices. Dann wurden eine Menge CRUD-Seiten, vielleicht auch Dashboards und Grafiken für die Nutzer erstellt. Schließlich fügte das Team (hoffentlich) ein paar automatisierte Unit-/Integrations-/End-to-End-Tests hinzu, um sicherzustellen, dass alles halbwegs stabil ist, und lieferte das Produkt dann aus, so etwa einen Monat später.
Diese ganzen Tasks sind aber nur die unmittelbaren Arbeit. Denn alle Projektbeteiligten verursachen darüber hinaus zusätzlichen Koordinationsaufwand: Standup-Meetings, Ticket-Management, Code-Reviews, Schnittstellen zwischen Frontend und Backend, Warten, dass jemand den Blocker für die eigene Aufgabe erledigt. Die eigentliche Programmierung macht oft nur einen Bruchteil der Arbeitszeit aus.
Fast alles davon kann man mit einer agentenbasierten CLI in wenigen Stunden erledigen. Ich habe Claude eine Unit-/Integrationstestsuite (300+ Tests) in wenigen Stunden schreiben lassen. Und das für ein recht komplexes internes Tool. Hätte ich das von Hand gemacht, hätte mich das – und auch einige andere erfahrene und von mir sehr geschätzte Entwickler – Tage gekostet.
Agentenbasierte Entwicklertools sind inzwischen richtig gut darin, Geschäftslogikspezifikationen in brauchbar geschriebene APIs und Dienste umzusetzen.
Projekte, die sonst Monate dauerten, dauern jetzt eine Woche. Dabei bleibt die Zeit, die man über die Umsetzung nachdenkt, gleich – aber die Zeit zum Implementieren geht deutlich zurück!
Das ermöglicht kleinere Teams und damit eine Umkehrung von Brooks' Gesetz: Statt eines immer weiter steigenden Kommunikationsaufwands je zusätzlichem Teammitglied – verschwindet er einfach. Eine Handvoll Menschen kann auf einmal viel mehr erreichen.
Auf den ersten Blick hört das nach einer schlechten Nachricht für die Softwareentwicklungsbranche an – doch die Wirtschaftswissenschaft sagt uns etwas Anderes.
Zum Beispiel Jevons Paradoxon (g+) : Es besagt, dass, wenn etwas billiger produziert werden kann, die Nachfrage steigt und nicht nur die gleiche Menge für weniger Geld hergestellt wird.
Beispiel elektrisches Licht: Als es aufkam, wurden zwar weniger Kerzen und Gasleuchten verkauft – aber im Gegenzug viel, viel mehr künstliches Licht erzeugt.
Dies gilt auch für die Softwareentwicklung, auch hier gibt es eine große, versteckte Nachfrage: In fast jeder Firma gibt es zur Nachverfolgung von wichtigen Business-Prozessen Hunderte oder gar Tausende von Excel-Sheets, deren Informationen besser in einer SaaS-Anwendung aufgehoben wären. Bei einem Angebot, eines der Sheets für 50.000 US-Dollar in eine App zu packen, würde man sich wohl nur bei den wichtigsten dafür entscheiden. Bei 5.000 Dollar für einen guten Entwickler plus KI-Tooling gibt es ganz plötzlich für viel mehr Prozesse ein Interesse und damit viel mehr Nachfrage.
Domänenwissen ist der einzige Schutz
Was fangen wir also damit an? Im Moment ist der Mensch als Agentenbetreuer immer noch sehr wertvoll. Er überprüft seine Arbeit, schlägt das Vorgehen vor und schreitet ein, wenn der Agent in die falsche Richtung hin entwickelt. Reines Yolo-Vibe-Coding kann schnell in totalem Chaos enden, aber mit einem eingebundenen Menschen kann man sehr gute Software in extrem kurzer Zeit entwickeln.
Entwickler, die diese Technik beherrschen, können also sehr effektive Problemlöser sein. Ihr Fachwissen und ihr Branchen-Know-how haben enormes Gewicht. Sie wissen um die besten Architekturentscheidungen, sie wissen, welches Framework und welche Bibliotheken am besten sind.
Vorausgesetzt, der Entwickler oder die Entwicklerin hat obendrein noch ein gutes Verständnis der fachlichen Domäne, kommen wir dem vielbeschworenen 10x-Entwickler schon recht nahe. Die Kombination aus motiviertem Entwickler, fachlichem Experten für den Geschäftsbereich und KI-Agenten kann sehr stark sein und sie wird, denke ich, auch immer verbreiteter. Statt eines großen Teams aus Business- und Softwarespezialisten wird es in Zukunft eine engere Zusammenarbeit von weniger Menschen geben.
Die Iterationen werden viel schneller und Software zu einer Art Wegwerfprodukt; denn wenn die Richtung nicht stimmt, wirft man es weg und fängt von vorne an, mit all dem Wissen, das man davor gesammelt hat. Das erfordert ein ziemliches Umdenken, denn die harte Arbeit wird das Konzipieren sein, nicht das Tippen.
Lass dich nicht überraschen
Die Agenten und Modelle werden sehr schnell immer besser, in den Benchmarks wird das, wie gesagt, aus meiner Sicht gar nicht ausreichend abgedeckt. Opus 4.5 ist offenbar in der Lage, 10 bis 20 Minuten langen Sessions zu folgen.
Wir sehen gerade einmal die ersten Ergebnisse der Hunderten Milliarden US-Dollar, die in 200-GB-GPUs geflossen sind, und ich bin mir sicher, dass neuere Modelle die älteren sehr schnell überflüssig werden lassen.
Ich begegne immer wieder Entwicklern, die sich dagegen wehren. Ich kenne die gängigen Argumente: LLMs machen zu viele Fehler, ich verstehe Anwendung XY nicht, man spart keine Zeit.
Diese Behauptungen werden aber immer schneller widerlegt – und sie erinnern mich an die vielen Desktop-Entwickler, die 2007 nicht viel vom iPhone hielten. Wir wissen, wie das ausgegangen ist: Die Smartphones wurden immer schneller und die mobilen Betriebssysteme immer leistungsfähiger.
Ich denke, dass sich Entwickler unbedingt auf diese Veränderung einstellen müssen. Sie wird nicht über Nacht passieren, vor allem große Unternehmen laufen dieser Entwicklung noch hinterher, gefangen in einem Netz aus Bürokratie, Lieferantenvereinbarungen und Managementstrukturen. Das alles macht sie für kleinere Konkurrenten extrem angreifbar.
Wer allerdings in einem kleinen Unternehmen arbeitet und KI-Tools nutzen kann, sollte das tun. Der Entwicklerjob wird sich ändern. Klar, auch Software hat sich immer verändert; nur werden die aktuellen Veränderungen sehr viel schneller vonstatten gehen, als irgendjemand vorhersagen kann.
Ein Einwand, den ich oft höre ist, dass LLMs nur bei Greenfield-Projekten gut seien. Das denke ich überhaupt nicht. Ich habe schon sehr viel Zeit damit verbracht, drei Jahre alte Programme zu verstehen, deren Entwickler schon lange nicht mehr im Unternehmen waren.
Agenten machen so etwas sehr viel einfacher, sie erklären, was der Code macht, sie finden Bugs, schlagen eine Lösung vor. Ich würde lieber ein Repo übergeben bekommen, das von einem guten Entwickler mit einem Agenten zusammen geschrieben wurde, als eines, das von einem Auftragsentwickler geschrieben wurde, eine zweifelhafte Qualität hat und nur ein Spaghetti-Chaos aus Klassen und Methoden ist.
Übersetzung: Jennifer Fraczek
- Anzeige Hier geht es zu Künstliche Intelligenz: Wissensverarbeitung bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.