Der Engpass war nie der Code

• Codex erstellte bei .txt in wenigen Stunden die erste funktionierende Version eines seit über einem Jahr aufgeschobenen Experiments zu Structured-Generation-Algorithmen, doch die eigentliche Veränderung liegt weniger in der individuellen Coding-Geschwindigkeit als darin, dass Kollaborationsengpässe sichtbar wurden
• Wenn Agenten die Implementierung übernehmen, wird nicht mehr der Code-Autor zum bremsenden Faktor, sondern die Erstellung präziser Spezifikationen, die Agenten direkt ausführen können — etwa bei Roadmaps, Akzeptanzkriterien und Design-Dokumenten
• Wenn das Schreiben von Code billiger wird, entstehen mehr Prototypen und interne Tools, die zuvor nicht gebaut worden wären; da die Geschwindigkeit, mit der Nutzer Dinge aufnehmen können, gleich bleibt, wird die Disziplin des Fokus darauf, was man nicht bauen sollte, noch wichtiger
• Agenten können aus Slack, PRs, Issues, Commits und Design-Dokumenten implizite Entscheidungen und Konventionen extrahieren und daraus eine Wissensbasis aufbauen, aber sie können den von Menschen direkt aufgebauten gemeinsamen Kontext nicht vollständig rekonstruieren
• Der Vorteil der nächsten zehn Jahre könnte weniger bei den besten Modellen liegen als bei Unternehmen, die auch bei 50, 200 oder 2.000 Personen organisatorische Konsistenz bewahren und auf eine kleiner werdende Menge an Entscheidungen ausgerichtet bleiben

---

Der von Coding-Agenten veränderte Engpass

• Das bei .txt seit über einem Jahr aufgeschobene Experiment bestand darin, Structured-Generation-Algorithmen und Open-Source-Alternativen zu testen und dabei nicht nur zu prüfen, „akzeptiert dies diesen String?“, sondern eher Fragen in der Art von „erzeugt es die korrekte Token-Verteilung?“ zu beantworten
• Dieses Experiment blieb immer wieder auf der Roadmap stehen, doch nachdem der Ansatz Codex etwa 30 Minuten lang erklärt worden war, entstand innerhalb weniger Stunden eine erste funktionierende Version
• Coding-Agenten verändern bereits stark, wie Einzelne Code schreiben, doch es ist nicht selbstverständlich, dass eine Steigerung der individuellen Produktivität unmittelbar zu einem höheren Tempo der gesamten Softwareindustrie führt
• Einflussreiche Software entsteht oft durch die Zusammenarbeit vieler Menschen, und die interessantere Analyseeinheit ist daher nicht die individuelle Produktivität, sondern die Zusammenarbeit
• Software ist eher das Resultat dessen, was übrig bleibt, nachdem Menschen ausgehandelt haben, was ein System tun soll; Code ist wichtig, aber zugleich das Nebenprodukt der schwierigeren Arbeit

Die Roadmap wird zur Grenze

• In Teams, in denen Agenten die Implementierung übernehmen, verlangsamt vor allem die Aufgabe, Spezifikationen so präzise zu formulieren, dass Agenten sie direkt aufnehmen und ausführen können
• Roadmaps, Akzeptanzkriterien und „was wir eigentlich wollen“ müssen klar niedergeschrieben werden — etwa als Test-Suites, Tickets oder Design-Dokumente
• Features werden sehr schnell implementiert, und statt dass ein Engineer auf einen anderen warten muss, wartet man darauf, dass als Nächstes eine korrekt geschriebene Spezifikation kommt
• Der Engpass verlagert sich von der Person, die Code schreibt, zu der Person, die entscheidet, welcher Code überhaupt existieren soll — und damit zu einer Frage des Managements

Billigerer Code verlangt mehr Einigung

