Code zu schreiben ist jetzt billig

• Die Realität drastisch gesunkener Kosten für das Schreiben von Code erschüttert inzwischen die gesamten Engineering-Gewohnheiten
• Früher war die Produktion von Code teuer, daher entstand eine effiziente Entwicklungskultur mit Fokus auf Design, Schätzung und Planung
• Mit dem Aufkommen von Coding-Agenten kann ein einzelner Entwickler nun mehrere Aufgaben gleichzeitig ausführen (Implementierung, Refactoring, Testen, Dokumentation)
• Doch um weiterhin „guten Code“ zu schreiben, sind nach wie vor hohe Qualitätsmaßstäbe und das Urteilsvermögen von Entwicklern erforderlich
• Damit rückt die Aufgabe in den Vordergrund, neue persönliche und organisatorische Entwicklungsgewohnheiten aufzubauen

---

Der Wandel der Kosten des Codeschreibens

• Früher dauerte es mehr als einen Tag, mehrere hundert Zeilen sauberen und getesteten Codes zu schreiben
  • Deshalb bewerteten Entwickler den Wert und die Priorität von Funktionen anhand begrenzter Zeit und Kosten
  • Projektentwurf, Aufwandsschätzung und Feature-Planung waren allesamt auf die „effiziente Nutzung der Coding-Zeit“ ausgerichtet
• Mit der Einführung von Coding-Agenten sind die Eingabekosten für Code drastisch gesunken, wodurch bisherige Maßstäbe ins Wanken geraten
  • Ein einzelner Engineer kann mehrere Agenten parallel laufen lassen und so gleichzeitige Entwicklungsarbeit an vielen Fronten leisten
  • Diese Veränderung zwingt dazu, die bisherige Bewertungslogik von Wert im Verhältnis zur Zeit neu zu prüfen

„Guter Code“ bleibt teuer

• Die Produktion neuen Codes ist fast kostenlos geworden, aber „guten Code“ zu schaffen bleibt weiterhin aufwendig
• Guter Code zeichnet sich durch Folgendes aus
  • Er funktioniert exakt und erfüllt seinen Zweck ohne Bugs
  • Er durchläuft Validierungsprozesse, die seine Zuverlässigkeit belegen
  • Er konzentriert sich auf die angemessene Lösung des Problems und behandelt Fehlersituationen vorhersehbar
  • Er bleibt einfach und minimal strukturiert, um Wartbarkeit und Verständlichkeit zu erhöhen
  • Tests und Dokumentation müssen auf dem aktuellen Stand gehalten werden
  • Er berücksichtigt künftige Änderungen, ohne unnötige Komplexität hinzuzufügen
  • Er erfüllt nichtfunktionale Qualitätsmerkmale wie Barrierefreiheit, Sicherheit, Skalierbarkeit und Wartbarkeit
• Coding-Agenten können Teile dieses Prozesses unterstützen, aber die Verantwortung für die endgültige Qualitätssicherung liegt weiterhin beim Entwickler

Die Notwendigkeit neuer Entwicklungsgewohnheiten

• In einer Umgebung des agentic engineering sind bisherige Entwicklungsgewohnheiten nicht länger ausreichend
• Sowohl Einzelpersonen als auch Organisationen müssen neue Arbeitsweisen und Beurteilungsmaßstäbe entwickeln
• Derzeit werden solche Best Practices branchenweit erst noch herausgebildet
• Der vorgeschlagene Ansatz lautet, selbst in dem Moment, in dem es sich wie „Zeitverschwendung“ anfühlt, mit asynchronen Agenten-Sessions zu experimentieren
  • Im schlimmsten Fall schaut man 10 Minuten später nach und es endet lediglich als verschwendete Tokens

Einordnung im Guide „Agentic Engineering Patterns“

• Dieser Text ist Teil von „Principles“, dem ersten Kapitel des Guides Agentic Engineering Patterns
• Im nächsten Kapitel folgt zum Thema Understanding code der Abschnitt Linear walkthroughs
• Im Abschnitt Testing and QA werden später Themen wie Red/green TDD und First run the tests behandelt
• Geplant ist, jede Woche ein bis zwei Kapitel hinzuzufügen; ähnlich wie ein Buch, aber in Form eines „Guides“ aufgebaut

[GN⁺]

Hacker-News-Kommentare

