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
Noch keine Kommentare.