• Wenn das Schreiben von Code günstiger wird, bedeutet das nicht nur, dass man mit 10 % des Aufwands zum gleichen Ergebnis kommt, sondern dass man den gleichen Aufwand auf Ergebnisse verwendet, die früher nicht lohnend gewesen wären
• Prototypen, die vor drei Monaten noch als „Zeitverschwendung“ gegolten hätten, entstehen an einem einzigen Nachmittag; interne Tools ohne klar erkennbare Nachfrage werden gebaut und dann wieder vergessen
• Das Tempo, in dem Nutzer Features aufnehmen können, bleibt weitgehend gleich — egal, ob ein Team 10 oder 50 Dinge ausliefert
• Wie Steve Jobs 1997 sagte: „Fokus heißt, Nein zu sagen“, und Apple strich in jenem Jahr rund 70 % seiner Produktlinie
• Weil es mit Agenten leichter wirkt, neue Features auszurollen, wird die Disziplin schwieriger, nicht nur zu entscheiden, was man baut, sondern auch, was man nicht baut

Kontext wird zur zentralen Ressource

• Verhandlung und Einigung beruhen innerhalb einer Organisation auf gemeinsamem Kontext
• Kontext umfasst, was gebaut wird, warum es wichtig ist, was bereits versucht wurde, wer was entschieden hat und was zentral ist und was nur eine Spur aus der Vergangenheit darstellt
• Die Menschen im Team bauen diesen Kontext ganz natürlich auf, indem sie im selben Raum sitzen, dieselben Slack-Kanäle lesen und denselben Ausfall um 2 Uhr morgens debuggen
• Der Großteil dieses Kontexts wird nie dokumentiert; wenn ein Senior Engineer in einem PR-Review sagt: „Das wird die Migration kaputtmachen“, greift er oft auf undokumentierten Kontext zurück
• Agenten können eine solche Osmose nicht leisten; sie gewinnen keinen Kontext dadurch, dass sie im Raum sind, Planungsgespräche halb mitbekommen oder Erinnerungen an vergangene Ausfälle haben
• Kontext, der nicht in Prompts, Dateibäumen, Tools oder expliziten Anweisungen steckt, steht Agenten nicht zuverlässig zur Verfügung
• Ohne Kontext können Agenten auf eine leicht falsche Frage eine plausibel klingende Antwort erzeugen
• Auch wenn Agenten bei .txt nützliche Arbeit geleistet haben, war die eigentliche Kontextarbeit bereits von Menschen erledigt worden, und die nächsten zehn Engineers besitzen dieses Gesamtbild nicht automatisch
• Der Kontext, auf den Organisationen schon immer implizit angewiesen waren, ist nun zu einem geschwindigkeitsbegrenzenden Input geworden, während Menschen dazu neigen, ihn implizit zu hinterlassen, weil es bisher keine explizite Form gab, die jemand lesen sollte

Die Schleife, in der Agenten Kontext produzieren

• Kontext in einer Form zu erzeugen, die Menschen leicht konsumieren können, ist keine Aufgabe, die Menschen gern erledigen
• Agenten sind stark darin, PR-Kommentare, geschlossene Issues, Commit-Messages, alte Design-Dokumente und Slack-Archive lückenlos zu lesen und daraus Muster zu extrahieren, die nie jemand dokumentiert hat
• Bei .txt wurde begonnen, Agenten zu bauen, die Codebase, Issues, PRs und Threads crawlen und daraus implizite Entscheidungen, Konventionen und das „warum wir es so gemacht haben“ in eine Wissensbasis überführen
• Diese Wissensbasis enthält nicht nur Aussagen wie „dieses Modul existiert“, sondern auch Kontext wie „dieses Modul ist ungewöhnlich, weil die Migration das bestehende Verhalten bewahren muss“ oder „dieser Benchmark ist wichtig, weil eine frühere Optimierung die Verteilung unbemerkt verändert hat“
• Andere Agenten nutzen diese Wissensbasis, wenn sie innerhalb der Codebase handeln müssen
• Die Osmose, die Menschen bisher informell geleistet haben, wird in eine Form externalisiert, die sowohl Agenten als auch Menschen lesen können
• Agenten, die Kontext konsumieren, brauchen Agenten, die Kontext produzieren; wenn diese Schleife funktioniert, erhält die Organisation eine dokumentierte Grundlage, die sie von sich aus nie geschaffen hätte
• Dennoch erzeugt diese Schleife immer nur ein Teilbild
• Wie Michael Polanyi sagte: „Wir wissen mehr, als wir sagen können“; ein Teil des entscheidenden Kontexts existiert gerade deshalb, weil er nie aufgeschrieben wurde, und kann sich in dem Moment verändern, in dem er verschriftlicht wird
• Die durch direkte menschliche Begegnung entstehende Osmose-Schicht lässt sich nicht vollständig allein aus dokumentierten Nebenprodukten rekonstruieren
• Das Ergebnis ist eher ein nützlicher Ausgangspunkt als eine vollständige Wiederherstellung, und ob das für kumulative Effekte ausreicht, bleibt vorerst eine experimentelle Frage

