3 Punkte von GN⁺ 2025-12-09 | 1 Kommentare | Auf WhatsApp teilen
  • Durch den Einsatz von Agentic-Coding-Werkzeugen sinken die Arbeitskosten bei der Softwareentwicklung deutlich
  • Ein internes Web-App-Projekt, das früher einen Monat dauerte, wird jetzt innerhalb einer Woche fertiggestellt
  • Tools wie Claude Code erzeugen innerhalb weniger Stunden Hunderte von Tests, wodurch sich das Modell zu kleinen Teams mit großen Ergebnissen verschiebt
  • Der Kostenrückgang kann durch den Jevons Paradox einen potenziellen Nachfrageboom auslösen, sodass mehr Organisationen individuelle Software entwickeln
  • Die Domain-Kenntnis der Entwickler und die Fähigkeit zur Zusammenarbeit zwischen Mensch und Agent werden zu einem neuen Wettbewerbsfaktor, und 2026 wird ein starker branchweiter Wandel erwartet

Veränderung der Kostenstruktur in der Softwareentwicklung

  • Die Verbreitung von Open Source war der erste Wendepunkt, der die Einstiegskosten der Softwareentwicklung senkte
    • Früher waren für SQL Server, Oracle usw. jährliche Lizenzkosten im Bereich von mehreren zehntausend US-Dollar nötig, während MySQL den kostenlosen Aufbau von Netzwerkanwendungen ermöglichte
  • Danach senkte die Cloud-Einführung zwar die Anfangsinvestitionen, insgesamt war die Kostensenkung aber begrenzt
  • In den letzten Jahren erhöhten dagegen TDD, Microservices, komplexe React-Frontends und Kubernetes die Komplexität, sodass die Kostenreduktion stagnierte
  • KI-Agenten dagegen reduzieren den Arbeitsaufwand im Entwicklungsprozess deutlich

Warum 90 Prozent Ersparnis

  • Bis Anfang 2025 war man KI-Coding-Werkzeugen skeptisch gegenüber, doch kürzlich hat eine Agentic-Coding-CLI echte Skaleneffekte nachgewiesen
  • Als Beispiel erzeugte Claude Code für ein internes Tool mehr als 300 Testcodes innerhalb weniger Stunden
  • Ein Projekt, das früher einen Monat dauerte, kann nun innerhalb einer Woche abgeschlossen werden
    • Die Implementierungszeit sank stark, die Denk-/Planungszeit blieb jedoch gleich
    • Durch kleinere Teams verschwand der Kommunikations-Overhead
  • Insgesamt erreichen so weniger Personen mehr als das Zehnfache an Produktivität

Potenzieller Nachfrageboom

  • Der Kostenrückgang wird durch das Jevons Paradox erklärt, das die Nachfrage in der gesamten Branche nicht reduziert, sondern ausweitet
  • Viele Organisationen nutzen noch Excel-basierte Arbeitsprozesse, wodurch es Nachfrage gibt, diese in SaaS-Apps zu überführen
  • Wenn ein bisheriges Angebot von 50.000 auf etwa 5.000 US-Dollar fällt, werden selbst nicht zwingend erforderliche Projekte zu potenziellen Entwicklungszielen
  • Daher ist ein Anstieg der Gesamtproduktion in der gesamten Softwarebranche wahrscheinlich

Domain-Wissen als neue Wettbewerbskraft

  • Nach wie vor sind menschliche Aufsicht und Urteilsvermögen unverzichtbar
    • Der Ansatz des Agenten muss überprüft und falsche Pfade korrigiert werden
  • Entwickler, die diese Technik beherrschen, steigern ihre Fähigkeit zur Lösung von Business-Problemen deutlich
  • Die Kombination aus Domain-Wissen und technischer Expertise wird zur zentralen Wettbewerbsfähigkeit
    • Geschäftsfachleute und Entwickler können in kleinen Kollaborationseinheiten schnell iterativ entwickeln
  • Software wird zu einem „verwerfbaren Asset“; bei falscher Ausrichtung kann sie sofort verworfen und erneut entwickelt werden

