Ich codiere seit einigen Monaten von Hand
(miguelconner.substack.com)- Ein Bericht eines Entwicklers, der zu einer Zeit, in der AI-Coding-Agenten alltäglich geworden sind, an einem dreimonatigen Retreat teilnimmt und dort bewusst ohne LLM von Hand codiert
- In Woche 6 im Recurse Center in Brooklyn baut er ein LLM erstmals von Grund auf selbst auf, festigt seine Python-Kenntnisse und vertieft zugleich sein Verständnis für die verschiedenen Abstraktionsebenen eines Computers
- Coding-Agenten ermöglichen schnelle Iteration und Deployment, doch beim direkten Schreiben von Code geschehen zwei Dinge gleichzeitig: man drückt aus, was man will, und lernt dabei die Codebasis kennen
- In Anlehnung an Cal Newports Metapher „Schreiben ist wie Sport“ wird die mentale Anstrengung beim Bauen von Code als ein Kernelement des Handwerks beschrieben
- Ausgehend von der Beobachtung, dass gerade Ingenieure mit tiefem Wissen AI-Tools besonders gut einsetzen, wird betont: Auch im AI-Zeitalter entsteht Hebelwirkung durch starke Grundlagen
LLMs und die Erfahrung des Codierens
- In den vergangenen zwei Jahren wurden bei Aily Labs in Barcelona AI-Agenten gebaut
- Anfang 2024 entstand ein interner Websuch-Agent, rund 6 Monate vor Anthropics Text „Building Effective AI Agents“ und etwa 1 Jahr vor OpenAIs DeepResearch
- Früher Nutzer von Cursor, außerdem früh beteiligt am Aufbau von Wissensgraphen mit LLMs
- Leitung eines wöchentlichen Journal Clubs mit Vorträgen zu Papers über den Aufbau von Open-Source-LLMs
- Behandelt wurden unter anderem Papers zu DeepSeek R1, Ai2s Olmo 3 und Metas Llama 3
- Das half dabei, die Trade-offs zwischen internem Modelltraining und Workflows auf Basis geschlossener SOTA-Modelle zu verstehen
- Seit der ersten Nutzung von LLMs im Jahr 2023 besteht durchgehend großes Interesse an ihrer Funktionsweise und ihren Anwendungen
Direktes Codieren als Kernelement des Handwerks
- Erkenntnisse aus dem gleichzeitigen Lernen über LLMs und ihrem Einsatz beim Codieren
- Wenn man Code „von Hand“ schreibt, erledigt man zwei Dinge zugleich: das Gewollte formulieren und dabei die Codebasis lernen
- Mit Coding-Agenten bekommt man exakt das, was im Prompt spezifiziert wurde; ist das Ziel unklar, trifft der Agent viele Annahmen (assumptions) stellvertretend
- Dadurch lernt man weniger und versteht die Codebasis schlechter
- Gleichzeitig ermöglichen Coding-Agenten schnelle Iteration und zuverlässiges Deployment von Software und können als hervorragende Tutoren dienen
- Zitat aus einer NYT-Kolumne von Cal Newport
- „Dein Schreiben muss dein eigenes sein. Die Anspannung, die nötig ist, um eine klare Notiz oder einen Bericht zu verfassen, ist die mentale Entsprechung zum Training eines Athleten im Fitnessstudio — keine lästige Mühe, die man beseitigen sollte, sondern ein Kernelement des Handwerks.“
- Diese Metapher wird als ebenso passend für das Schreiben von Code betrachtet
- Die hervorragenden Programmierer bei Aily waren meist auch besonders gut im Umgang mit AI, und tiefes Wissen verschafft Hebelwirkung beim Einsatz von AI-Tools
Was ist ein Code-Retreat?
- Das Recurse Center (RC) ist ein selbstgesteuertes Vollzeit-Programmier-Retreat in Brooklyn
- Retreat: „eine Zeit, in der man sich kurz aus dem Alltag zurückzieht, um sich auf eine bestimmte Tätigkeit zu konzentrieren“
- Teilnahme nach Bewerbung und Coding-Interview; anschließend 6 oder 12 Wochen voller Fokus auf Programmieren
- Kennzeichnend ist eine kohortenbasierte kollaborative Umgebung mit Menschen unterschiedlichster Spezialisierungen, darunter viele Programmierer mit jahrzehntelanger Erfahrung
- Das Programm ist kostenlos
- Ziele im Recurse Center
-
Ein LLM von Grund auf lernen
- Ziel ist es, inklusive Pretraining und Post-Training selbst einen Transformer zu schreiben, statt eine bestehende Codebasis zu forken
-
Python besser von Hand schreiben
- Trotz mehrjähriger Arbeit mit Python gibt es noch viel zu lernen; Ziel ist es, Dokumentation und LLM-Fragen zu minimieren und mehr Intuition für die Struktur von Projekten zu entwickeln
-
Computer tiefer verstehen
- Computer werden als hochkomplexe Maschinen verstanden, die auf vielen Abstraktionsebenen arbeiten
- Ohne formale Computer-Science-Ausbildung soll ein besseres mentales Modell dafür entstehen, wie diese Ebenen zusammenspielen
- Es gibt noch keinen sehr konkreten Plan, aber RC erscheint als der richtige Ort dafür
-
Fortschritt
-
1. Ein LLM von Grund auf trainieren
- Die erste Aufgabe aus Stanfords Kurs CS336: Language Modeling from Scratch wurde ohne LLM-Coding-Hilfe abgeschlossen
- Die rund 50-seitige Aufgabe wurde gemeinsam mit einem anderen Recurser bearbeitet
- Geschrieben wurden ein optimierter tokenizer in Python und eine auf PyTorch basierende GPT-2-artige Architektur
- Nach vielen Ablation-Tests zur Hyperparameter-Abstimmung auf dem Tiny Stories-Datensatz wurde das Ganze auf rund 9 Milliarden Tokens aus OpenWebText angewendet
- Ein Learning-Rate-Sweep für ein selbst geschriebenes Modell mit 17 Mio. Parametern zeigte: hohe Learning Rates führen zu Instabilität. Training auf einer A100 dauerte etwa 1 Stunde
- Nächste Schritte
- Die restlichen Aufgaben aus CS336: Optimierung von Sprachmodellen, Schätzung/Berechnung von Scaling Laws, Umwandlung von Rohtext in Pretraining-Daten und Post-Training des Modells
- Mit der zweiten Aufgabe zu GPU-Profiling und der Implementierung von FlashAttention2 in Triton wurde bereits begonnen
- Am Ende soll ein selbst post-trainiertes Modell stehen
- Die erste Aufgabe aus Stanfords Kurs CS336: Language Modeling from Scratch wurde ohne LLM-Coding-Hilfe abgeschlossen
-
2. Python-Fähigkeiten verbessern
- Geübt wurde durch das Schreiben vieler kleiner Agenten und neuronaler Netze in Python und PyTorch
- Am hilfreichsten war Pair Programming mit jemandem mit mehr als 10 Jahren Python-Erfahrung
- Ein Pair-Partner öffnet, wenn ihm Syntax oder Verhalten nicht mehr einfällt, sofort das Terminal und tippt ein kurzes Beispiel ein, um das Verhalten in weniger als einer Minute zu prüfen
- Dieser ins Muskelgedächtnis übergegangene Prozess, Probleme ohne Google-Suche oder LLM-Anfrage zu lösen, half enorm dabei, Blockaden aufzulösen
- Dieser Weg soll mit Pair Programming bei Problemen wie Advent of Code fortgesetzt werden
- Die Zusammenarbeit in Echtzeit ist anfangs angespannt, beschleunigt das Wachstum aber spürbar
-
3. Das Verständnis von Computern vertiefen
- Auf einem Apple IIe von 1983 wurde fizzbuzz in BASIC geschrieben
- Der manuelle Prozess von Codebearbeitung und Ausführung war direkt erfahrbar und machte Unterschiede wie Ähnlichkeiten zwischen damaligen und heutigen Computern deutlich
- Teilnahme an CTF Fridays zur Verbesserung von Unix-/Terminal-Skills
- Mit Terminal-basierten „war games“-Challenges wie Bandit wurden Passwörter gesammelt und Level aufgestiegen
- Dadurch ist nun besser nachvollziehbar, was Claude Code auf dem eigenen Rechner ausführen will
- Ein Single-Layer-Perceptron in Vim von Hand codiert
- Anfangs sehr mühsam, später deutlich besser durch Tipps anderer Recurser und gelernte Shortcuts
- Besonders nützlich, wenn bei Trainingsjobs auf Cloud-GPUs kurz vor Schluss noch Dateien angepasst werden müssen
- Teilnahme an einem Clojure-Workshop (geleitet von jemandem mit mehr als 15 Jahren Erfahrung)
- Wegen geringer Erfahrung mit funktionalen Sprachen war schon das Thema an sich spannend
- Nach einer kurzen Einführung lief der Workshop als Mob Programming, bei dem die Teilnehmenden reihum 1–2 Minuten lang zur Lösung beitrugen
- Teilnahme an den wöchentlichen 5-Minuten-Tech-Talks
- Themen waren unter anderem „Running Rust Code“, „GPUs for Dummies“, „Typesafe APIs for Type B Personalities“ und „Some Useless Agents“ (eigener Vortrag)
- Bisher wurden zwei eigene Vorträge gehalten (einfache Agentenarchitekturen, effiziente Skalierung von MCP-Tools); diese Woche folgt ein Talk über Methoden zur GPU-Optimierung
- Schon das Zuhören bei den Projekten und Karrierewegen anderer Teilnehmender erweitert das Verständnis dafür, welche Problemräume Computer lösen können
- Auf einem Apple IIe von 1983 wurde fizzbuzz in BASIC geschrieben
Die verbleibenden 6 Wochen
- Nach dem Retreat geht es mit neuen Technologien und Fähigkeiten zurück zur Produktionsbereitstellung von Agenten und zur Durchführung von Evals
- Es besteht die Sorge, in den verbleibenden 6 Wochen nicht alle Punkte der Liste abschließen zu können
- Doch der wahre Wert von RC liegt nicht darin, alles abzuhaken, sondern überhaupt Zeit ins Codieren zu investieren
6 Kommentare
Den Code für die Arbeit überlasse ich komplett den AI-Agenten und sorge dafür, dass sie möglichst lange in der Schleife laufen.
An privaten Hobbyprojekten arbeite ich dagegen direkt selbst, ohne AI-Assistenten oder AI-Autovervollständigung zu verwenden (...)
Das erinnert mich an einen Witz, den ich vor Kurzem gesehen habe
Ich habe den Code erst per Hand geschrieben und dann die AI gebeten, ihn zu verbessern
Phase 1: Müllcode löschen
stand da, hahaha
Ich habe die AI-Funktionen in VSCode deaktiviert und nutze Claude Code; das ist definitiv angenehmer.
Ich bin wegen AI von vim zu VS Code gewechselt,
habe aber das Gefühl gehabt, die Freude am Entwickeln verloren zu haben, und bin deshalb zu vim zurückgekehrt.
Ich nutze AI als Assistant, und ich habe das Gefühl, die Freude am Entwickeln dadurch definitiv wiedergefunden zu haben.
Ich bin eher nach der Nutzung von AI Agents zu
nvimgewechselt.Es ist viel angenehmer, den Sourcecode in
nvimanzusehen..Hacker-News-Kommentare
Ich unterrichte dieses Semester 18-jährige Studierende in 6502-Assembly auf einem emulierten Apple II Plus.
Die Studierenden hatten in modernen Umgebungen bereits Python, Datenstrukturen und Objektorientierung gelernt.
In insgesamt etwa 10 Stunden Unterricht und Praxis haben sie Register, Befehle, Adressierungsarten, Memory Maps und Apple-Monitor-Routinen kennengelernt und anschließend gemeinsam ein Zeichenprogramm, einen springenden Ball, selbst erstellte Sprites und sogar einfache Kollisionserkennung mit 40x40-Niedrigauflösungsgrafik umgesetzt.
Als Aufgabe sollten sie einfache Spiele wie Snake oder Tetris selbst bauen, vorführen und danach erklären, wie sie funktionieren.
Anfangs hassten sie den Zeileneditor, aber bald begannen sie, vor dem Schreiben des Codes erst zu planen und zu diskutieren.
Eine Gewohnheit, die ich in früheren Kursen immer betont hatte, aber die nie richtig greifen wollte, stellte sich ohne mächtige Werkzeuge plötzlich ganz natürlich ein.
Später sagten die Studierenden sogar, sie hätten den Code so sehr im Kopf, dass sie nicht mehr alles auf dem Bildschirm sehen müssten.
Natürlich werden sie am Ende wieder zu modernen Tools zurückkehren, aber ich glaube trotzdem, dass diese Erfahrung sehr wertvoll war.
Der größte Grund ist, dass man Typen eigentlich ständig mitdenken muss, Python diesen Punkt aber eher verwischt.
Auch Einrückungen sind mal zwingend und mal nicht; wer daran gewöhnt ist, empfindet das als selbstverständlich, für Anfänger kann es aber verwirrend sein.
Durch die Low-Level-Umgebung und die eingeschränkten Werkzeuge habe ich mir angewöhnt, vor dem Schreiben von Code erst nachzudenken.
Bei Greenfield-Arbeit hole ich bis heute zuerst Stift und kariertes Papier heraus, zeichne mögliche Funktionen oder Klassen als lockeren Graphen und verbinde sie mit Pfeilen.
Wenn man das übertreibt, wird daraus natürlich nur eine andere Form von Waterfall-Planung, deshalb ist Maßhalten wichtig.
Schon ein paar Stunden Vorabüberlegungen zur Struktur können die eigentliche Coding-Zeit aber massiv verkürzen.
Das tatsächliche Ergebnis sah fast nie genau wie der Entwurf auf Papier aus, aber allein der Prozess, erst das große Ganze zu durchdenken, machte mich produktiver.
Wenn man im Editor scaffoldet, rutscht man schnell in die eigentliche Implementierung hinein; auf Papier muss man ohnehin später alles noch einmal tippen, also kann man sich von Nebengedanken wie Variablennamen oder Methodenauswahl lösen.
Auch bei ein paar Fällen von vibe coding war diese Methode besonders nützlich, weil ich dadurch viel konkretere und fokussiertere Prompts formulieren konnte.
Aber an der Stelle, dass sich der Code im Kopf der Studierenden festgesetzt hat, habe ich meine Meinung geändert.
Das erinnerte mich daran, dass Zed Shaw einmal etwas Ähnliches sagte: Ohne IDE geschriebener Code wirke seltsamerweise oft besser.
In einem ähnlichen Zusammenhang habe ich mit Büchern wie "From Nand to Tetris" gelernt, und das hat mir enorm geholfen zu verstehen, wie Computer, Assembler und Compiler funktionieren.
Wenn er ein Problem bekam, fing er nicht sofort an zu tippen, sondern dachte erst nach, kritzelte etwas auf Papier, ging sogar spazieren und setzte sich erst danach an den Rechner.
Dann tippte er den Code fast in einem Zug ein und kompilierte am Ende nur noch — und erstaunlicherweise funktionierte es meist.
Sogar Tippfehler waren selten.
Dadurch wurde mir sehr deutlich, wie wichtig die Fähigkeit ist, sich den Problemraum und das Programm zuerst im Kopf aufzubauen und daraus zu schlussfolgern.
Dann ist klarer, welches Ergebnis man erwartet, und man merkt auch schneller, wenn etwas Unerwartetes passiert.
Von oben hieß es immer, das sei zu schwer und werde heute ohnehin von niemandem mehr benutzt, also wurde das Fach gestrichen.
Trotzdem habe ich es heimlich in andere Veranstaltungen wie Systemprogrammierung, Computersprachen oder Rechnerarchitektur eingebaut.
Als ich aufwuchs, war Assembler Teil des Curriculums und überbrückte die Lücke zwischen Hochsprachen wie C/C++ und der Hardware.
Dadurch verstand man auch, warum bestimmte Sprachfeatures überhaupt existieren und wie viele Sprachelemente tatsächlich arbeiten.
Vor allem war es, wie in den Kommentaren oben beschrieben, eine großartige Übung darin, dem CPU Zeile für Zeile im Denken zu folgen.
Den Kampf um ein eigenes Fach habe ich oft verloren, aber ich hoffe zumindest, bei den Studierenden ein paar Samen gesät zu haben.
Ich glaube, jeder sollte wenigstens einmal eine Art von Assembler lernen.
Ich wünschte, es wäre mehr in AI-Autocomplete-Workflows investiert worden.
Das war ein ziemlich guter Mittelweg.
Selbst das, was man heute die alte Methode nennt, ist im größeren Bild gegenüber agentischen Workflows aus meiner Sicht immer noch ziemlich konkurrenzfähig.
Wenn man selbst tippt, behält man das Wissen über die Codebase viel besser, und durch das aktive Erinnern und Überprüfen versteht man die Konzepte tiefer.
Den Code schreibe ich selbst, und den Agenten lasse ich das Code-Review machen.
So behalte ich mein Coding-Gefühl und mein Verständnis der Codebase und fange vor dem Commit trotzdem noch gut Bugs ab.
Das frühe Cursor war wirklich beeindruckend, aber danach hatte ich das Gefühl, dass Autocomplete fast stagniert, und selbst das aktuelle Cursor bewegt sich wie die anderen Tools immer stärker in Richtung Agenten.
Ich hoffe, dass Workflows in der Nähe von Autocomplete wieder Auftrieb bekommen, wenn Diffusion-Modelle irgendwann mehr Schwung entwickeln.
Das Mercury-Modell von Inception Labs fühlt sich wegen seiner nahezu sofortigen Antworten immer noch fast magisch an.
Leider fehlt noch die Raffinesse auf Cursor-Niveau und die tiefe Editor-Integration.
Und Diffusion-Ansätze scheinen sich eigentlich hervorragend für lokale Nutzung zu eignen, deshalb finde ich es schade, dass es fast keine wirklich bedeutenden Open-Weight-Modelle gibt.
Wenn ich den langweiligen Glue Code selbst schreibe, entsteht in meinem Kopf eine Karte des Projekts.
Wenn ein Agent dagegen zu viel Struktur erzeugt, läuft zwar zunächst alles, aber wenn ich eine Woche später eine kleine Änderung machen will, muss ich erst wieder suchen, wo was überhaupt gelandet ist.
Es gab Gründe, warum alle so schnell zu etwas anderem gewechselt sind; am Ende war es einfach kein nützliches Interface.
Wenn man einmal das Flugzeug genommen hat, ist es wirklich schwer, wieder zurückzugehen.
Dieser Titel wirkt auf mich wie einer der deprimierendsten Titel, die ich hier je gesehen habe.
Er könnte bedeuten, dass es deprimierend ist, dass Hand-Coding inzwischen so ungewöhnlich geworden ist, dass man darüber einen Blogpost schreibt; oder dass ein AI-Maximalist sich über menschliches Programmieren lustig macht.
Wenn man sich die Beitragshistorie ansieht, scheint eher die erste Deutung zu passen.
Das erinnert mich ein bisschen an Schlagwörter wie wild swimming — als wären wir wirklich zu weit gegangen.
Es wirkt tatsächlich so, als hätten wir den Hai übersprungen.
Trotzdem fand ich das einen wirklich eindrucksvollen Beitrag.
Danach fand ich es wirklich absurd.
Bald stellt man sich schon halb im Scherz eine Welt vor, in der man in die Psychiatrie eingewiesen wird, nur weil man von Hand-Coding gesprochen hat.
Die ersten Jahre meiner Karriere habe ich auf SPARC-basiertem Solaris mit vi verbracht, hauptsächlich beim Schreiben von Perl-Code — und zwar vi, nicht einmal vim.
Das O’Reilly Perl Cookbook war fast mein einziger Wegweiser, es gab nicht viele Internetforen und Suchmaschinen waren noch primitiv, also war es viel schwieriger, bei Problemen Hilfe zu bekommen.
Dafür hat mich diese Umgebung gezwungen, Perl-Syntax, Terminal-Tools und vor allem vi-Tastenkombinationen sehr tief zu verinnerlichen.
Es gab weder Syntax-Highlighting noch IntelliSense, und gerade deshalb ist viel stärker hängen geblieben.
Rückblickend gab es damals viel weniger Ablenkung und Rauschen.
Natürlich lag das vielleicht auch daran, dass ich noch am Anfang meiner Laufbahn stand und die Erwartungen niedriger waren, aber heute wirkt alles übermäßig geschichtet und kompliziert.
Das war eine ziemlich reine Erfahrung mit sofortiger Belohnung, schneller Entwicklung und ohne unnötige Schichten, und genau das hat mich auf diesen Weg gebracht.
Ironischerweise bringt agentic coding mir einen Teil dieser Aufregung zurück.
Ich muss mich nicht mehr selbst mit allen komplexen Enterprise-Aspekten herumschlagen, und dadurch ist die Verbindung zwischen Gedanke und Ergebnis wieder direkter geworden.
Es ist wirklich erstaunlich, wie sich die Branche verändert hat.
Noch vor gerade einmal zwei Jahren wäre das etwas gewesen, das fast jeder Entwickler gesagt hätte; heute wirkt jemand, der von Hand codet, schon fast wie eine bedrohte Spezies.
Gerade bei neuen Technologien und Sprachen, mit denen ich im letzten Jahr gearbeitet habe, habe ich das Gefühl, dass ich zwar leicht Ergebnisse erziele, mir aber gleichzeitig Wissensschulden auflade.
Ich frage mich ernsthaft, wie die nächste Generation von Software Engineers noch ein tiefes Verständnis dafür entwickeln soll — oder ob sie es vielleicht gar nicht mehr entwickelt.
Eine Generation davor wäre das vergleichbar gewesen mit Programmieren ohne IDE, und selbst das war in der Praxis schon selten.
Ich bin generell ziemlich pro AI, besonders bei GenAI, verbringe aber trotzdem noch viel Zeit mit manuellem Coden.
Höchstens habe ich Copilot-Unterstützung eingeschaltet.
Manchmal arbeite ich mit Tools wie SpecKit + OpenCode an spec-driven development, manchmal vibe-code ich einfach.
Trotzdem bin ich noch nicht bereit, meine Verantwortung, den Code zu verstehen, abzugeben oder die Fähigkeit aufzugeben, ihn selbst zu schreiben.
Deshalb habe ich mir kürzlich wieder ein paar Bücher zu LISP und Java gekauft, davor auch eins zu Forth.
Zumindest auf absehbare Zeit, vielleicht sogar für immer, habe ich nicht vor, das eigentliche Coden komplett aufzugeben.
Entscheidend ist nicht die Implementierung, sondern das Verständnis des Verhaltens.
Diese Verifikation leisten automatisierte Unit-Tests, Integrationstests und Lasttests.
Jemand hielt es für naiv, dass ich gesagt habe, ich hätte eine interne Web-Admin-Seite per vibe coding gebaut und dabei keine einzige Codezeile gelesen, sei aber trotzdem sicher, dass sie die Sicherheitsanforderungen erfüllt.
Aber die Anforderungen lauteten, dass jede Person mit Zugriff auf die Seite alles tun können muss; der Zugriff war durch Amazon-Cognito-Credentials geschützt, und die dafür zuständige Lambda-Funktion hatte eine Rolle mit Minimalrechten.
Wenn diese beiden Invarianten gebrochen worden wären, dann hätte Claude wohl eine massive AWS-Schwachstelle entdeckt.
Ich nutze AI maximal, um viel zu bauen, nehme mir aber gleichzeitig immer die Zeit zu prüfen, ob der von AI erzeugte Code meinen Maßstab für kognitive Last besteht.
Dazu gehören auch Überarbeitung und Dokumentation des Codes, und auf Basis dieses AGENTS.md-Beispiels bekomme ich vieles recht mühelos hin.
Trotzdem merke ich, wenn es in eine seltsame Richtung abdriftet, und dann übernehme ich wieder die Steuerung.
Und wenn die Credits aufgebraucht sind, bin ich wirklich dran.
Der Code ist dann meist schon sauber organisiert, die Abstraktionen sind sinnvoll und die Kommentare hilfreich, sodass sich darauf gut organisches menschliches Coden aufbauen lässt.
Inzwischen bitte ich die AI sogar darum, die Bühne schon einmal vorzubereiten, je näher ich ans Limit komme.
Früher war ich frustriert, wenn die Credits ausgingen und ich Code zurückbekam, den ich erst studieren musste, um ihn zu verstehen; heute freue ich mich fast schon auf die nächste brain time hand-out.
Es klingt vielleicht seltsam, aber für mich fühlt sich das tatsächlich wie eine Form von Teamwork an.
Ich könnte auch einfach einen teureren Tarif buchen, aber ich möchte mein Gehirn weiter aktiv halten.
Dem Grundsatz stimme ich zu, aber zumindest Claude kopiert Logik für mein Gefühl viel zu häufig, sodass eher ein Gegensteuern in die andere Richtung nötig ist.
Wenn ein LLM den Code für mich schreibt, wirkt dieser Code auf mich fast wie eine Blackbox, an die ich kaum herankomme.
Wenn er funktioniert, benutze ich ihn zwar, aber ich vertraue ihm nicht wirklich, und wenn er kaputtgeht, ist es einfach frustrierend.
Am besten funktioniert für mich deshalb, wenn ich immer selbst am Steuer sitze und das LLM die Rolle eines Assistenten übernimmt: Fragen beantworten, Ideen mit mir brainstormen oder Konzepte, die ich bereits verstanden habe, in die Syntax einer bestimmten Sprache übersetzen.
Ehrlich gesagt fiel mir schon immer weniger das konzeptionelle Verständnis schwer als vielmehr das Übertragen in Syntax.
Ich denke auch schon länger darüber nach, Agenten einen Teil zu überlassen, aber bestimmte Aufgaben bewusst bei mir zu behalten, damit mein Gehirn weiterarbeiten muss.
Vielleicht sollte ich tatsächlich einmal ein Skill oder Hook für Claude Code bauen.
Drei Monate lang selbstgesteuert auf eine tiefe Lernreise gehen zu können, klingt wirklich großartig.
Solche tiefen technischen Kenntnisse dürften auch langfristig wertvoll sein, und ich bin noch nicht sicher, ob dieser Wandel wirklich dieselbe Art von Abstraktion ist wie der Übergang von Assembler zu C.
Heutzutage wird der Großteil meines Codes von LLMs erzeugt, aber am Ende des Tages empfinde ich ehrlich gesagt nur wenig Freude, Erfüllung oder Zufriedenheit dabei.
Gleichzeitig habe ich jedoch erkannt, dass nur etwa 5–10 % dessen, was ich am Coden wirklich mag, im Zentrum liegt und der Rest eher langweilige, halbmechanische Arbeit war, die diesen interessanten Kern gestützt hat.
Im Maßstab der gesamten Menschheitsgeschichte ist die Zeit, in der wir überhaupt mit Computern arbeiten, nur ein sehr kurzer Moment, und ich frage mich, wie das Zeitalter des Hand-Codings in 100 Jahren aussehen wird.
Vielleicht bleibt es nur eine Fußnote oder wird einfach mit allen Epochen zusammengefasst, die der Selbstautomatisierung der Maschinen vorausgingen.
Früher schrieb man direkt in Assembler, später wechselte man zu kompilierten Sprachen wie C, und Assembler blieb als nützliche, aber spezialisierte Nischenfähigkeit bestehen.
So wie wir den Compiler heute den Code erzeugen lassen, ohne uns seinen internen Output meist anzusehen, könnten künftig große Teile der Entwicklung auf die LLM-Abstraktionsschicht wechseln.
Die Kernkompetenzen könnten sich dann hin zu guten Prompts, Context-Window-Management sowie dem Betrieb von Agenten und Memory verschieben.
Einige Entwickler werden vermutlich weiterhin LLM-generierten Code lesen und Probleme darin finden können, aber die meisten vielleicht nicht.
Ich habe dazu selbst gemischte Gefühle.
Seit dem Erscheinen von ChatGPT bis noch vor ein paar Monaten war ich LLM-Programmierung gegenüber ziemlich skeptisch; selbst neue Modelle wirkten auf mich eher wie Variationen derselben minderwertigen Ausgabe.
In letzter Zeit scheint es jedoch, als hätten die Modelle einen gewissen Schwellenwert überschritten, und obwohl ich Claude weiterhin vorsichtig einsetze, hat es mir tatsächlich geholfen, die Zeit für Feature-Implementierungen deutlich zu reduzieren oder Bugs allein anhand von Logs zu lokalisieren.
Den übertriebenen Behauptungen, Coding sei gelöst, stimme ich zwar immer noch nicht zu, aber ich glaube schon, dass wir eine der größten Veränderungen seit dem Aufkommen höherer Programmiersprachen erleben.
Ich habe als halben Kompromiss angefangen, Zed zu benutzen.
Künftig will ich AI eher für Planung und Vorschläge für Schritte nutzen als für die eigentliche Implementierung.
In letzter Zeit sieht man sogar Menschen ohne technischen Hintergrund, die mit Claude Apps bauen, und wenn ich Openclaw und ähnliche agentenfixierte Strömungen anschaue, scheint es mir nicht besonders praktisch, den Weg der AI-Übersteigerung einfach weiterzugehen.
Ich wurde in anderen Lebensbereichen immer danach beurteilt, dass ich mich auch um die inneren Details kümmere und neue Probleme selbst direkt anpacke und löse.
Ich frage mich, wie sich der Markt daran anpassen wird und wie Menschen künftig ihre Fähigkeit, mit solchen Nuancen umzugehen, vermitteln und nachweisen können.
Als ich auf der Website des Recurse Center den Satz sah, dass es „keine Lehrkräfte und kein festes Curriculum gibt und nur volles Engagement während des Retreats verlangt wird“, wurde ich neugierig.
Ich wollte wissen, wie Menschen mit Vollzeitjob normalerweise an so einem Coding-Retreat teilnehmen.
Ich fragte mich auch, ob das hauptsächlich ein Programm für Berufseinsteiger oder für Menschen in Übergangsphasen zwischen zwei Jobs ist.
Im eigentlichen Artikel ging es darum, was jemand im Retreat gebaut hat, aber ehrlich gesagt bekam ich eher Lust, selbst einmal hinzugehen.
Viele kündigen eigens für RC oder bewerben sich nach einem Jobverlust.
Auch formelle Sabbaticals, Garden Leave sowie die Sommerferien von Studierenden und Promovierenden werden oft genutzt.
Es kommen auch nicht wenige Freelancer, unabhängige Auftragnehmer und Rentner.
Manche kommen, um in die Branche einzusteigen, aber viele Teilnehmende haben bereits als Programmierer gearbeitet.
Das Alter der Teilnehmenden reicht von 12 Jahren bis in die frühen 70er, der Schwerpunkt liegt aber zwischen 20 und 40.
Mehr Details zu den Teilnehmenden findest du auf der Vorstellungsseite des Recurse Center.
Andernfalls ist es realistisch eigentlich nur, wenn man ein Sabbatical von etwa sechs Wochen nehmen kann und danach an den aktuellen Arbeitsplatz zurückkehrt.