Der neue Burggraben liegt eher in der Organisation als in der Technik

• Die Gewinner der nächsten zehn Jahre werden womöglich nicht die Unternehmen mit den besten Modellen oder der besten Agenten-Infrastruktur sein, sondern jene, die auch beim Wachstum auf 50, 200 oder 2.000 Personen pro Kopf mehr Output erzielen und dabei auf eine kleiner werdende Menge an Entscheidungen ausgerichtet bleiben
• Solche Unternehmen sind Organisationen, die schon vor dem Aufkommen von Agenten verstanden haben, dass das schwierigste Problem Konsistenz ist
• Das ist eine Frage von Kultur und Management — und war es immer
• Werkzeuge früherer Generationen wie IDEs, Versionsverwaltung, CI, Microservices und DevOps versprachen, Koordination durch bessere Tools zu lösen, verstärkten in der Praxis aber meist nur die bereits vorhandene organisatorische Konsistenz
• Kleine Teams bekommen Konsistenz fast kostenlos, deshalb ist dieser Verstärkungseffekt dort meist positiv; auch deshalb kommen viele besonders starke Pro-Agenten-Stimmen aus kleinen Teams, weil es in ihrem Kontext oft tatsächlich stimmt
• Jenseits einer bestimmten Größe muss Konsistenz aktiv geschaffen und erhalten werden, und der Verstärkungseffekt wird in beide Richtungen schärfer
• Gute Organisationen werden besser, schlechte Organisationen zerfallen schneller
• Agenten sind ein weit stärkerer Verstärker als frühere Werkzeuge; sie werden als Mittel überschätzt, damit Einzelne schneller Code schreiben, und unterschätzt als Mittel, das Wissen einer Organisation zu externalisieren

Agenten als Erweiterung der Unternehmenskultur

• Agenten können sich wie eine Erweiterung des eigenen Denkens anfühlen, und dieses Gefühl ist mächtig
• Die schwierigere Aufgabe besteht darin, Agenten zu einer Erweiterung der Unternehmenskultur zu machen
• Dafür braucht es eine Schreibkultur, ein reflektiertes Management, das erkennt, wo es selbst noch der Kontext-Engpass ist, und Menschen, die Konsistenz als reales Artefakt behandeln, das erhalten werden muss
• Neu ist, dass sich ein Teil davon nun tatsächlich bauen lässt
• Die Lese-und-Extraktionsschleife ist eine Form davon, und weitere Formen könnten entstehen

[GN⁺]

Hacker-News-Kommentare

