Was sich in drei Jahren mit LLMs verändert hat

Als ich angefangen habe, LLMs ernsthaft für Softwareentwicklung auszuprobieren, war meine wichtigste Frage ziemlich banal:

Kann mir dieses Werkzeug beim realen Entwickeln überhaupt nennenswert helfen?

Meine Antwort lag 2023 irgendwo zwischen „manchmal erstaunlich“ und „noch ziemlich anstrengend“. Die Modelle konnten überzeugend erklären, Code erzeugen und auf den ersten Blick erstaunlich technische Antworten geben. Gleichzeitig produzierten sie viel Noise: APIs wurden erfunden, Framework-Funktionen falsch angenommen und aktuelle Entwicklungen mit veraltetem Wissen vermischt. Gerade bei Technologien, die sich schnell veränderten, musste man ziemlich genau wissen, wann eine Antwort lediglich plausibel klang.

Für kleine, klar abgegrenzte Aufgaben war das trotzdem bereits nützlich. Eine Funktion erklären, eine Methode refactoren oder ein überschaubares Beispiel erzeugen funktionierte häufig erstaunlich gut. Eine unbekannte, gewachsene Anwendung zu untersuchen, relevante Stellen zu finden, vorhandene Architektur zu verstehen, Änderungen über mehrere Schichten umzusetzen, Tests auszuführen und Fehler selbstständig zu verarbeiten, war dagegen eine andere Kategorie.

Heute, im Jahr 2026, arbeite ich deutlich anders mit diesen Werkzeugen. Nicht weil sie plötzlich fehlerfrei wären, sondern weil sich die Art der Aufgaben verändert hat, für die ich sie sinnvoll einsetzen kann.

Für mich verlief diese Entwicklung ungefähr so:

Das ist keine universelle Evolutionskurve künstlicher Intelligenz, sondern die Entwicklung meiner eigenen Nutzung. Genau aus dieser Erfahrung ist diese Serie entstanden.

Zwei sehr unterschiedliche Realitäten

Meine Erfahrungen mit LLMs stammen aus zwei Kontexten, die sich kaum stärker unterscheiden könnten. Im beruflichen Umfeld arbeite ich mit großen Softwaresystemen, teilweise in Bereichen mit sehr sensiblen Daten. Dort reicht die Frage „Was kann der Agent technisch?“ nicht aus. Mindestens genauso wichtig ist, welche Informationen ein System überhaupt sehen darf, auf welche Werkzeuge es zugreifen kann, welche Entscheidungen es selbst treffen soll, wie Veränderungen anschließend nachvollzogen und geprüft werden können und wer am Ende die Verantwortung dafür trägt.

Ein Agent, der technisch eine komplette Anwendung analysieren könnte, darf deshalb noch lange nicht automatisch eine komplette Anwendung analysieren. Informationsgrenzen, Datenschutz, Governance, Security und Nachvollziehbarkeit gehören genauso zu professioneller Agentic Work wie das Modell selbst.

Privat hatte ich wesentlich mehr Freiheit. Über die vergangenen Jahre habe ich LLMs und Coding Agents in knapp 40 eigenen Projekten unterschiedlicher Größe und Komplexität eingesetzt – von kleinen Experimenten über Frontends, Backends und Infrastruktur bis zu Anwendungen, in denen AI selbst Bestandteil des Produkts war.

Dort konnte ich deutlich aggressiver experimentieren. Ich konnte Agents Zugriff auf vollständige Repositories geben, Agent Files und Skills verändern, Memories einsetzen, Specs präzisieren, Modelle wechseln oder beobachten, was passiert, wenn Kontext erweitert oder reduziert wird. Das ist keine wissenschaftliche Stichprobe. Es ist aber inzwischen genug praktische Arbeit, um einen deutlichen Unterschied zu meinen ersten Experimenten erkennen zu können.

Am Anfang beeindruckte vor allem die Sprache