Auf den Wandel vorbereiten

  • LLMs und Agentenmodelle verbessern sich schnell, doch bestehende Benchmarks bilden dies noch nicht ab
    • Beispiel: Opus 4.5 hält 10 bis 20 Minuten Sitzungen stabil
  • Mit großangelegten Investitionen in GPU-Infrastruktur ist eine starke Leistungssteigerung der Modelle in Zukunft zu erwarten
  • Einige Entwickler behaupten weiterhin, dass „LLMs zu fehlerhaft sind“ oder „nicht zeitersparend“ – das ist jedoch zunehmend nicht mehr zutreffend
  • Wie das Beispiel der Desktop-Ingenieure zeigt, die das iPhone 2007 ignorierten, besteht die Gefahr, den Anschluss zu verlieren, wenn man die Veränderung verweigert
  • Große Unternehmen haben wegen ihres bürokratischen Aufbaus einen langsameren Rollout, während kleine Teams sofort profitieren können
  • LLMs sind nicht nur für neue Projekte wirksam, sondern auch für die Analyse und Wartung bestehender Codebasen
    • hohe Effizienz beim Strukturverständnis älterer Codebestände sowie bei der Fehlererkennung und dem Vorschlagen von Korrekturen
  • Infolgedessen ist es sehr wahrscheinlich, dass 2026 der Wendepunkt in der Entwicklungsweise wird