• Es wirkt lächerlich, wie Ingenieure, die sich während ihrer gesamten Karriere über alles beschwert haben, was ihre stundenlangen Coding-Flow-Zustände gestört hat — Team-Meetings, Agile-Rituale, Issue-Tracker, Backlogs, Slack, E-Mails, Design-Reviews, all das, was sie als essenzielle und fast heilige Aktivitäten verteidigt sehen wollten — jetzt, da Maschinen Code schneller schreiben als sie selbst, plötzlich völlig schamlos über die Bedeutung von Zusammenarbeit und die Geringfügigkeit von Code und Codieren predigen
  Falsch ist das nicht, aber die unverhohlene Heuchelei der Leute, die noch vor einem Jahr in praktisch jedem Team am unsozialsten waren und am wenigsten kooperiert haben, überrascht mich trotzdem

  • Sprichst du von bestimmten Autoren oder Leuten, die du kennst? Falls das eine Verallgemeinerung über eine gesamte Online-Gruppe sein soll, könnte es sein, dass du dem Group Attribution Error aufsitzt, also individuelle Eigenschaften auf die ganze Gruppe überträgst
    Unabhängig davon können zwei Dinge gleichzeitig wahr sein: Dass das Schreiben von Code nicht der Flaschenhals ist und man Features schneller entwickeln kann, als man sie ausrollen kann, und dass Unterbrechungen bei Arbeit, die tiefe Konzentration erfordert, nervig sind und den Flow unterbrechen
    https://en.wikipedia.org/wiki/Group_attribution_error
  • Das ist eine falsche Dichotomie. Softwareentwicklung bestand schon immer darin, vom Kunden bis zum Coder — und allen dazwischen — ein gemeinsames Verständnis aufrechtzuerhalten, und je weniger Leute dazwischenstehen, desto besser
    Meetings, die die Synchronisierung zwischen Kunden und Codern verbessern, sind selten und wertvoll. In großen Organisationen vermehren sich ritualisierte Meetings aus den falschen Gründen. Leute versuchen, sich in den Prozess zwischen Kunde und Coder hineinzuschieben, um ihre Existenz zu rechtfertigen
    Ich persönlich mag Meetings mit Kunden, Endnutzern, UX-Designern und echten Stakeholdern. Meetings mit politisch motivierten Busywork-Leuten, die für ihren Einfluss im Unternehmen Bandbreite fressen, hasse ich. Ich brauche keinen weiteren mittleren Manager zwischen mir und meinen Nutzern
  • Warum ist das Heuchelei? Wenn in der alten Welt das eigentliche Schreiben von Code ein sehr wichtiger Teil des Prozesses war, viel Zeit gekostet hat und stark davon profitierte, nicht unterbrochen zu werden, dann fühlten sich all die Rituale mit begrenztem Wert, die nur dazu dienten, Statusberichte nach oben zu liefern, wie Zeitverschwendung an
    In der neuen Welt dagegen, in der das Schreiben von Code sehr schnell geworden ist und der schwierige Teil darin besteht, die geschäftlichen und technischen Anforderungen zu verstehen, kann dieselbe Person diesen Ritualen mehr Priorität geben und Unterbrechungen tolerieren, während ein AI-Agent den Code schreibt
    Es ist keine Heuchelei, seine Meinung zu ändern, wenn sich die Tatsachenlage verändert hat
  • Rituale und Tickets sind nicht besonders effektiv für echte Zusammenarbeit. Sie sind vor allem Werkzeuge, um Arbeit für das Management lesbar und kontrollierbar zu machen
    Wenn man außerhalb einer Firma mit jemandem an einem kreativen Projekt arbeitet, denkt man aus gutem Grund nicht zuerst an Scrum-Rituale oder Jira. Zusammenarbeit wichtig zu finden und diese Dinge trotzdem zu kritisieren, ist vollkommen konsistent
  • Das ist zu 100 % Verdrängung und Stolz. Ich arbeite schon lange unfreiwillig als Contractor, und jedes Mal, wenn ich zu einem neuen Team dazustoße, sehe ich dieselbe Reaktion
    Das Team beschwert sich, es habe so viel Arbeit, dass es nichts mehr schafft, also setzt der Manager mich ein. Und plötzlich will niemand mehr etwas abgeben. Genau da stecke ich gerade wieder mittendrin
    Das Team sagt, es sei „komplett ausgelastet“, hat aber gleichzeitig die Kapazität zu behaupten, dass bei fast allem, was ich übernehmen könnte, sie selbst die beste Besetzung seien und keine Hilfe bräuchten. Für mich ist das okay, ich kann auch rumsitzen und bezahlt werden. Aber es riecht immer gleich
    A: Sie wollen nicht anerkennen, dass sie ersetzbar sind und ihre Arbeit nicht so einzigartig ist, und B: dass der Flaschenhals nicht der Prozess oder die Arbeitsmenge ist, sondern sie selbst