Die frühen breit verfügbaren LLMs hatten einen interessanten Effekt: Sie wirkten schneller kompetent, als sie es in vielen technischen Situationen tatsächlich waren. Die Sprache war überzeugend, die Lösung klang plausibel, und der Code sah aus wie etwas, das ein Entwickler tatsächlich so geschrieben haben könnte.

Gerade darin lag ein Teil des Problems. Wer das jeweilige Framework oder die API kannte, bemerkte relativ schnell, dass eine Funktion nicht existierte, ein Parameter falsch war oder die vorgeschlagene Lösung auf einem inzwischen überholten Stand basierte. Wer dieses Wissen nicht hatte, bekam trotzdem eine sehr selbstbewusst klingende Antwort.

Das machte die Systeme für mich nicht wertlos. Im Gegenteil: Schon damals waren sie gute Sparringspartner für kleine, klar begrenzte Probleme. Sie konnten Varianten erzeugen, Boilerplate reduzieren, Code erklären und beim Einstieg in unbekannte Technologien helfen. Die eigentliche Integrationsarbeit blieb jedoch weitgehend beim Menschen.

Der typische Ablauf blieb dabei stark vom Menschen gesteuert.

Die AI war ein Werkzeug innerhalb eines menschlich gesteuerten Entwicklungsprozesses. Und die entscheidende technische Arbeit bestand häufig gar nicht darin, eine einzelne Funktion zu schreiben. Schwieriger war herauszufinden, wo eine Änderung hingehört, welche Teile eines Systems betroffen sind und welche Nebenwirkungen daraus entstehen können. Genau dort waren die frühen Systeme für mich deutlich begrenzter.

Der wichtigste Fortschritt war für mich nicht besserer Code

Irgendwann verschob sich meine Wahrnehmung. Natürlich wurde auch die Codegenerierung besser. Interessanter war für mich aber etwas anderes:

LLMs wurden für meine Arbeit vor allem dadurch wertvoller, dass sie bestehenden Code besser lesen konnten.

Plötzlich war nicht mehr nur die einzelne Funktion interessant. Mehrere Dateien konnten gemeinsam betrachtet, Abhängigkeiten erkannt und unbekannte Features exploriert werden. Ein Fehler ließ sich durch mehrere Ebenen verfolgen, bestehende Patterns wurden sichtbar und unterschiedliche Lösungswege konnten gegen die vorhandene Architektur gehalten werden.

Damit änderte sich auch der Nutzen bei unbekannten Technologien. Früher bedeutete eine neue Library oder ein unbekanntes Subsystem häufig zuerst, Dokumentation zu lesen, Einstiegspunkte zu suchen, Code zu durchsuchen und aus Beispielimplementierungen langsam ein mentales Modell aufzubauen. Heute kann ein LLM diesen ersten Orientierungsschritt erheblich beschleunigen.

Es nimmt mir damit nicht das Denken ab. Es verkleinert zunächst den Suchraum. Ein Agent kann Einstiegspunkte finden, relevante Dateien zusammenstellen, Abhängigkeiten verfolgen, Hypothesen zu einem Fehler formulieren oder einen Proof of Concept vorbereiten. Das Ergebnis ist noch kein vollständiges Systemverständnis, aber der Weg zum eigenen Systemverständnis kann deutlich kürzer werden.

Für mich war das eine wesentlich wichtigere Entwicklung als die Frage, ob die nächste generierte Methode noch etwas eleganter geworden war.

Vom Assistenten zum Agenten

Mit der Tool-Nutzung änderte sich die Arbeitsweise noch einmal grundlegender. Ein klassischer Chat kennt zunächst das, was ich ihm gebe. Ein Coding Agent kann – innerhalb seiner Berechtigungen – selbst im Repository suchen, Dateien lesen und verändern, Tests starten, Compiler- oder Linterfehler sehen und auf deren Ergebnisse reagieren.

Damit entsteht ein anderer Ablauf:

Das klingt zunächst nach einem graduellen Unterschied. Praktisch ist er ziemlich groß.