1 Kommentare

 
GN⁺ 2025-12-09
Hacker-News-Kommentare
  • Ich habe gehört, dass Claude Code in nur wenigen Stunden über 300 Tests erstellt hat.
    Aber ich bezweifle, dass diese Tests wirklich das beabsichtigte Verhalten verifizieren und dem nächsten Entwickler klar vermitteln können, wie das System funktioniert.
    Selbst wenn KI schnell Code erzeugt, besteht ein großes Risiko für Qualitätsverlust, wenn man nicht entsprechend sorgfältige Review-Zeit investiert.

  • Ich habe auch versucht, dem Rat zu folgen und mich „aktiv an AI Coding anzupassen“.
    Aber weil ich eher im Bereich Robotik und Embedded arbeite, war es eine sehr langweilige und frustrierende Erfahrung, Web-Apps oder Spiele mit KI zu bauen.
    Wenn ich Cursor bat, ein Problem zu beheben, wurde es eher noch schlimmer, und am Ende war es viel effizienter, Flask und JS direkt selbst zu lernen.
    KI war großartig beim Finden von Dokumentation oder Fehlermeldungen, aber ihr „das Steuer zu überlassen“ hat überhaupt nicht geholfen.

    • Ich hatte eine ähnliche Erfahrung.
      Ich bezweifle, dass die Aussage stimmt, KI bringe „10x Produktivität“.
      Realistisch ist eher, sie wie ein superaufgeladenes Google/Stack Overflow zu verwenden.
      Den Großteil des Codes schreibe ich selbst, und die KI hilft nur bei einfachen Routinearbeiten oder beim Schreiben von Skripten.
    • KI den Code zu überlassen, ist eine Fähigkeit, die man lernen muss.
      Um erfolgreich zu sein, braucht man die Fähigkeit, klar Anweisungen zu geben und Dinge wie einem „Mentor“ zu erklären.
      Wichtig ist die Gewohnheit, Änderungswünsche per Prompt zu formulieren, statt selbst direkt einzugreifen, und dieser Prozess fördert letztlich die Kommunikationsfähigkeit.
  • Wenn man solche Artikel sieht, zeigt sich klar die Wahrnehmungslücke zwischen Entwicklungsteams und Management.
    Die Leute in den oberen Etagen glauben, sie hätten das ganze System mit ein paar Zeilen Anforderungen verstanden, kennen in Wirklichkeit aber kaum die Abhängigkeiten und den Kontext.
    Dass ein gutes Entwicklungsteam diese vagen Anforderungen in ein echtes Produkt verwandelt, ist die eigentliche Kunst, und es gibt noch keine Technologie, die das automatisieren kann.

  • Die Kosten für das bloße Schreiben von Code sind um 90 % gesunken.
    Aber um ein Problem überhaupt in einfachen Code zu übersetzen, braucht man weiterhin viel Erfahrung und Zeit.

    • Der Großteil der Entwicklung ist Wartung von Legacy-Code.
      Claude Code war hervorragend darin, alte Codebasen zu verstehen und zu ändern.
      Es half sogar bei Tests und Debugging, sodass es sich nach einer 10x höheren Produktivität anfühlte.
      Es schreibt nicht einfach nur schneller Code, sondern funktioniert eher wie ein schnelles zweites Gehirn.
    • Dank KI erledige ich jetzt auch schnell kleine Automatisierungsaufgaben, die ich früher aus Bequemlichkeit gar nicht angegangen wäre.
      Innerhalb einer Stunde konnte ich Skripte oder kleine Webservices bauen und damit Probleme lösen.
    • Ich stimme der Aussage zu, dass die Kosten für das Erstellen von CRUD-Apps um 90 % gesunken sind,
      aber eigentlich hätten solche einfachen Aufgaben schon vor KI automatisiert sein sollen.
    • Auch komplexe Systeme sind letztlich nur eine schichtweise aufgebaute Struktur aus einfachem Code.
      Ein LLM fühlt sich an wie ein Upgrade von einer Schaufel auf zehn Bagger,
      aber wenn ein Projekt scheitern wird, dann scheitert es nur schneller.
    • Ob Code einfach ist, hängt letztlich davon ab, wie sehr er Muster aus Online-Beispielen ähnelt.
      Claude Code schreibt selbst komplexen Code gut, solange er innerhalb der gelernten Muster liegt.
  • Wenn die Kosten für maßgeschneiderte Softwareentwicklung wirklich um 90 % gesunken wären,
    müsste der Markt von billigen SaaS-Angeboten überflutet sein, aber in der Realität ist das nicht so.
    Offenbar ist das Schreiben von Code also nicht das größte Problem.

    • Stimmt, die Betriebskosten nach der Entwicklung sind viel höher.
      Wartung, Sicherheit, Upgrades, Hosting, Kundensupport, neue Features und so weiter.
      Das ist der eigentliche Wert, der im SaaS-Abo steckt.
      Bis KI auch diesen Teil löst, dauert es meiner Meinung nach noch 3 bis 5 Jahre.
    • Die tatsächliche Coding-Zeit eines Entwicklers macht nur etwa die Hälfte der gesamten Arbeit aus.
      Der Rest besteht aus Meetings, Abstimmung, Warten und Ähnlichem.
      Selbst wenn die Coding-Kosten um 90 % sinken, bleibt also mehr als die Hälfte der Gesamtkosten bestehen.
      Außerdem schafft KI nicht einmal Zusammenfassungen in natürlicher Sprache zuverlässig,
      daher ist fraglich, ob sie die Bedeutung von Code vollständig verstehen und schreiben kann.
      Zugehöriges Video: YouTube-Link
    • Nur weil Code billiger geworden ist, wird daraus noch kein gutes Business.
      Auch jetzt schon gibt es unzählige SaaS-Produkte, aber selbst mit guten Funktionen ist das Geschäft in der Realität schwierig.
    • SaaS ist ein Bereich, der zwei- bis dreimal mehr Aufwand erfordert als eine einfache App.
      Ein großer Teil des Engineerings ist praktisch Arbeit für Vendor Lock-in.
    • Schon die Annahme, dass der Markt perfekt funktioniert, ist falsch.
      Wegen Plattform-Sichtbarkeit, Vertrauen und algorithmischer Kontrolle ist es für neue SaaS-Anbieter schwer zu wachsen.
      Große Unternehmen kopieren sie schnell, und den Verbrauchern geht zunehmend das Geld aus.
      Der Markt ist also nicht fair, und deshalb wenden sich viele inzwischen dem politischen Bereich zu.
  • Wer schon einmal in einem Großunternehmen gearbeitet hat, wird mit solchen Artikeln kaum etwas anfangen können.
    Bei einer Firma wie Shutterstock muss man zum Beispiel selbst für eine einfache Anfrage fünf Systeme anfassen.
    KI hilft zwar dabei, Code zu verstehen und zu ändern,
    aber dass die gesamten Entwicklungskosten um 90 % gesunken seien, ist überhaupt nicht wahr.

    • Außerdem ist der Autor „Dozent für AI-Entwicklungsworkshops“,
      daher ist dieser Text faktisch eher ein Werbetext für Unternehmen.
  • Zu der Behauptung „Jede Organisation hat Hunderte von Excel-Sheets, und als SaaS wäre das besser“
    würde ich gern fragen, für wen genau das besser sein soll.
    Tabellenkalkulationen können direkt von Menschen mit Domänenwissen bedient werden
    und sind wegen ihrer Zugänglichkeit weiterhin ein mächtiges Werkzeug.

    • Ich liebe Tabellenkalkulationen auch, aber sobald die Komplexität nur ein wenig steigt, schleichen sich viele Fehler ein.
      Formeln und UI sind eng miteinander verknüpft, sodass die interne Logik schwer zu durchschauen ist.
    • Tabellenkalkulationen sind mächtig, aber leicht zu missbrauchen.
      Gerade Excel ist schwer zu warten, und je komplexer es wird, desto mehr denke ich, dass man es besser in Code überführt.
    • Um als Autor zu sprechen: Es ging nicht darum, jedes Sheet in eine Web-App zu verwandeln,
      sondern darum, dass strukturelle Ergänzungen wie Zusammenarbeit, Zugriffskontrolle und Tests nötig sind.
    • Das Problem ist der Zeitpunkt, an dem man erkennt, dass eine Tabellenkalkulation ihre Grenzen überschritten hat.
      Wenn sie wie eine Datenbank benutzt wird oder mehrere Nutzer gleichzeitig damit arbeiten, ist der Punkt für den Umstieg erreicht.
    • Die meisten Tabellenkalkulationen verschwinden mit ihrem ursprünglichen Ersteller.
      Gemeinsame Probleme lösen Lösungen wie SAP,
      aber die meisten Sheets behandeln maßgeschneiderte Probleme mit genau einem einzigen Kunden.
  • Ich habe das Gefühl, dass die 90/90-Regel immer noch gilt.
    KI erledigt die ersten 90 % schnell, aber die restlichen 10 % sind die wirklich schwierigen.
    LLMs sind in der Grabungsphase nützlich, stehen aber beim Feinschliff eher im Weg.
    Für das Erstellen einfacher Websites mag das wie Magie wirken,
    aber ich glaube, dass das künftig ein Bereich sein wird, mit dem sich schwer der Lebensunterhalt verdienen lässt.

    • Gerade bei Aufgaben, bei denen Genauigkeit in neuen Szenarien wichtig ist, werden die Grenzen von KI sichtbar.
      Wenn man bei den generierten Ergebnissen innehält und genauer hinsieht, zweifelt man daran, ob sie wirklich korrekt sind.
  • Es überrascht mich, dass viele Leute KI immer noch nur als Copy-paste-Chatbot benutzen.
    Wenn man sie aber richtig anweist, kann Claude Code Experimente, die Wochen dauern würden, in wenigen Minuten reproduzieren.
    In der Praxis ist es wichtiger, schnell Ergebnisse zu liefern, als perfekten Code zu haben.
    Natürlich bleiben Sicherheitsbugs oder Fehler in der Business-Logik weiterhin Risiken.
    Wenn Domänenexperten mit dabei sind, dürften solche Probleme meiner Meinung nach nach und nach kleiner werden.

    • Wenn man aber nur auf schnelle Ergebnisse aus ist, leidet die Codequalität stark.
      Das Gleichgewicht zwischen Feature-Entwicklung und Pflege der Codebasis ist wichtig.
      Ob Agenten wie Cursor dieses Gleichgewicht gut halten, ist noch fraglich.
  • Nach dem LLM-Boom habe ich einmal an einem Projekt teilgenommen, das Excel ersetzen sollte.
    In Wirklichkeit war es aber ein Fall, in dem Nichtfachleute versucht haben, mit KI Apps zu bauen, und gescheitert sind.
    Datenanalysten hatten per „Vibe Coding“ Python-Apps gebaut,
    aber es gab kein State-Management, und die Struktur war ein einziges Chaos.
    Am Ende kam ein katastrophales Ergebnis heraus, bei dem Kundendaten völlig falsch verarbeitet wurden.
    In solchen Organisationen fehlt technisches Personal, deshalb beschleunigt KI dort eher noch das Risiko.

    • Schon die Formulierung „Excel-Modernisierungsprojekt im Post-LLM-Zeitalter“ klingt wie eine beunruhigende Vorstellung.