• Veteranen unter den Ingenieuren scheinen schon immer gewusst zu haben, dass die eigentliche Ursache von Geschwindigkeitsproblemen eher in der Organisation als in der Technik liegt
  Dass das Business keine fokussierte, produktive Roadmap definieren kann, ist seit Langem ein Problem im Software Engineering. Das ständige Springen auf das nächste glänzende Objekt mit kaum ROI, während systemische technische Schulden nicht angegangen werden dürfen, hat mehrere Unternehmen, in denen ich gearbeitet habe, langfristig kaputtgemacht

  • Für Veteranen mag das stimmen, aber für Junior Engineers vor AI war Geschwindigkeit immer ein technisches Problem
    Ich kenne Junior Engineers, die ein ganzes Jahr lang C++ schreiben und trotzdem std::unique_ptr nicht verstehen; solche Leute sind im Team immer die langsamsten
    Früher, wenn ich Leistungsbeurteilungen für Junior Engineers geschrieben habe, hing die Performance tatsächlich stark von Geschwindigkeit ab und wurde grob daran gemessen, wie viele fehlerfreie Codezeilen sie in einem bestimmten Zeitraum produzierten. Gute Juniors bekamen klar definierte Features und schrieben schnell guten Code; schwächere bekamen dieselbe Aufgabe und schrieben entweder langsam oder schnell, aber voller Bugs, was viel mehr Arbeit für Debugging und Neuimplementierung erzeugte
  • Ich stimme zu, dass das Problem oft darin liegt, dass das Business keine fokussierte, produktive Roadmap definieren kann, und auch darin, dass die meisten Entwickler das mit Zeit und Erfahrung erkennen
    Wenn man die Business-Begründung, den Scope, die Inputs und den gewünschten Output klar versteht, ergeben sich Datenmodell, Systemdesign und Code fast von selbst oder sind zumindest viel klarer
  • „Organisationen, die Systeme im weiten Sinne entwerfen, sind gezwungen, Designs hervorzubringen, die die Kommunikationsstrukturen dieser Organisationen kopieren.“
    — Melvin E. Conway, 1967
  • Auf systemische technische Schulden kann man jetzt mit LLMs in großem Maßstab reagieren. Künftige Modelle werden gut genug sein, um das dauerhaft zu tragen; und wer das nicht glaubt, sollte erklären, warum nicht
    Man sollte sich zuerst fragen, ob man versteht, was Skalierungsgesetze wie Chinchilla sind und wie Reinforcement Learning mit Verifikation im Kern funktioniert
    Ich stimme völlig zu, dass die grundlegende Grenze darin liegt, ob ein Business sich selbst und seine Strategie konsistent ausdrücken kann
    Aber der Vorteil jetzt ist, dass man Prototypen praktisch kostenlos bauen kann. Früher musste man extrem vorsichtig sein, bevor man Engineering-Kapazität investiert; heute kann man unter denselben Zeitbeschränkungen sehr viel mehr ausprobieren
  • Ein kompetenter Engineer sollte verstehen, dass Engineering eher die Montagelinie der Produktentwicklung ist
    Welche Features und Bugfixes wann ausgeliefert werden sollen und wie das Produkt insgesamt entwickelt und gemanagt werden soll, war immer die eigentliche Herausforderung, und ein großer Teil dieser Strategie hängt von Feedback-Loops ab, die AI nicht schnell erzeugen kann
    Gleichzeitig habe ich auch den Eindruck, dass Führungskräfte auf der Business-Seite die Geschwindigkeit der Engineers oft zum Sündenbock machen, statt Verantwortung für schlechte Entscheidungen auf ihrer Seite zu übernehmen

• Meistens ist der Flaschenhals tatsächlich Code, aber nicht das Schreiben von Code, sondern der Code selbst. In meiner Karriere gab es unzählige Verzögerungen wegen langsamer Anwendungen
  Ich musste Editoren auf Eclipse-Basis verwenden, die langsam waren und regelmäßig hingen oder abstürzten. Build-Jobs dauerten 15 bis 20 Minuten. Und ich habe oft Web-Apps erlebt, die für Aufgaben, die höchstens 50 ms dauern sollten, praktisch ewig brauchten
  Diese Liste ließe sich endlos fortsetzen. Jede Verzögerung ist eine Unterbrechung, die meine Konzentration zerschlägt. Heute bin ich im Management und habe mit Dutzenden Menschen und administrativen Störungen zu tun, schreibe aber immer noch Code im Unternehmen
  Wenn Software langsam ist, wird sie für mich zur absoluten Niedrigstpriorität. Mir ist egal, wen das betrifft. Wenn es wirklich wichtig wäre, wären wir nicht alle Geiseln dieses zähen Sirups aus langsamer Software, der uns herunterzieht

  • Welcher Editor, und warum Eclipse?