• Ich bin mir nicht sicher, ob die Formulierung „Code war schon immer teuer“ wirklich zutrifft.
  Teuer war in Wirklichkeit nicht der Code selbst, sondern alles darum herum — Korrektheit sicherstellen, Wartung, Abstimmung zwischen Teams, langfristiger Support usw. waren die eigentlichen Kostentreiber.
  Wenn man Test- oder Freigabeprozesse übertreibt, macht am Ende der Prozess selbst den Großteil der Kosten aus.
  LLMs haben kurzfristig die Kosten für die Erzeugung von funktionierendem Code stark gesenkt, langfristig könnten aber Wartungs-, Sicherheits- und Testaufwände steigen.
  Ob es also wirklich eine tiefgreifende Veränderung gibt, wird man erst mit Langzeitdaten sehen.

  • Ich stimme der Aussage zu, dass „alles rund um den Code“ teuer ist.
    Früher war selbst das Schreiben von ein paar hundert Zeilen Code kostspielig.
    Ich habe 256 Zeilen JavaScript in das SLOCount-Tool aus den 2000ern (WebAssembly-Version) geworfen, und es kam auf eine damalige Kostenschätzung von etwa 6.461 $.
    Natürlich sollte man diese Zahl eher als Spaß verstehen.
  • Meiner Erfahrung nach wurden nicht nur das Coding, sondern auch DevOps, Datenanalyse und Support-Aufgaben in allen Bereichen durch AI verstärkt.
    Im Moment arbeite ich weniger selbst, sondern bin eher der eigene Manager meiner Arbeit.
    Gefühlt ist meine Produktivität ungefähr auf das 2,5-Fache gestiegen.
  • Wenn man sich den Software Development Lifecycle (SDLC) ansieht, ist Coding nur ein Schritt.
    Anforderungserhebung, Design, Test, Deployment und Wartung bleiben weiterhin nötig, und der Großteil der Kosten entsteht in der Wartungsphase.
    Wie bei Amdahls Gesetz gilt: Selbst wenn die Coding-Kosten gegen null gehen, werden die Kosten der anderen Phasen zum Limit.
  • Die eigentliche Kostensenkung entsteht dadurch, dass man genau weiß, was die Nutzer wirklich wollen.
    Das Problem ist nur, dass das der menschlichen Natur nach schwer ist.
  • Code war früher teuer, ist heute teuer und wird auch künftig teuer bleiben.
    Qualitätsfaktoren wie Korrektheit, Wartbarkeit und Performance sind versteckte Kosten, die man nur durch Erfahrung wirklich versteht.

• Ich stimme der Behauptung „Code war schon immer teuer“ nicht zu.
  Eigentlich war Code teuer, weil wir versucht haben, ‚guten Code‘ zu schreiben.
  Wenn man die Maßstäbe senkt, ist generierter Code schnell und billig, aber der Aufwand, ihn wieder in guten Code zu verwandeln, bleibt derselbe.
  Wer agentisches Coding verteidigen will, muss mit einer anderen Logik argumentieren.

  • Nach meiner Erfahrung ist es mit AI-Agenten sogar schwieriger, guten Code sicherzustellen.
    Wenn ich selbst schreibe, verstehe ich den Grund für jede Zeile, aber bei AI-generiertem Code muss ich jede Syntaxkonstruktion verifizieren.
    Im letzten Monat habe ich den Großteil meiner Arbeit mit Agenten gemacht, und dabei tauchten ständig Edge-Case-Bugs auf, die ein Mensch so nicht gebaut hätte.
    Am Ende ist der Review-Aufwand so groß, dass der kurzfristige Gewinn verschwindet.
  • Ich habe bewusst vorsichtig formuliert: „Guter Code kostet weiterhin.“
    Allerdings sinken diese Kosten dank Coding-Agenten deutlich.
    Feine Anpassungen übernimmt der Agent, sodass man schneller Code mit besserer Qualität liefern kann.
  • Einfacher Code ist billig, aber komplexer Code bleibt teuer.
    Komplexität akkumuliert sich, daher ist es am günstigsten, sie schon beim ersten Schreiben sorgfältig zu behandeln.
    Im Moment ist der kurzfristige Nutzen groß, aber langfristig könnte das Rauschen um das Zehnfache steigen.
  • Der Kern ist die Aussage: Programmieren ist billig, Software Engineering ist teuer.
  • Mich erinnert das an Ousterhouts Konzept von taktischem vs. strategischem Programmieren.
    LLMs sind auf taktisches Programmieren spezialisiert, also auf die schnelle Umsetzung von Features.
    Deshalb wird das Management von Komplexität auf Systemebene noch wichtiger.

