Veränderungen im Coding-Workflow
- Im November 2024 bestand die Arbeit aus 80 % manuell+Autovervollständigung und 20 % Agenten-Coding, im Dezember kehrte sich dieses Verhältnis um zu 80 % Agenten-Coding und 20 % Korrekturen/Touch-ups
- Praktisch ist es zu einer Form des Programmierens auf Englisch geworden, bei der man dem LLM sprachlich vorgibt, welchen Code es schreiben soll
- Es kratzt etwas am Ego, aber die Fähigkeit, Software in großen „Code-Aktions“-Einheiten zu bearbeiten, ist enorm nützlich
- Wenn man sich daran anpasst, es einrichtet, die Nutzung lernt und versteht, was möglich bzw. nicht möglich ist, wird es noch effektiver
- Es ist die größte grundlegende Veränderung des Coding-Workflows in rund 20 Jahren Programmiererfahrung, und sie ist innerhalb weniger Wochen eingetreten
- Vermutlich passiert Ähnliches bereits bei einem erheblichen Anteil (zweistellige Prozentsätze) der Engineers, während die öffentliche Wahrnehmung eher im niedrigen einstelligen Prozentbereich liegen dürfte
IDE/Agenten-Schwarm/Fehleranfälligkeit
- Den Hype um „man braucht keine IDE mehr“ oder „Agenten-Schwärme“ hält er derzeit für übertrieben
- Die Modelle machen weiterhin Fehler; wenn der Code wirklich wichtig ist, muss man ihn mit Argusaugen überwachen, und es ist nötig, daneben eine große IDE offen zu haben
- Die Art der Fehler verändert sich: nicht mehr bloße Syntaxfehler, sondern subtile konzeptionelle Fehler, wie sie ein etwas nachlässiger und voreiliger Junior-Entwickler machen würde
- Der häufigste Fehlertyp: Es trifft falsche Annahmen anstelle des Nutzers und macht ohne Rückfrage einfach weiter
- Weitere Probleme:
- kann Verwirrung nicht gut managen
- stellt keine Rückfragen zur Klärung
- macht Inkonsistenzen nicht sichtbar
- zeigt keine Trade-offs auf
- widerspricht nicht, wenn Widerspruch angebracht wäre
- zeigt noch immer eine gewisse schmeichlerische (sycophantic) Tendenz
- Im Plan-Modus wird es besser, aber es braucht einen leichtgewichtigen Inline-Plan-Modus
- Außerdem gibt es die Tendenz, Code und APIs übermäßig zu verkomplizieren, Abstraktionen aufzublähen und nach der Arbeit toten Code nicht aufzuräumen
- Mitunter implementiert es über 1000 Zeilen hinweg eine ineffiziente, aufgeblähte und fragile Struktur, und wenn man fragt: „Geht das nicht auch so?“, kommt sofort: „Klar!“, und es kürzt alles auf 100 Zeilen
- Es kommt weiterhin vor, dass es Kommentare und Code ändert/löscht, die nichts mit der Aufgabe zu tun haben, ihm nicht gefallen oder die es nicht ausreichend versteht
- Diese Probleme treten selbst dann auf, wenn man einfache Korrekturversuche über Anweisungen in CLAUDE.md einbaut
- Trotz all dieser Probleme ist es immer noch eine schlichtweg gewaltige Verbesserung, und eine Rückkehr zum rein manuellen Coden ist sehr schwer
- Aktueller Workflow: links einige Claude-Code-Sessions in ghostty-Fenstern/Tabs, rechts die IDE zum Prüfen des Codes und für manuelle Bearbeitung
Hartnäckigkeit (Tenacity)
- Es ist äußerst interessant zu sehen, wie Agenten unermüdlich an etwas dranbleiben
- Sie ermüden nicht, verlieren nicht den Mut und versuchen es weiter, selbst in Situationen, in denen ein Mensch längst aufgegeben und auf später verschoben hätte
- Wenn man zusieht, wie sie lange mit etwas ringen und nach 30 Minuten schließlich Erfolg haben, fühlt sich das wie ein „AGI-Gefühl“ an
- Man merkt, dass Ausdauer ein zentraler Engpass der Arbeit ist, und mit einem LLM in der Hand steigt sie dramatisch
Geschwindigkeitsgewinn
- Es ist unklar, wie man den „Geschwindigkeitsgewinn“ durch LLM-Unterstützung messen soll
- Was man ohnehin tun wollte, fühlt sich definitiv viel schneller an, aber der Haupteffekt ist eher, dass man viel mehr tut als ursprünglich geplant:
- Alle möglichen Dinge werden nun programmierbar, die früher den Aufwand nicht wert gewesen wären
- Man kann auf Code zugreifen, an dem man früher wegen fehlendem Wissen oder fehlender Skills nicht hätte arbeiten können
- Es ist zwar ein Geschwindigkeitsgewinn, aber in noch größerem Maß vermutlich eine Expansion
Hebelwirkung
- LLMs sind hervorragend darin, Schleifen zu durchlaufen, bis ein bestimmtes Ziel erreicht ist, und darin liegt ein Großteil des „AGI-Gefühls“
- Nicht Schritt für Schritt vorgeben, was zu tun ist, sondern Erfolgskriterien definieren und dann beobachten
- Zuerst Tests schreiben lassen und sie dann bestehen lassen
- In eine Schleife zusammen mit Browser MCP einbinden
- Zuerst einen vermutlich sehr genauen naiven Algorithmus schreiben lassen und dann um Optimierung bei gleichbleibender Genauigkeit bitten
- Wenn man den Ansatz von imperativ auf deklarativ umstellt, laufen Agenten länger in Schleifen und erzeugen mehr Hebelwirkung
Spaß
- Ein unerwarteter Punkt ist, dass Programmieren mit Agenten mehr Spaß macht
- Langweilige Lückenfüller-Arbeit fällt weg, und es bleiben nur die kreativen Teile
- Blockaden/Stillstand (der unspaßige Zustand) nehmen ab, und man erlebt mehr Mut — weil es immer einen Weg gibt, gemeinsam positive Fortschritte zu machen
- Andere empfinden das Gegenteil: LLM-Coding wird Engineers in jene aufteilen, die das Coden selbst lieben, und jene, die das Erschaffen lieben
Verkümmerung (Atrophy)
- Es wird deutlich, dass die Fähigkeit, Code manuell zu schreiben, langsam verkümmert
- Generierung (Code schreiben) und Beurteilung (Code lesen) sind unterschiedliche Fähigkeiten des Gehirns
- Wegen der vielen kleinen syntaktischen Details beim Programmieren kann man Schwierigkeiten beim Schreiben haben und trotzdem Code-Reviews problemlos durchführen
Slopacolypse
- Es wird erwartet, dass 2026 das Jahr der Slopacolypse (Flut minderwertiger KI-generierter Inhalte) auf GitHub, Substack, arXiv, X/Instagram und generell in allen digitalen Medien wird
- Neben echten Verbesserungen wird es noch viel mehr KI-Hype-Produktivitätstheater geben (als ob das überhaupt noch steigerbar wäre)
Fragen
- „Was passiert mit dem 10X-Engineer?“ — also mit dem Produktivitätsverhältnis zwischen durchschnittlichen und Top-Engineers? Es könnte deutlich steigen
- Werden, bewaffnet mit LLMs, Generalisten Spezialisten zunehmend übertreffen? LLMs sind bei Lückenfüllung (Mikro) viel stärker als bei großer Strategie (Makro)
- Wie wird sich zukünftiges LLM-Coding anfühlen? Eher wie StarCraft? Oder wie Factorio? Oder wie Musik machen?
- Wie viele Bereiche der Gesellschaft sind durch digitale Wissensarbeit als Flaschenhals begrenzt?
TLDR
- Die Fähigkeiten von LLM-Agenten wie Claude und Codex haben um Dezember 2025 offenbar eine Art Konsistenz-Schwelle überschritten und dadurch in Software Engineering und angrenzenden Bereichen einen Phasenwechsel (phase shift) ausgelöst
- Es fühlt sich so an, als liege der Intelligenzteil plötzlich deutlich vor allem anderen — Integration (Tools, Wissen), Bedarf an neuen organisatorischen Workflows, Prozesse, breitere Verbreitung
- 2026 wird ein energiegeladenes Jahr sein, in dem die Branche diese neuen Fähigkeiten verarbeitet
15 Kommentare
Auf Grundlage des Inhalts dieses Beitrags wurde offenbar auch eine Skills-Version veröffentlicht, die das Verhalten von Claude Code verbessert.
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
Ich glaube, ich habe die 20 % viel zu sehr vernachlässigt
Kürzlich bin ich auf einen Bug gestoßen, den die KI nicht lösen konnte ... sie ist nicht allmächtig, aber mir wurde bewusst, dass ich sie so behandelt hatte, als wäre sie es.
Ach ... hahaha
Das frage ich mich immer wieder: Es ist sicher gut, wenn Leute, die bereits durch manuelles Codieren geprägt wurden, LLMs überwachen. Aber für Menschen, die gerade erst anfangen zu lernen, dürfte es schwer sein zu beurteilen, ob etwas richtig ist oder nicht, wenn sie nur auf den Code schauen, den das LLM erzeugt.
Haben sich die Leute, die früher in Assembler programmiert haben, wohl beim Aufkommen der Compiler gefragt, wie man einem Compiler vertrauen soll, der so miserablen Assembler-Output ausspuckt?
Damals haben sie wahrscheinlich auch in C programmiert und dabei so codiert, dass der erzeugte Assembler-Output möglichst so ausfiel, wie sie es wollten.
Ich frage mich, ob sich das im KI-Zeitalter so weiterentwickeln wird, dass am Ende auch ohne menschliche Aufsicht per natürlicher Sprache ein fertiges Ergebnis zuverlässig herauskommt.
Ich glaube, selbst damals, als Menschen noch Code geschrieben haben, wusste man ohne Lernen nicht, was eigentlich falsch lief, haha.
Assembler-Experten schimpfen noch immer auf Compiler. Entscheidend ist letztlich, dass man in Situationen, in denen extreme Optimierung nötig ist, solche Spezialisten braucht; auf KI übertragen heißt das, dass es für KI selbst bei weiterer Entwicklung schwer sein könnte, Menschen zu übertreffen, die auf höchstem Niveau optimieren. Im Allgemeinen kann allerdings schon jetzt kein Mensch mehr mit KI mithalten. Noch ein AlphaGo-Moment wäre spannend — etwa ein AlphaCode-Wettkampf.
Wenn man sich bemüht, den erzeugten Code zu analysieren und zu verstehen, scheint das in Ordnung zu sein.
Bei Compilern ist das ein etwas anderes Konzept: Da sie regelbasiert Assembly erzeugen, bewegen sie sich in einem deterministischen Bereich. Deshalb tritt ein Problem, wenn es einmal überprüft wurde, danach in der Regel nicht erneut auf. LLMs hingegen befinden sich in einem probabilistischen Bereich, sodass Probleme erneut auftreten können.
Ob sich diese probabilistische Genauigkeit weiterentwickelt und nahezu 100 Prozent erreicht, weiß ich nicht. Wenn jedoch schon die natürlichsprachige Anforderung selbst ungenau ist, wird am Ende auch das Ergebnis ungenau sein. Daher hängt eine
gutefertige Lösung letztlich doch vom Menschen ab, denke ich.Ich mache mir auch Sorgen um Junioren, die schon seit ihrer Studienzeit mit LLMs in Berührung gekommen sind. Ich habe auch den Eindruck, dass sich der Pool für die Einstellung von Junioren etwas verschlechtert hat, aber das ist wiederum schwer zu belegen...
Persönlich denke ich, dass es kaum einen Unterschied macht, solange man CS-Wissen hat.
Oder vielleicht liegt es daran, dass ich es derzeit so nutze, als würde ich Pair Programming mit einem Freund machen, der extrem schnell tippt und den gesamten Code für mich schreibt...
Letztlich kommt beim tieferen Entwickeln unweigerlich der Punkt, an dem man wissen muss, was innerhalb der Abstraktionsschicht passiert.
Die Kluft zwischen natürlichsprachlichem Prompt und generiertem Code ist jedoch zu groß, sodass es schwierig erscheint, vom Prompt aus in das Innere der LLM-Abstraktionsschicht vorzudringen.
Im Moment übermitteln wir dem LLM das Konzept der Spezifikation aus unserem Kopf per Prompt und lesen den geschriebenen Code anschließend erneut, um ihn zu verifizieren.
Das kommt eher einer Review von Code nahe, den jemand anderes geschrieben hat, sodass es sich nicht so anfühlt, als würde man in das Innere der Abstraktion eintauchen.
Dem stimme ich weitgehend zu. Im aktuellen Projekt habe ich etwa 100.000 Zeilen committet (die tatsächliche Code-Menge ist noch größer) und nutze im Schnitt 2–3 Agenten. Ich würde sagen, dass etwa 95 % von Agenten geschrieben werden.
Aber Tests und toter Code müssen weiterhin gepflegt werden, und es braucht Details zu Testfällen und zu den Kriterien, wann Tests als bestanden gelten. Wichtig ist die Steuerung dessen, was bis zu welchem Grad erledigt werden soll. Dafür müssen nicht nur die Pläne, sondern auch die Architektur, die die Harness bereitstellt, sowie die Einstellungen von Rules und Ähnlichem kontinuierlich aktualisiert werden.
Hacker-News-Kommentare
Es ist interessant zu sehen, wie der Agent nicht müde wird und immer weiter versucht
Während GPU und NPU heiß laufen, geben wir ihm sogar Daten, die wir normalerweise nicht teilen würden
Im Moment wirkt das wie ein bequemer Tausch, aber langfristig besteht die Gefahr wachsender Abhängigkeiten und gesellschaftlicher Probleme
Am Ende könnte daraus eine Struktur werden, in der wir diesen riesigen Gatekeepern ausgeliefert sind
Bei der Arbeit mit AI scheint das größere Problem nicht geistiger Abbau zu sein, sondern dass man in Selbstzufriedenheit und Lethargie verfällt
Anfangs sorgt das schnelle Ergebnis für einen Dopaminschub, aber je öfter es passiert, desto mehr hat man das Gefühl, dass die AI die Projektrichtung nach Belieben an sich zieht
Am Ende verschwinden die kreativen Experimente, die ich eigentlich machen wollte, und ich werde von der Gravitation ihres latenten Raums eingesogen
Das ist wie Doomscrolling: eine süchtig machende Schleife, in der man ständig die nächste Ausgabe sehen will
Ich baue gerade ein Multiplayer-Spiel mit Rust und Bevy, und obwohl der Code läuft, ist es Code, den ich selbst nicht verstehe
Früher wäre ich nur bis hier gekommen, wenn ich das Werkzeug vollständig verstanden hätte; jetzt habe ich ein halbwegs funktionierendes Spiel gebaut, weiß aber nicht einmal, was ECS ist
Wenn man an Wartung oder Incident-Response denkt, ist das ein wirklich gefährlicher Zustand
Wir konzentrieren uns jetzt darauf, das Modell zu lernen, und verlernen, selbst zu denken
Da sich die Nutzung von LLMs ständig verändert, steht man letztlich auf einem endlosen Lern-Laufband
Auch nach einer langen Pause bleibt das Gefühl erhalten, und wenn man wieder aufsteigt, kommt es schnell zurück
Immer mehr Entwickler geben einfach auf, wenn das LLM etwas nicht weiß, und wollen keine Dokumentation mehr lesen
Selbst wenn man die Doku direkt liest und sogar Screenshots zeigt, reagieren sie noch mit: „Ist das wirklich richtig?“
Wegen kurzer Glücksreize feuert man ständig neue Prompts ab und wartet darauf: „Was kommt diesmal heraus?“
LLM-Coding wird zu einem Moment der Trennung zwischen „Menschen, die Coding mögen“ und „Menschen, die Bauen mögen“
Ich bin eher ein Builder-Typ, der gern Ergebnisse hervorbringt, deshalb macht mir dieser Wandel Spaß
Wer hingegen das Coding selbst genießt, empfindet diese Entwicklung eher als unangenehm
Der Reiz des Programmierens lag in dem Prozess, Probleme zu strukturieren und selbst umzusetzen
Jetzt fühlt es sich so an, als würde ich nicht selbst coden, sondern nur Anweisungen geben, und dadurch verliere ich das Interesse
Schon früher gab es Gegensätze wie Compile vs. Interpret, typisiert vs. untypisiert, schnelle Auslieferung vs. Wartbarkeit
Erfolgreiche Software durchläuft am Ende immer den Übergang von einer chaotischen Anfangsphase zu einer stabil skalierenden Phase
Ob AI diesen Prozess unterstützt oder eher komplizierter macht, ist noch nicht klar
Ihnen geht es nicht nur um das Ergebnis, sondern der Spaß liegt im Entwerfen der Systemstruktur
Menschliche Teammitglieder tragen Verantwortung und Vertrauen, LLMs jedoch nicht
Die Vorstellung, dass AI eine 10-fache Produktivitätssteigerung bringen kann, ist interessant
DevOps hat die Zusammenarbeit zwischen Entwicklung und Betrieb verändert und High-Performance-Teams hervorgebracht; das kam für Teams einem 10X-Effekt recht nahe
Um AI-Coding gut zu nutzen, braucht es wie bei DevOps kontinuierliche Verbesserung, veränderte Workflows und einen Prozess aus Automatisierung und Verifikation, um Vertrauen aufzubauen
So wie sich DevOps wegen neuer Konzepte und notwendiger Kulturveränderungen nicht sofort überall durchgesetzt hat, könnte auch AI-Coding trotz 10X-Potenzial ohne Lernen und Kulturwandel nur langsam adaptiert werden
Für eine nachhaltige Verankerung braucht es Ausbildung und Veränderungen in der Engineering-Kultur
Ich hatte das Gefühl, dass LLMs in großen Codebases nutzlos sind
Vor allem in komplexem Code mit vielen Wechselwirkungen helfen sie fast gar nicht
Sie in bestehende große oder komplexe Codebases einzubringen, ist riskant, wenn es sich nicht um begrenzte Änderungen mit sorgfältigem Review handelt
Bei einfachen Strukturen ist es beeindruckend, dem Agenten eine Dateiliste zu geben und die Implementierung zu überlassen, aber mit steigender Komplexität müssen die Prompts immer stärker zu detaillierten Anweisungen werden, damit noch gute Ergebnisse herauskommen
Anders als frühere Modelle hilft es jetzt auch in komplexen Monorepos ganz praktisch weiter
Man sollte vergleichen, ob sie mit denselben Informationen besser arbeiten als ein neues Teammitglied
Kommerzielle interne Codebases werden durch wiederholte Entwicklung nach Kundenanforderungen unübersichtlich, während ursprüngliche Annahmen und Anforderungen immer weiter auseinanderlaufen und technische Schulden entstehen
Wenn man mit LLMs per Refactoring aufräumt, etwa durch Auslagern von Helfern, Modularisierung oder Renaming, und die Struktur an aktuelle Anforderungen anpasst, wird das Verhalten des Agenten danach vorhersehbarer
Anforderungen, Akzeptanzkriterien und User Stories sollten in Markdown festgehalten werden; danach braucht es einen schrittweisen Ablauf, bei dem zuerst detailliert geplant und erst dann implementiert wird
Beeindruckend ist der Punkt, an dem Beharrlichkeit und Ausdauer der AI die menschlichen Grenzen überschreiten
Auch in der Forschung heißt es, dass Grit enger mit Erfolg verbunden ist als Intelligenz
Solange das Budget reicht, besitzt ein LLM unendliche Beharrlichkeit
In den letzten Monaten hatte ich eher das Gefühl, dass sich die AI-Leistung sogar verschlechtert hat
Sie vergisst Regeln und erzeugt übermäßige Planung sowie überengineerten Code
Im Frontend-Bereich (HTML + Tailwind) ist sie allerdings weiterhin nützlich
Übertriebene Erwartungen an IDEs oder Agent Swarms halte ich noch für verfrüht
Beim Bauen einer iPhone-App war ich beeindruckt von Claudes Code-Generierungsfähigkeit auf Basis englischer Prompts
Wenn ich die Dinge zusammennehme, die ich auch in meinem Umfeld höre, scheint es am Ende tatsächlich genau auf diese Unterscheidung hinauszulaufen.