• Code ist Schuld
  Man kann Code leicht als Vermögenswert betrachten, aber im Kern ist er Schuld. Einige der „Flaschenhälse“ auf dem Weg zu neuem Code existieren, um sicherzustellen, dass der Output größer ist als die dadurch anwachsende Schuld. Agenten, die schneller mehr Code erzeugen, erzeugen auch schneller mehr Schuld
  Ein großer Teil der Begeisterung und Skepsis rund um Coding-Agenten dreht sich darum, ob die sofortige Produktivitätssteigerung — also unmittelbarer Output wie neue Features, neue Produkte und neuer Umsatz — den Anstieg langfristiger Schuld aufwiegt. Die Antwort werden wir wohl erst in 1 bis 3 Jahren kennen, und sie wird je nach Bereich unterschiedlich ausfallen
  Aus dieser Sicht ergibt es durchaus Sinn, solche Flaschenhälse direkt in agentische Workflows einzubauen. Es ist wertvoll, einem Coding-Agenten zusätzlichen Kontext zu geben, der eine kohärente Projektvision betont und sich gegen neue Features oder einen ungebremsten Prozess stellen kann
  Ist das die eigentliche Aussage des Artikels? Dass manche Agenten Produktmanagement-Verantwortung übernehmen sollen, möglichst viel zu einer kohärenten Produktvision verdichten und diese Vision den Coding-Agenten so strikt wie möglich in Erinnerung rufen?
  Sollten solche Agenten neue Vorschläge und neue Pull Requests unter dem Gesichtspunkt der „Übereinstimmung mit dem Gesamtbild“ prüfen? Nenn es Kontext, Vision oder anders
  Solche Agenten könnten sehr gut darin sein, Kontext zu synthetisieren und kohärente Roadmaps zu formulieren, die sprachlich zu den Werten und der Vision eines Teams passen. Aber ich bin skeptisch, ob sie das Urteilsvermögen eines guten Managers oder Teams haben können. Dass eine bestimmte Roadmap schnell und überzeugend abgesegnet wird, könnte mehr schaden als nützen

  • „Code ist Schuld“ ist zu stark vereinfacht. Code an sich ist weder Vermögenswert noch Schuld
    Der minimale Code, der nötig ist, um Geschäftsanforderungen ohne zusätzliche Komplexität zu erfüllen, ist ein Vermögenswert mit Wartungsschuld. So wie der Traktor eines Bauern ein Vermögenswert ist, der gewartet werden muss und bei Vernachlässigung durch Bitrot an Wert verliert
    Code, der unnötige Komplexität schafft, ist reine Schuld

• Stimmt, aber das Schreiben von Code lehrt einen immer etwas
  Ich habe sowohl in Gründer-Startups als auch in börsennotierten Unternehmen mit Hunderten Milliarden Dollar Marktkapitalisierung gearbeitet, und ich habe noch nie eine Produktspezifikation, ein Pitch Deck oder ein PRD gesehen, das tatsächlich eine Lösung beschrieben hätte, die das Problem durch bloße Umsetzung der Spezifikation gelöst hätte. Erst wenn man es wirklich baut, lernt man, wie es funktionieren muss
  Software ist ein komplexes, interaktives Medium. Mit Leuten im Code zu iterieren, die das Problem verstehen und lösen wollen, war immer die einzige Art, auf der wertvolle Produkte entstehen. Meetings und Diagramme helfen, aber bevor man funktionierende Software schreibt, weiß man nicht, ob man überhaupt etwas in der Hand hat

• „Das Ziel war, unsere Algorithmen zur strukturierten Generierung und ihre Open-Source-Gegenstücke zu testen und das naive ‚Akzeptiert es diesen String?‘ durch die realitätsnähere Frage zu ersetzen: Erzeugt es die korrekte Token-Verteilung? … Letzten Monat habe ich Codex 30 Minuten lang erklärt, wie es geht. Ein paar Stunden später gab es eine funktionierende erste Version. Das war alles.“
  Das beweist, dass der Flaschenhals tatsächlich der Code war. Jetzt hat nur eben AI diesen Code geschrieben
  Wer denkt, „der Flaschenhals war nicht der Code“, hatte Ziele bereits besprochen und im Kopf kohärent geordnet
  Dass Code der Flaschenhals ist, muss nicht unbedingt heißen: „Ich wollte dieses Feature, aber das Codieren hätte Monate gedauert.“ Es kann auch heißen: „Ich wollte dieses Feature seit zwei Jahren, habe es aber aufgeschoben, weil die Reibung, mich hinzusetzen, es in Code zu übersetzen und 5 bis 10 Tage zu investieren, zu hoch war.“
  Wenn Code nicht der Flaschenhals gewesen wäre, hätte die Person sich einfach hingesetzt und es selbst geschrieben. Aber sie wollte den Aufwand und die Zeit für das manuelle Codieren nicht investieren und wusste, dass es nicht annähernd so wenig Aufwand wäre wie mit einem LLM
  Auch wenn die endgültige Spezifikation nicht klar ist, geht exploratives Coden, Überprüfen, Verwerfen und erneutes Probieren eines neuen Designs mit LLMs schneller. Und zwar genau deshalb, weil der „Code“-Teil schneller wird
  Anders gesagt: Der Flaschenhals war der Code
  Auch dieser Artikel selbst wirkt wie ein AI-generierter Text mit einer Anweisung, offensichtliche Formulierungen zu vermeiden, und ist deshalb trotzdem unerquicklich zu lesen