In meinen eigenen Projekten ist es inzwischen realistisch, einem Coding Agent ein klar abgegrenztes Feature zu beschreiben und eine zusammenhängende Umsetzung über mehrere technische Schichten zu erhalten. Je nach System kann das beispielsweise beim Datenmodell oder Backend beginnen und über API und State bis zur UI reichen.

Das funktioniert weder bei jeder Aufgabe noch mit jedem Modell. Es braucht ausreichenden Kontext, liefert nicht automatisch eine gute Lösung und ersetzt vor allem kein Review. Aber allein die Tatsache, dass ein solcher Workflow praktisch nutzbar geworden ist, unterscheidet meine heutige Arbeit fundamental von meinen ersten Experimenten.

Auch die Forschung beginnt den Unterschied zwischen klassischen Assistenzsystemen und stärker agentischen Werkzeugen genauer zu betrachten. Eine kontrollierte CHI-Studie zu Copilots und Coding Agents beschreibt beispielsweise, dass stärker automatisierte Agents Aufgaben übernehmen konnten, bei denen klassische Assistenzsysteme weniger weit gingen, und dabei menschlichen Aufwand reduzieren konnten. Gleichzeitig entstanden neue Anforderungen daran, nachvollziehen und einordnen zu können, was ein Agent tatsächlich tut. [1]

Das passt gut zu meiner praktischen Erfahrung: Mehr Autonomie entfernt die menschliche Arbeit nicht zwangsläufig. Sie verändert sie.

Ein Agent muss nicht perfekt sein, um wertvoll zu sein

Ein Teil der Diskussion über AI in der Softwareentwicklung verwendet für mich einen merkwürdigen Maßstab. Häufig lautet die Frage, ob AI einen erfahrenen Entwickler vollständig autonom ersetzen kann. Fällt die Antwort darauf heute negativ aus, wird daraus schnell geschlossen, die Technologie sei überschätzt.

Für meine tägliche Arbeit ist eine andere Frage wesentlich interessanter:

Wie viel hochwertige Arbeit kann ich mit diesen Werkzeugen zuverlässig verantworten?

Ein Coding Agent muss nicht perfekt sein, um enorm nützlich zu sein. Wenn er die Exploration eines unbekannten Bereichs beschleunigt, einen Proof of Concept in einer Stunde statt an einem Nachmittag vorbereitet oder repetitive Änderungen konsistent über viele Dateien durchführen kann, entsteht bereits ein erheblicher Nutzen. Dasselbe gilt, wenn er einen Fehler über mehrere Layer zurückverfolgt, plausible Ursachen herausarbeitet oder eine gut spezifizierte Änderung weitgehend selbstständig umsetzt, deren Architektur und Ergebnis ich anschließend prüfe.

Das Entscheidende ist für mich nicht die Abwesenheit menschlicher Arbeit. Interessanter ist die Verschiebung dessen, womit ich meine Zeit verbringe.

Meine persönliche Wahrnehmung ist dabei eindeutig: Bei vielen Aufgaben bin ich mit modernen LLMs und Coding Agents erheblich schneller. Daraus lässt sich jedoch keine allgemeine Produktivitätsbehauptung ableiten. Die bisherige Forschung zeichnet ein deutlich differenzierteres Bild.

Drei randomisierte Feldexperimente mit insgesamt 4.867 Entwicklern fanden 2026 im kombinierten Ergebnis einen Anstieg erledigter Aufgaben von rund 26 Prozent bei Entwicklern mit AI-Coding-Unterstützung. Besonders größere Effekte zeigten sich dort bei weniger erfahrenen Entwicklern. Untersucht wurden allerdings Coding Assistants und damit nicht die gesamte Bandbreite heutiger agentischer Workflows. [2]

Dem gegenüber steht ein viel diskutiertes Experiment mit 16 erfahrenen Open-Source-Entwicklern, die 246 reale Aufgaben in Projekten bearbeiteten, die sie im Durchschnitt seit Jahren kannten. Dort führte die erlaubte Nutzung damaliger AI-Werkzeuge zu einer um 19 Prozent längeren Bearbeitungszeit. Bemerkenswert war dabei auch, dass die Entwickler selbst nach dem Experiment weiterhin glaubten, mit AI schneller gewesen zu sein. [3]

