„Unsere Rolle im Prozess der Softwareherstellung wird langsam von Akteuren zu Zahnrädern in einer Maschine degradiert.“ So beschreibt ein Entwickler aus der Haskell-Community seine Sicht auf die großen Sprachmodelle. Sein Beitrag versteht sich ausdrücklich nicht als Abrechnung mit KI. Der Mann ist kein Gegner der Technik. Er plädiert für einen Mittelweg zwischen Abstinenz und blindem Delegieren, weil er seinen Beruf weiterhin als Handwerk begreift – nicht als Aufsichtsfunktion über einen Schwarm von Agenten.
Der Beitrag trägt den Titel „How to keep enjoying programming in a world of LLMs“ und stammt aus dem Haskell-Diskurs. Der Autor kennt die ethischen Einwände gegen die großen Modelle. Ihm geht es um etwas anderes: um die Frage, wie man beim Programmieren mit LLMs nicht die Freude verliert. Er beschreibt das übliche Szenario, in dem eine Spezifikation an ein Modell weitergereicht und das Ergebnis anschließend mühsam geprüft wird – ein Ablauf, der viele Entwickler ausbrennen lässt. Seine These ist einfach und unbequem: Wer selbst weiter Code schreibt, verliert weder sein Können noch seinen Spaß.
Warum die Freude an der Sprache selbst auf dem Spiel steht
Der Autor mag Haskell nicht nur wegen des fertigen Produkts, sondern wegen des Prozesses – wegen des Ausdrucks von Gedanken in dieser Sprache. Das erklärt, warum die Debatte um LLM-assistierte Programmierung je nach Sprache unterschiedlich hitzig geführt wird. In Sprachen, deren Reiz im Formulieren liegt, trifft das Generieren von Code den Kern der Motivation. Wer nur das fertige Ergebnis will, verliert weniger.
Das ist wie der Unterschied zwischen Kochen und Essen. Manche kochen, weil sie satt werden wollen, andere, weil das Schneiden, Rühren und Abschmecken selbst der Genuss ist. Ein Lieferdienst löst das Problem des Hungers, aber nicht das Bedürfnis des Kochens. Übertragen auf Software: Ein Agent kann dir Code liefern, aber er nimmt dir das Denken ab – und mit dem Denken oft auch die Befriedigung. Wie beim Kochen kannst du Teile abgeben und andere behalten.
Den Code nur zu lesen, reicht nicht, um ihn zu verstehen. Generierter Code, der nie ein Mensch geschrieben hat, wird zu einer fremden Landschaft, in der man einen Fehler nicht mehr findet, weil einem die Wege fehlen. Er nennt das eine „LLM-Wüste“, in der nur noch die Agenten zurechtkommen. Wer seine Codebasis besitzen will, muss also weiter selbst schreiben, sonst geht sie ihm Stück für Stück verloren.
Selbst schreiben hält die Fähigkeit am Leben
Ein starkes Argument des Autors betrifft die Übung. Fähigkeiten verkümmern, wenn man sie nicht nutzt, und die Schwelle zur Abgabe an einen Agenten ist verlockend niedrig. Nach ein paar Wochen ohne eigene Codearbeit fällt der Wiedereinstieg schwer – das kennt jeder, der längere Zeit nur Reviews gemacht hat. Der Beitrag nennt das nicht moralisch, sondern praktisch: Wer die Kontrolle behalten will, muss sie ausüben.
Die Qualität des generierten Codes wird nach Einschätzung des Autors überschätzt. Modelle produzieren Code, mit dem sie selbst später weiterarbeiten können, aber keinen guten, menschenlesbaren Code. Ein Modell optimiert auf Funktionieren, nicht auf Verständlichkeit, und das rächt sich spätestens beim nächsten Fehler.
Wenn du produktiver werden willst, ohne die Freude zu verlieren, dann nicht dadurch, dass Agenten den Code schreiben, sondern dadurch, dass sie fast alles andere übernehmen. Der Autor gibt ihnen die langweiligen, gut prüfbaren Aufgaben. Damit dreht er die übliche Reihenfolge um: Nicht der Mensch assistiert der Maschine, sondern die Maschine assistiert dem Menschen.
Planung und Recherche als Buchhaltung mit natürlicher Sprache
Der Autor erinnert daran, dass Computer seit jeher Buchhaltungswerkzeuge waren, und rät, die Modelle genauso einzusetzen. Ein LLM ist für ihn ein Werkzeug, das man in natürlicher Sprache ansprechen kann, um Gesprächsprotokolle in Aufgabenlisten zu verwandeln oder Testergebnisse zu ordnen. Die Grenze bleibt: Entscheidungen trifft der Mensch, das Modell fragt nach. Wenn es eine Frage stellt, die du nicht verstehst, liegt der Fehler beim Kontext, den es nicht geliefert hat.
Bei der Recherche rät der Entwickler zu einer ungewohnten Praxis: Recherchiere selbst, parallel zum Agenten. Verlass dich nicht darauf, dass er dir das entscheidende Wissen präsentiert oder bessere Entscheidungen trifft als du. Der Nutzen liegt nicht im besseren Ergebnis, sondern darin, dass du dir das Nachschlagen sparst. Davon hängt ab, ob du und dein Assistent auf Augenhöhe arbeiten oder ob du ihm hinterherläufst.
Konkret schlägt er vor, Agenten ihre Rechercheergebnisse schriftlich festhalten zu lassen – mit Quellenangaben. Wenn später ein merkwürdiger Vorschlag auf dem Tisch liegt, kannst du nachfragen, auf welche Quelle er sich stützt. In vielen Fällen entdeckt das Modell dabei seinen eigenen Fehler. In den übrigen hast du die Quelle gelesen und kannst selbst entscheiden.
Du bleibst der Programmierer, der Agent liefert die Vorarbeit
Der Autor nennt diesen Punkt die eigentliche Veränderung: Die gängigen Coding-Umgebungen verleiten dazu, zuerst zu planen und dann den Agenten schreiben zu lassen. Er rät, das abzulehnen. Stattdessen soll das Modell den eigenen Code durchsuchen, die aktuelle Aufgabe zusammenfassen, alle Stellen auflisten, die angepasst werden müssen, und auf Fallstricke hinweisen. Den Code schreibst du. Das Ergebnis, so berichtet er, mache mehr Freude als je zuvor, teils sogar mehr als vor der LLM-Ära.
Er beschreibt den Ablauf als agil ohne den Prozesslärm. Du hast immer eine klare Aufgabe, du musst nicht über den Gesamtplan nachdenken, du kannst dich konzentrieren, und du bist schnell fertig, weil gut geplant wurde. Die Arbeit gruppiert sich um deinen Arbeitsstil, nicht um den des Modells. Du gewinnst dabei, du verlierst nichts.
Als Vorteile zählt der Entwickler vier Dinge auf, die sich gegenseitig verstärken. Du tust weiter, was dir Freude macht. Du weißt jederzeit, in welchem Zustand dein Code ist, weil du ihn selbst geschrieben hast. Du erkennst einen schlechten Plan früh, bevor ein Agent dich durch eine Sackgasse führt. Und du übst weiter, bleibst also ein guter Programmierer oder wirst es. Das ergibt einen anderen Begriff von Produktivität als den, den viele Dashboards versprechen.
Wann ein Coding-Agent wirklich sinnvoll ist
Der Autor schließt Agenten nicht aus, er begrenzt sie. Sinnvoll seien Aufräumarbeiten, kleine Aufgaben, Routine und risikoarme Refactorings. Liegen gebliebene FIXMEs, wenn drei besonders interessante Fälle geschrieben und sieben langweilige übrig sind, ein Modulumbau, der gemessen werden soll, oder der Austausch einer ungepflegten Bibliothek – das sind nachvollziehbare Einsätze. Auch das Fertigstellen klarer, risikoarmer Restaufgaben über Nacht hält er für vertretbar.
Gleichzeitig warnt er vor einem Denkfehler, der vielen unterläuft: Wenn du drei interessante Fälle von Hand schreibst und die sieben ähnlichen Fälle generieren lässt, solltest du vielleicht abstrahieren statt kopieren. Möglicherweise brauchst du eine Linse, eine Traversable-Instanz oder eine Funktion höherer Ordnung. Modelle neigen laut dem Beitrag dazu, große Codeblöcke zu wiederholen, statt das Muster zu erkennen. Hier ist der Mensch gefragt, der auf Lesbarkeit zielt.
Dasselbe gilt für die Erforschung des eigenen Codes. Ein Agent kann dir alle Codepfade auflisten, die du berühren musst. Doch die Notwendigkeit selbst könnte ein Hinweis darauf sein, dass die Struktur deines Projekts schlecht organisiert ist. Wer sauber strukturiert, braucht weniger Recherche, ob durch Mensch oder Maschine.
Der Review-Zyklus als automatisches Sicherheitsnetz
Für alle Artefakte, die aus einem Modell kommen, fordert der Autor einen automatischen Prüfzyklus, angelehnt an generative adversarial networks: ein Generator, ein Diskriminator, bessere Ergebnisse als durch den Generator allein. Kein generiertes Ergebnis soll gelesen werden, bevor es eine Review-Instanz passiert hat – das gilt für Code wie für Pläne. Erst wenn ein Prüfagent keine Beanstandungen mehr hat, ist das Ergebnis für menschliche Augen geeignet.
Der Entwickler wendet diesen Zyklus auch auf seinen eigenen Code an. Häufig findet die Prüfung nur Kleinigkeiten oder drängt auf mehr Dokumentation, aber immer wieder entdeckt sie einen echten Fehler oder eine Auslassung. Wer keine Lust hat, die Kritik einer Maschine an seinem Werk zu lesen, kann kleinere Befunde auch selbst beheben lassen. So bleibt die Aufmerksamkeit dort, wo sie hingehört.
Was das für den Arbeitsalltag bedeutet
Der Beitrag verspricht keine Wunder und keine Erlösung, er beschreibt einen Umgang. Programmieren mit großen Sprachmodellen kann Spaß machen, wenn man die Rollen klar verteilt: Das Modell plant, recherchiert, erinnert, prüft und erledigt Routine – der Mensch denkt, entscheidet und schreibt. Damit vermeidest du zwei Extreme, die der Autor fürchtet: den KI-Burnout durch endloses Prüfen fremden Codes und den stillen Verlust der eigenen Fähigkeiten.
Der Text kommt aus der Haskell-Welt, wo die Sprache selbst Teil der Motivation ist. Die Haltung lässt sich aber auf jede Umgebung übertragen, in der Code-Qualität mehr sein soll als ein Häkchen. Wer weiter selbst schreibt und KI nicht komplett vermeidet, wird nicht unbedingt der produktivste Entwickler im Raum sein. Aber er wird der sein, der in zwei Jahren noch weiß, wie seine Programme aussehen – und warum sie so aussehen.
Eine praktische Empfehlung zum Ausprobieren: Nimm dir eine Woche lang vor, den Code selbst zu tippen und alle Vor- und Nacharbeit an das Modell abzugeben. Vielleicht kommt ein Teil der Freude zurück, den du in den letzten Monaten verloren hast. Und wenn du merkst, dass dir das Generieren lieber ist, kannst du dich bewusst dagegen entscheiden – nur eben nicht mehr aus Gewohnheit.
Quelle: discourse.haskell.org