• Code-Erzeugung ist so billig wie Reden darüber, aber die Fähigkeit, daraus wertvolle Ergebnisse zu machen, ist die eigentliche Kompetenz.
  Agentic engineering ist letztlich die Kunst, billigen Input in wertvollen Output zu verwandeln.

  • Ich stimme der Formulierung „die Kunst, billigen Input in wertvolle Ergebnisse zu führen“ vollkommen zu.
    Agentic engineering ist nicht einfach nur das Schreiben von Software, sondern das Bauen von Werkzeugen, die ein konkretes Problem schnell lösen.
    Wenn das Problem aber gelöst ist, ist AI an sich nicht mehr interessant.
    Viele machen AI selbst zum Ziel, aber der eigentliche Wert liegt in der Problemlösung.
    Wie Alan Watts sagte: Wenn man die Botschaft erhalten hat, sollte man auflegen.
  • Nur weil es einen Bagger gibt, wird man nicht reich, indem man überall Löcher gräbt.
    Dass ein Werkzeug billiger geworden ist, erzeugt nicht automatisch Wert.
  • Das eigentliche Tippen von Code ist in Wirklichkeit nicht der Wert.
    Design- und Strukturierungsfähigkeit sind der wahre Wert.
  • Wenn der Output aus demselben Kopf stammt, ist die Qualität ähnlich, egal ob man sehr detailliert anweist oder ob zufällig alles auf Anhieb klappt.
    Am Ende ist die Qualität der Entscheidungen entscheidend.
  • Nur weil jemand 100 Millionen Dollar eingesammelt hat, heißt das noch lange nicht, dass die Idee gut ist.
    Finanzierung ist kein Beweis für Wert.

• Ich habe Zweifel an der Behauptung „Code war schon immer teuer“.
  Schon die Definition von sauberem, getestetem Code ist unscharf.
  Wenn man Tests übertreibt, explodieren die Kosten, und auch organisatorische Freigabeprozesse sind ein großer Kostenfaktor.
  LLMs senken kurzfristige Kosten, könnten aber die langfristigen Wartungskosten erhöhen.

  • Code war schon immer teuer.
    Als ich als Praktikant in einem Startup billig gearbeitet habe, haben sich Ausfälle, Datenkorruption und technische Schulden angesammelt.
    Oberflächlich sah es billig aus, aber die versteckten Kosten waren hoch.
    Dank LLMs scheint man heute guten Code billig bekommen zu können, aber ich bin noch dabei, mich daran anzupassen.
  • Aus Sicht eines Startups musste man früher mehr als sechs Monate lang Entwickler beschäftigen, um überhaupt ein Produkt auf den Markt zu bringen.
    Heute ist es billig, eine v1 zu bauen, aber die komplexen Entscheidungen eines reifen Produkts bleiben teuer.

• Der wirtschaftliche Wert von Software steckt in der Information, die im Code enthalten ist.
  Das Schreiben von Code ist nur der Prozess, diese Information abzubilden; die Qualität der Information bestimmt den eigentlichen Wert.
  Wenn man Code schneller schreibt, wird die Qualität der Information nicht automatisch besser.
  Das ist wie im Consulting: Nur weil man Folien schneller erstellt, entsteht dadurch noch kein Wert.

  • Dieses Konzept berührt sich mit dem jüngsten Schlagwort cognitive debt.
    Wenn die Implementierung zu schnell wird, driftet das mentale Modell der Entwickler vom Code weg.
    Verwandter Artikel: Cognitive Debt by Simon Willison
  • Ich habe beim Einsatz von Coding-Agenten auch erlebt, dass die Qualität des Mappings zwischen Information und Code sogar besser wurde.
    Der Grund war, dass ich Refactorings schnell iterieren konnte.
  • Am Ende ist der Flaschenhals der Prozess, Absicht an die Maschine zu übermitteln.
    AI wird den Kontext zunehmend besser verstehen, aber dafür muss man entsprechend mehr menschliches Urteil aufgeben.
    Wenn Maschinen eines Tages die Absicht vollständig erfassen, wird der Mensch aus dem Loop gedrängt.