Eine Meta-Analyse aus dem Jahr 2026, die 23 Studien zusammenfasst, kommt wiederum auf einen moderaten positiven Produktivitätseffekt, allerdings mit erheblicher Streuung zwischen den untersuchten Situationen. Die Effekte waren in kontrollierten Experimenten tendenziell größer als in Open-Source- und Unternehmenskontexten. [4]

Für mich ist das kein Widerspruch, den man schnell auflösen sollte. Es ist möglicherweise die interessantere Erkenntnis: AI-Unterstützung kann Produktivität steigern, aber Größe und möglicherweise sogar Richtung dieses Effekts hängen stark von Kontext, Aufgabe, Werkzeug und Entwickler ab.

Das ist weniger spektakulär als „AI macht Entwickler 50 Prozent schneller“. Als Engineering-Aussage ist es wesentlich brauchbarer.

Schnell erzeugter Code ist noch keine gute Lösung

Ein anderer Reflex hat sich bei mir durch LLMs nicht verändert: Ich übernehme Code nicht deshalb, weil er funktioniert. Das galt vorher, und mit Coding Agents gilt es erst recht.

Ein Agent kann einen Test grün bekommen und trotzdem die falsche Systemgrenze gewählt haben. Er kann eine Anforderung korrekt umsetzen und dabei eine Architekturentscheidung treffen, die den nächsten Anforderungen im Weg steht. Er kann einen bestehenden Workaround sauber reproduzieren, lokale Konsistenz herstellen und gleichzeitig globale Inkonsistenz verstärken oder eine technisch korrekte Lösung im System an der falschen Stelle platzieren.

Auch die Forschung zur Qualität AI-generierten Codes liefert Gründe, Verifikation nicht als optionalen letzten Schritt zu betrachten. Ein systematischer Review zur Security von AI-Code dokumentiert bekannte Schwächen generierter Lösungen und hebt die Bedeutung geeigneter Prüf- und Verifikationsprozesse hervor. [5]

Daraus folgt nicht, dass AI-Code unsicher und menschlicher Code sicher sei. Das wäre offensichtlich zu einfach. Code erhält seine Qualität weder durch einen Menschen noch durch ein Modell als Urheber. Er muss dieselben fachlichen, architektonischen, funktionalen und sicherheitsrelevanten Qualitätsgrenzen passieren.

Gerade an diesem Punkt stoße ich in meinen privaten Projekten auf eine Beobachtung, die mich besonders interessiert. Ich arbeite dort teilweise mit sehr expliziten Vorgaben: Architekturregeln, Agent Files, Skills, Memories, Beispielen und klaren Grenzen dafür, was etwa in Components, Application Layer, State oder Infrastructure gehören soll. Trotzdem sehe ich bestimmte Muster wiederkehren.

Nach einigen Änderungen beginnt beispielsweise eine Component wieder, einen fachlichen Ablauf selbst zu orchestrieren. Ein sauber reaktiver Flow erhält irgendwo eine imperative Zwischenlösung. Eine Layer-Grenze wird lokal aufgeweicht, weil die unmittelbare Lösung einfacher erscheint. Das passiert nicht zwangsläufig sofort und auch nicht bei jedem Agent, aber oft genug, dass es für mich eine wiederkehrende Praxisbeobachtung ist.

Persönliche Beobachtung: Explizite Architekturregeln reduzieren problematische Entscheidungen deutlich. Sie verhindern aber nicht automatisch, dass Coding Agents im Verlauf längerer Arbeit wieder in bekannte, lokal plausible Muster zurückfallen.

Warum das geschieht, ist eine der Fragen dieser Serie. Es wäre zu einfach, daraus zu schließen, LLMs könnten grundsätzlich keine Architektur verstehen. Interessanter ist, wie Modell, Context, bestehender Code, lokale Beispiele, Spezifikation und Tooling gemeinsam beeinflussen, welche Lösung als nächster Schritt plausibel wird.

