Nachdem der Autor sich mit dem Buch The AWK Programming Language beschäftigt hatte, wollte er das Advent of Code 2024 lösen – zunächst mit AWK. Doch bereits bei Teil 2, einem kürzesten-Pfad-Problem mit einem Twist, stieß er auf die Grenzen der klassischen AWK: fehlende funktionale Programmierkonzepte wie immutabile Datenstrukturen, lexikalische Bindung, erste-Klasse-Funktionen und robuste Array-Verarbeitung. Trotz seiner Erfahrung mit funktionalen Sprachen (FP-pilled) fühlte er sich durch AWKs dynamische Scope-Regeln, den fehlenden Zugriff auf Arrays als Rückgabewerte und die komplizierte Handhabung von Zuständen blockiert. Die Implementierung seiner bevorzugten funktionale BFS-Strategie wurde schnell unübersichtlich und zeitraubend. Daraus entstand eine Vision: Was wäre, wenn AWK modernisiert würde? Der Autor träumte von einer „funktionalen AWK“-Variante – FAWK – mit ersten-Klasse-Arrays (inkl. Literale, verschachtelte Strukturen, Assoziativarrays), Lambda-Ausdrücken, lexikalischer Scope-Bindung, expliziten Globalen und sogar Pipelines wie in funktionalem Code (z. B. |> map(...) |> filter(...)). Diese Ideen wurden nicht nur theoretisch diskutiert, sondern konkretisiert – mit Beispielcode, der in einer modernen Sprache funktionieren könnte. Anstatt selbst einen Interpreter zu bauen, nutzte der Autor den Cursor Agent mit Sonnet 4.5, um einen vollständigen AWK-ähnlichen Interpreter in Python zu erstellen. Überraschenderweise gelang dies innerhalb weniger Chat-Sitzungen: Der LLM lieferte einen funktionsfähigen Interpreter, der die erwähnten Features korrekt umsetzte – inklusive komplexer Arrays, Funktionen als Werte, Pipeline-Syntax und sogar Rückwärtskompatibilität zu GAWK. Auch schwierige Aufgaben wie die Implementierung von Multi-Line-Records oder die zweifache Rolle von print als Anweisung und Ausdruck wurden korrekt umgesetzt. Nur bei der exakten Berechnung von Gleitkommazahlen ohne externe Bibliotheken (z. B. mpmath) scheiterte der LLM zunächst – doch nach einem Hinweis, die Bibliothek hinzuzufügen, wurde die Lösung sofort bereitgestellt. Der Erfolg zeigte, dass LLMs heute in der Lage sind, komplexe, strukturierte Softwareprojekte – inklusive Tests und Dokumentation – selbstständig zu entwerfen und zu implementieren. Der Autor zieht daraus die Konsequenz: Seine Vorstellung von den Grenzen von LLMs hat sich grundlegend verändert. Was früher als „vibecoding“ galt, ist nun eine praktikable Entwicklungsmethode. Allerdings gibt es auch Risiken: Der Code ist für den Autor eine Black Box – er versteht ihn nicht tiefgehend, was künftige Anpassungen erschweren könnte. Zudem ist die Leistung von FAWK (Python-basiert) vermutlich suboptimal, was aber für den geplanten Einsatz – schnelle, einmalige Skripte für Advent of Code – akzeptabel ist. Die Möglichkeit, den Code in Rust umzuschreiben, wird als realistisch gesehen. Fazit: FAWK ist ein eindrucksvolles Beispiel dafür, wie LLMs die Grenzen der Softwareentwicklung neu definieren. Es eröffnet neue Wege, Sprachentwürfe zu prototypen – aber auch die Notwendigkeit, zwischen Nutzung und Verständnis zu balancieren. Für Entwickler, die bisher aufgrund fehlender Motivation oder Komplexität Projekte aufgegeben haben (wie z. B. ein Hindley-Milner-System), könnte dies eine neue Chance sein – vorausgesetzt, man bleibt aktiv im Code, liest, versteht und prüft, statt nur zu vertrauen.