• Im Artikel hieß es: „Jevons Paradox: Wenn etwas billiger wird, nutzt man es nicht weniger, sondern mehr.“ Das ist eine kaputte Formulierung des Jevons-Paradoxons
  Dieser Satz beschreibt kein Paradox, sondern einen völlig natürlichen Effekt. Wenn etwas billiger wird, nimmt die Nutzung natürlich zu
  Das Jevons-Paradoxon beschreibt eigentlich eine Situation, in der die Nutzung einer Ressource effizienter wird und man für eine bestimmte Aufgabe weniger davon braucht, die Gesamtnutzung dieser Ressource aber trotzdem steigt

  • Warum nennt man das dann ein Paradox? Ein einfacher Grund ist, dass man jetzt weniger Ressourcen verbraucht, es dadurch billiger wird und die gegebene Aufgabe deshalb häufiger ausgeführt wird als zuvor
  • Natürlich ist es selbstverständlich, dass etwas häufiger genutzt wird, wenn es billiger wird
    Aber ist es nicht genauso selbstverständlich, dass der Preis dieser „Nutzung“ sinkt, wenn der Ressourceneinsatz effizienter wird?
    Also steigt mit der Effizienzsteigerung zwangsläufig auch die Nutzung. Dass man es ein Paradox nennt, liegt nur daran, dass manche Leute naiv glauben, Effizienzgewinne seien eine gute Methode, den Konsum zu senken
    Fast alles, was als „Paradox“ bezeichnet wird, ist auf diese Weise offensichtlich
  • Müsste das Paradox nicht eher darin liegen, dass wir am Ende mehr Geld dafür ausgeben?
    Oder dass wir, wenn ein Prozess effektiver wird und also weniger Zeit braucht, am Ende mehr Zeit auf genau diesen Prozess verwenden?