AI als Katalysator

Viele Probleme, die wir heute im Zusammenhang mit Coding Agents beobachten, sind erstaunlich alte Probleme des Software Engineerings. Menschen kopieren vorhandenen Code, orientieren sich an lokalen Beispielen, interpretieren unklare Anforderungen unterschiedlich, übernehmen Workarounds und bauen auf Entscheidungen auf, deren ursprünglicher Kontext längst verschwunden sein kann.

Coding Agents erfinden diese Mechanismen nicht. Sie können sie aber massiv beschleunigen.

Stellen wir uns vor, in einem System existiert ein unglücklicher Workaround. Er funktioniert, liegt nah an der neuen Aufgabe und sieht aus wie ein etabliertes Pattern. Ein späterer Change orientiert sich daran, wodurch der Workaround ein zweites Mal erscheint. Damit wird er im Repository sichtbarer und kann bei der nächsten ähnlichen Aufgabe noch stärker wie eine gewollte Konvention wirken.

Das erinnert an einen Broken-Window-Effekt. Ich behaupte damit ausdrücklich nicht, dass dieser Mechanismus für Coding Agents bereits als universelles Gesetz nachgewiesen wäre. Für mich ist es zunächst eine Hypothese, die aus einer wiederkehrenden Beobachtung entsteht: Wenn bestehender Code als wichtiger Kontext für neue Entscheidungen dient, könnten häufig sichtbare lokale Patterns ihre eigene weitere Reproduktion begünstigen.

Das Spannende daran ist, dass diese Dynamik nicht ausschließlich negativ sein muss. Gute Patterns können auf dieselbe Weise sichtbar werden, reproduziert werden und dadurch die Konsistenz eines Systems erhöhen.

Deshalb gefällt mir die Vorstellung von AI als Katalysator oder Verstärker besser als die Vorstellung einer völlig neuen Ursache für Softwareprobleme.

AI erfindet viele bekannte Probleme des Software Engineerings nicht neu. Sie kann ihre Geschwindigkeit und Reichweite drastisch erhöhen.

Dasselbe gilt für gute Engineering-Praktiken. Architektur wird dadurch nicht unwichtiger. Ihre Wirkung kann lediglich wesentlich schneller sichtbar werden.

Der Mensch kann heute erstaunlich effektiv gegensteuern

Bis hierhin könnte leicht der Eindruck entstehen, Coding Agents würden zwangsläufig irgendwann architektonisch entgleisen und müssten deshalb permanent misstrauisch beobachtet werden. Das entspricht nicht meiner Erfahrung.

Der entscheidende Punkt ist, dass Geschwindigkeit auf beiden Seiten wirkt. Ein Agent kann in kurzer Zeit sehr viel umsetzen. Ein erfahrener Entwickler kann häufig ebenfalls früh erkennen, dass eine Lösung gerade in eine ungünstige Richtung läuft. Dann wird nicht alles verworfen, sondern die Spec präzisiert, eine Grenze expliziter gemacht, ein Pattern als Referenz genannt oder eine falsche Abstraktion entfernt. Anschließend arbeitet der Agent weiter.

Agent arbeitet schnell
↓
Ergebnis ist weitgehend brauchbar
↓
problematische Richtung wird früh erkannt
↓
Context oder Vorgabe wird korrigiert
↓
Agent setzt weiter um

Das ist für mich derzeit eine der produktivsten Formen von Agentic Work. Nicht: „Mach alles und sag Bescheid, wenn du fertig bist.“ Sondern eher: „Arbeite weitgehend selbstständig innerhalb eines klaren Raums, während ich besonders die Entscheidungen überprüfe, an denen dieser Raum verlassen werden könnte.“

Genau deshalb sehe ich erfahrene Entwickler mit tiefem Systemverständnis Stand 2026 weiterhin als entscheidenden Bestandteil professioneller Agentic Work. Das ist keine Aussage darüber, was Modelle in fünf oder zehn Jahren können werden. Es beschreibt den Zustand, mit dem ich heute arbeite.