• Der Kern jeder Entwicklungsmethodik ist die Tatsache, dass sich Anforderungen immer ändern.
  Deshalb ist guter Code „Code, den man leicht ändern kann“.
  Ob heutige LLM-Agenten solchen Code erzeugen, ist fraglich.
  Bis man ihnen vollständig vertrauen kann, werden sie wohl auf Prototyp-Niveau bleiben.

  • Der eigentliche Flaschenhals ist nicht das Schreiben von Code, sondern die Kosten, Absicht klar zu vermitteln.
    Wenn die Spezifikation unklar ist, werden sowohl Tests als auch die Validierung des Werts schwierig.
  • Auch menschliche Engineers ändern Dinge nicht zu 100 % sicher.
    Selbst mit Tests hat man nur etwa 70 % Sicherheit.
  • Ich steuere LLMs sehr fein und lasse sie oft Features ändern oder Bugs beheben.
    Das ist schneller als selbst zu coden, und das Ergebnis ist wartbarer Code.
  • Bei mir werden inzwischen alle Commits zu 100 % vom Agenten erzeugt.
    Wenn man sauberen Code und gute Praktiken explizit vorgibt, kommen ausreichend wartbare Ergebnisse heraus.
    Letztlich gilt Garbage in, garbage out.
  • Manche haben allerdings das Gefühl, dass LLMs für Demos gut sind, aber schon bei kleinen Änderungen auseinanderfallen.

• Wie ich in meinem Artikel (The Final Bottleneck) geschrieben habe,
  ist das Schreiben von Code zwar schneller geworden, aber die nachgelagerten Schritte kommen nicht hinterher.
  Es geht nicht nur um Gewohnheiten; Verantwortungsstrukturen, Sprachdesign und die gesamte Systemarchitektur müssen sich ändern.

  • Es ist für Unternehmen nicht leicht, komplett auf neue Arbeitsweisen umzuschalten.
    Wenn die Produktivität wirklich um das Zehnfache gestiegen wäre, hätten Startups den Markt längst aufgerollt.
  • Wenn LLMs klein und billig genug werden, kommt vielleicht eine Zeit, in der sie direkt in Apps eingebettet sind und den Code für jeden Nutzer individuell anpassen.
  • Es gibt auch die Frage: Warum muss man überhaupt so schnell Code schreiben?
    Nur weil etwas möglich ist, heißt das nicht, dass man es auch tun sollte.
  • Open-Source-Entwickler sollten eine Zeit anführen, in der auch Nicht-Entwickler zu Buildern werden.
    Ansätze wie AI evals(measure-first-optimize-last, ai-evals.io) weisen in diese Richtung.
  • „Muss man in diesem Tempo überhaupt weiter deployen?“
    Feature-Raserei will am Ende niemand.

• Jede einzelne Codezeile ist eine Verbindlichkeit (liability).
  In einer Zeit, in der LLMs Unmengen an Code ausspucken, explodiert diese Verbindlichkeit.
  Die Werkzeuge selbst sind nicht schlecht, aber eine Struktur, in der verantwortungslose Programme die Codebasis umschreiben, ist riskant.

  • Wir haben über Jahrzehnte Validierungs-, Review- und Rollback-Systeme für das Deployment von Code aufgebaut.
    „Code ist billig“ bedeutet nur, dass die Erzeugung billiger wurde; die Kosten der Freigabe für Deployment sind weiterhin hoch.
    Wenn man die Urteilsinstanz überspringt, gewinnt man nicht Produktivität, sondern erzeugt eine Kontrolllücke (control gap).
    Nur weil etwas schnell ist, sollte man ihm keinen Generalschlüssel geben.
  • Sowohl das Schreiben als auch die Wartung bleiben teuer.
    Billig ist keines von beidem.

• Ich stimme dieser Ansicht fast vollständig zu.
  Das Schreiben von Code ist billiger geworden, aber die Kosten für Review und Validierung bleiben hoch.
  Gerade in Monorepos mit Millionen Zeilen Code ist es entscheidend, die Testbarkeit zu erhöhen.
  Ich bin dankbar, dass solche Diskussionen in der überhitzten Twitter-Stimmung etwas Ausgleich schaffen.

  • Ich beobachte dasselbe.
    Code churn ist leichter geworden, aber Qualitätssicherung wird zur neuen Herausforderung.
    Die massenhaften Änderungen aus LLMs führen zu subtilen Fehlern, und dieser Strom reißt nicht ab.

• Code ist nicht billig.
  Es gibt auch Token-Kosten, und die tatsächliche Kostenstruktur ist noch unsicher.
  Da Startups ohne Erlöse derzeit die GPU-Lieferkette dominieren, fehlen belastbare Daten.

  • Das Schreiben ist billiger geworden, die Wartung aber nicht.
    Je mehr LOC, desto mehr Schulden.
    Der Weg vom Gedanken zur Ausführung ist kürzer geworden, aber Code selbst bleibt weiterhin eine Verbindlichkeit.
  • Lokale Modelle zeigen die Untergrenze der Kosten.
    Im Moment ist alles durch Subventionen billig, aber wenn Hardware-, Strom- und Personalkosten sinken, könnte es noch billiger werden.