• Ein Flaschenhals wofür genau? Für mehr Features?
  Ich glaube nicht, dass die Menge an Software über den Erfolg eines Unternehmens entscheidet. Ich halte auch die Menge an erfasstem Kontext nicht für so wichtig
  Entscheidend ist die Qualität des Kontexts. Wie gut können Menschen schlussfolgern?
  Danach kommt die Haltung. Wie gut reagieren Menschen auf schlechte Situationen?
  Danach kommt das Ressourcenmanagement. Wie gut geht das Unternehmen mit Menschen und Geld um?
  Und zuletzt das Glück. Wie viele unkontrollierbare Faktoren spielen uns in die Karten?
  Das sind ziemlich gute Flaschenhälse eines Unternehmens. Ich sehe nicht, dass Agenten diese Probleme in absehbarer Zeit lösen

  • In Unternehmen sind Softwareanwendungen Werkzeuge, die helfen, „die eigentliche Arbeit“ zu erledigen, mit der Geld verdient wird. Wir in der Softwarewelt denken gern, diese Arbeit sei Software und Software-Features, aber außerhalb davon gibt es meist eine andere „Arbeit“
    Der Flaschenhals beim Verbessern von Softwareanwendungen, die von Nicht-Software-Unternehmen genutzt werden, liegt darin sicherzustellen, dass die Software all die Aufgaben übernimmt, die dem Business tatsächlich nützen
    Dinge, die Zeit sparen, Menschen produktiver machen, menschliche Fehler reduzieren, das Business effizienter machen und die Margen erhöhen
    All das ist ziemlich schwer vorherzusagen und zu quantifizieren. Man kann mit einer Idee beginnen, von der man glaubt, dass sie dem Business hilft, sie entwerfen, einen Prototyp bauen und testen. Am Ende versucht man dann zu messen, wie viel besser die Softwareanwendung das Business gemacht hat
    Während dieses gesamten Prozesses ist es schwer sicherzustellen, dass die Software die richtigen Probleme auf die richtige Weise angeht und am Ende das Business wirklich verbessert — ganz unabhängig davon, wie schnell und einfach das Erstellen von Software geworden ist
    Trotzdem kann Geschwindigkeit wirklich helfen. Man kann Prototypen bauen, testen und die Feedback-Loops verbessern
  • Nicht so sehr „mehr Features“, sondern Code-Änderungen. Also nicht nur Features, sondern auch Bugfixes, allgemeine Wartung und Refactorings, um die Testbarkeit zu verbessern
    Mit AI-Coding-Assistenten werden Dinge, die früher als Aufgaben für Junior-Entwickler galten, jetzt per schnellem Prompt und im Hintergrund laufendem Agenten umgesetzt
    Diese Junior-Entwickler-Aufgaben liefert ein Coding-Assistent inzwischen fast ohne menschliches Zutun mühelos aus. Das Backlog leert sich schneller, als neue Einträge hinzukommen. Und weil Durchsatz kein Problem mehr ist, kommen auch immer mehr neue Einträge dazu
    Die Aufgabe besteht jetzt darin, mit dem Umfang der Änderungen Schritt zu halten. Wir sehen das direkt in unserer Organisation
    Nur weil man sich andere Flaschenhälse vorstellen kann, heißt das nicht, dass Code-Generierung nicht der Flaschenhals war oder jetzt nicht ist. Schon das Konzept eines Backlogs zeigt, dass es sich um einen Flaschenhals handelt

• „Software ist das, was übrig bleibt, nachdem eine Gruppe von Menschen miteinander ausgehandelt hat, was das System tun soll.“
  Diese Formulierung gefällt mir. Vor allem bei Kontext stimme ich zu. Genau dort werden erfahrene, langfristig bestehende Teams belohnt
  Ich habe solche Teams jahrzehntelang geführt. Als unsere Abteilung schließlich konsolidiert wurde, hatte selbst der dienstjüngste Engineer bereits 10 Jahre Betriebszugehörigkeit
  Wenn ein Team so lange zusammenarbeitet, sinkt der Kommunikations-Overhead fast auf null
  Deshalb frustriert mich die heutige Kultur mit Beschäftigungsdauern wie bei Eintagsfliegen so sehr
  Heute arbeite ich meistens allein. Meine Produktivität ist sehr hoch, aber mein Wirkungskreis ist wirklich begrenzt
  Ich vermisse die Zeit, in der ich Teil eines guten Teams war

• An was für Projekten arbeitet ihr bitte, bei denen der einzige schwierige Teil darin besteht, zu verstehen, welche Features das Management will, und der Rest einfach nur noch „runtergetippt“ oder heute an ein LLM delegiert wird?
  Wenn das eure Arbeit ist, wundert es mich nicht, dass viele auf HN glauben, LLMs könnten sie ersetzen

  • Diskussionen zu diesem Thema wirken immer so, als würden alle annehmen, dass jeder Code auf dieselbe Weise und mit denselben Funktionen schreibt, und dann versucht man, den Rest der Welt gewaltsam durch diese Linse zu pressen
    Also drehen wir wieder dieselben Kreise, sprechen über unsere Ängste, reden aneinander vorbei und warten 30 Minuten auf die nächste Gelegenheit für denselben Kommentar
  • Je höher ich in meiner Karriere gekommen bin, desto austauschbarer erschien mir der Code und desto wichtiger und schwieriger wirkte der Prozess
  • Etwa 80 % aller CRUD-Apps sind so. Es gibt gelegentlich interessante Probleme, aber nichts aus den Top 20 %
    Das meiste ist wegen Offshore-Auslagerung und Entlassungszyklen in Bezug auf die Codequalität lodernder Müll
  • Spiegel zurück. Wie begrenzt muss deine Projekterfahrung sein, um zu glauben, dass es im Bereich der Softwareentwicklung kein riesiges Kontinuum zwischen Code-Schwierigkeit und Organisationsproblemen gibt?