Je mehr Implementierungsarbeit ich an einen Agent delegiere, desto wichtiger wird momentan jemand, der beurteilen kann, ob die entstehende Lösung zum System passt.

Auch deshalb sollte man repositoryweite Änderungen und vollständige Softwareautonomie nicht gleichsetzen. Neuere Benchmarks versuchen zunehmend, nicht nur einzelne Codeänderungen zu bewerten, sondern komplette Abläufe aus Environment Setup, Implementierung und Verifikation. Der SWE-Cycle-Preprint von 2026 berichtet beispielsweise einen deutlichen Leistungseinbruch, wenn diese zuvor getrennten Aufgaben als vollständiger End-to-End-Prozess ohne menschliches Scaffolding ausgeführt werden müssen. [6]

Ein Agent kann heute beeindruckende, zusammenhängende Änderungen durchführen. Daraus folgt nicht, dass er ein beliebiges Softwareprojekt vollständig autonom übernehmen kann. Zwischen diesen beiden Aussagen liegt ein ziemlich großer Raum – und genau dort findet für mich derzeit die interessante praktische Arbeit statt.

Die eigentliche Frage hat sich verändert

2023 habe ich mich gefragt:

Kann AI überhaupt sinnvoll programmieren?

Diese Frage interessiert mich heute kaum noch. Natürlich kann sie programmieren – nicht immer richtig, nicht immer gut und nicht ohne ausreichenden Context. Aber die Existenz brauchbarer Codegenerierung ist für mich keine offene Frage mehr.

Die interessantere Frage lautet inzwischen:

Wie setzen wir diese Geschwindigkeit so ein, dass daraus gute Software entsteht?

Damit öffnet sich ein wesentlich größeres Feld. Wir müssen verstehen, warum Ergebnisse nicht immer reproduzierbar sind, was Context tatsächlich bedeutet, welchen Einfluss Memory und Skills haben und was Benchmarks wie SWE-bench überhaupt messen. Wir müssen uns fragen, warum Agents trotz Regeln in bestimmte Richtungen driften können, wie genau Requirements werden müssen, wenn Implementierung immer billiger wird, welchen Einfluss Architektur auf den möglichen Lösungsraum hat und wie Verifikation funktionieren soll, wenn Software schneller erzeugt wird, als Menschen sie lesen können.

Hinzu kommen wirtschaftliche und organisatorische Fragen: Wann ist ein großes Frontier Model tatsächlich notwendig? Wann reicht ein kleineres oder lokales Modell? Was kostet Agentic Work, wenn man nicht nur Token, sondern auch Review, Infrastruktur und Fehlentscheidungen betrachtet? Und was passiert mit unserer eigenen Rolle, wenn immer mehr Implementierungsarbeit delegierbar wird?

Diese Serie wird einige dieser Fragen untersuchen. Nicht weil AI plötzlich jedes alte Problem der Softwareentwicklung ersetzt, sondern weil sie viele davon unter neuen Bedingungen sichtbar macht.

Ein Artikel von 2023 wäre heute schon historisch

Wenn ich diesen Artikel 2023 geschrieben hätte, wäre ein erheblicher Teil davon heute nur noch eine historische Momentaufnahme. Das ist bemerkenswert, aber kein Grund, nun in die Gegenrichtung genauso unseriös zu argumentieren.

Wir wissen nicht, wie groß die nächsten Sprünge werden. Wir wissen nicht, wo zusätzliche Skalierung wenig bringt oder welche heutigen Grenzen durch bessere Modelle verschwinden werden. Ebenso wenig wissen wir, welche Probleme sich langfristig als strukturelle Eigenschaften der eingesetzten Verfahren erweisen.

Deshalb halte ich zwei Aussagen gleichzeitig für wichtig:

Aus den Grenzen des Jahres 2026 sollten wir keine ewigen Grenzen ableiten.

Und genauso:

Aus drei Jahren außergewöhnlich schneller Entwicklung sollten wir keine unbegrenzte Zukunft extrapolieren.

Beides wäre Spekulation.

Für Software Engineering reicht der aktuelle Zustand ohnehin vollkommen aus. Die Technologie ist bereits leistungsfähig genug, dass wir lernen müssen, professionell mit ihr zu arbeiten.

Warum diese Serie entstanden ist

Ich möchte deshalb weder eine AI-Werbeserie schreiben noch eine Sammlung von Gründen, warum das alles überschätzt ist. Auch eine Modell-Bestenliste interessiert mich nur begrenzt. Sie wäre vermutlich veraltet, bevor die Serie fertig ist.

Mich interessiert die Engineering-Frage: Was funktioniert heute tatsächlich? Wo funktioniert es überraschend gut? Wo entstehen Risiken? Welche alten Probleme werden lediglich beschleunigt? Welche Arbeitsweisen helfen, welche Regeln helfen weniger als erwartet, was können wir messen und was bleibt Erfahrungswissen? Vor allem interessiert mich, welche Prinzipien auch dann noch sinnvoll sind, wenn die nächste Modellgeneration wieder deutlich besser ist als die heutige.

Meine Perspektive auf LLMs hat sich in den vergangenen Jahren mehrfach verändert: vom beeindruckenden Textgenerator über einen brauchbaren Coding Assistant und ein Werkzeug für Analyse und Exploration bis zu Agents, denen ich heute unter geeigneten Bedingungen erhebliche Teile einer konkreten Umsetzung übertragen kann.

Das ist weder „nur Noise“ noch der autonome Softwareentwickler, der ein komplexes System ohne menschliche Führung zuverlässig übernimmt. Beide Beschreibungen sind mir inzwischen zu bequem.

Die Realität dazwischen ist viel interessanter – und bereits praktisch genug, dass Software Engineering darauf eine Antwort braucht.

Diese Serie ist deshalb vor allem eine Bestandsaufnahme:

beobachten, verstehen, ausprobieren, überprüfen – und daraus möglichst belastbare Engineering-Prinzipien ableiten.

Bevor wir jedoch untersuchen können, warum Agents manchmal erstaunlich gute und manchmal erstaunlich merkwürdige Entscheidungen treffen, müssen wir einen Schritt zurückgehen.

Was passiert in einem LLM überhaupt? Was bedeuten Training und Inference? Was ist ein Token, was ist Context, und was meinen wir eigentlich, wenn wir sagen, ein Ergebnis sei probabilistisch?

Damit beginnt der nächste Artikel.

Quellen

[1] Valerie Chen, Ameet Talwalkar, Robert Brennan, Graham Neubig: Code with Me or for Me? How Increasing AI Automation Transforms Developer Workflows. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems, 2026. DOI: 10.1145/3772318.3790850.

[2] Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz: The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science, 2026. DOI: 10.1287/mnsc.2025.00535.

[3] Joel Becker, Nate Rush, Elizabeth Barnes, David Rein: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Preprint, 2025. arXiv: 2507.09089. DOI: 10.48550/arXiv.2507.09089.

[4] Sebastian Maier, Moritz Gunzenhäuser, J. Schweisthal, Manuel Schneider, S. Feuerriegel: A meta-analysis of the effect of generative AI on productivity and learning in programming. Preprint, 2026. arXiv: 2605.04779.

[5] Claudia Negri-Ribalta, Rémi Géraud-Stewart, Anastasia Sergeeva, Gabriele Lenzini: A systematic literature review on the impact of AI models on the security of code generation. Frontiers in Big Data 7, 2024. DOI: 10.3389/fdata.2024.1386720.

[6] Hao Guan, Lingyue Fu, Shao Zhang, Yaoming Zhu, Kangning Zhang, Lin Qiu, Xunliang Cai, Xuezhi Cao, Weiwen Liu, Weinan Zhang, Yong Yu: SWE-Cycle: Benchmarking Code Agents across the Complete Issue Resolution Cycle. Preprint, 2026. arXiv:2605.13139.