Nach einigen Monaten des Codierens mit LLMs habe ich beschlossen, wieder mein eigenes Gehirn zu benutzen
(albertofortin.com)- Beim Aufbau einer Infrastruktur mit leistungsstarken LLMs zeigten sich erhebliche Probleme bei Codequalität und Wartbarkeit
- Wegen der Ineffizienz von AI und inkonsistenter Ergebnisse wurde mir klar, dass ich Code wieder selbst verstehen, recherchieren und meine eigenen Fähigkeiten ausbauen muss
- Das Ziel, ein Projekt schnell abzuschließen, führte vielmehr zu chaotischer Code-Struktur, Duplikaten und Inkonsistenzen
- Inzwischen nutze ich AI nur noch eingeschränkt als Hilfsmittel für einfache Wiederholungsaufgaben oder Code-Konvertierung
- Da der Einsatz von AI zu einem Nachlassen des Coding-Gefühls und der Problemlösungsfähigkeit führen kann, setze ich bewusst wieder auf das eigene Denken
Einleitung: Der Versuch, eine Infrastruktur mit LLMs aufzubauen
- Die bestehende PHP+MySQL-Infrastruktur war an ihre Grenzen gekommen, daher wurde der Bedarf an einer neuen Infrastruktur erkannt
- Entscheidung für Go und Clickhouse, anschließend wurden gemeinsam mit AI Infrastrukturdesign und Planung ausgearbeitet
- Mit LLMs wie Claude wurden Best Practices und Architektur besprochen und daraus ein detaillierter Plan entwickelt
- Die Code-Entwicklung wurde stark auf Geschwindigkeit ausgerichtet, mit dem Ziel, Funktionen schnell fertigzustellen und früh zu releasen
Entwicklungsprozess und auftretende Probleme
- Mit Tools wie Cursor schrieb die AI den Code, während ich mich vor allem auf Builds und Tests konzentrierte
- Auch wenn die Codebasis nicht sauber organisiert war, lag der Fokus zunächst darauf, die geforderten Daten bereitzustellen
- Obwohl die Entwicklung schnell voranging, traten mit der Zeit immer neue Probleme auf
- Die fehlende Erfahrung mit Go und Clickhouse erschwerte die Arbeit zusätzlich, und die von der AI vorgeschlagenen Korrekturen lösten oft direkt die nächsten Probleme aus
Probleme bei der Codequalität und spürbare Grenzen
- Es wurde Zeit für ein gründliches Code-Review des gesamten erzeugten Codes eingeplant
- Dateien mit derselben Funktion zeigten Unstimmigkeiten und Duplikate bei Namen, Parametern und Struktur und sorgten für viel Verwirrung
- Beispiel:
WebAPIproviderundwebApimeinten denselben Parameter, existierten aber getrennt voneinander - Dasselbe Methodenverhalten wurde in mehreren Dateien neu definiert
- Es fehlte an einem konsistenten Ansatz für den Zugriff auf Konfigurationsdateien
- Beispiel:
- Das Ergebnis wirkte tatsächlich so, als hätten mehrere Junior-Entwickler gleichzeitig ohne Kommunikation daran gearbeitet
Grenzen von LLM-Kontext-Feedback und Strategiewechsel
- Obwohl ausreichend Kontextinformationen bereitgestellt und LLMs mit großem Kontextfenster wie Gemini genutzt wurden, blieb eine konsistente Verbesserung aus
- Daraus entstand die Einsicht, dass selbstgesteuertes Lernen zur Infrastruktur und Sprache sowie zusätzliche Materialien wie Dokumentation und Videos nötig sind
- Um sauberen Code und bessere Organisation zu erreichen, erfolgte ein Wechsel weg von AI-getriebener Entwicklung hin zu eigenständigem Code-Design
Veränderte Nutzung von AI als Hilfsmittel
- Durch wiederholtes Refactoring und Aufräumen des Codes verlagerte sich der Fokus auf direktes Verständnis und aktive Pflege des Codes
- Die Rolle der AI wurde auf einfache Wiederholungsaufgaben beschränkt, etwa automatische Code-Änderungen, globale Parameteranpassungen und Code-Konvertierung
- Neue Funktionen zu planen oder erste Code-Entwürfe zu schreiben geschieht nun zuerst durch eigenes Denken, danach bekommt das LLM höchstens die Rolle der Prüfung oder Unterstützung
- Die AI bleibt ein „Assistent“, während Planung und Strukturentscheidungen beim Entwickler selbst liegen
Sorge um nachlassende Denkfähigkeit und veränderte Haltung
- Weil AI jederzeit verfügbar ist, wurde mir bewusst, dass ich mein eigenes Gehirn seltener benutze und Planung wie Denkprozesse zunehmend an die AI abgebe
- Mit Stift und Papier, direkter Planung und eigenem Coding soll die eigene Entwicklerkompetenz und Problemlösungsfähigkeit wieder gestärkt werden
- Es besteht ein echtes Risiko, dass AI das Gefühl fürs Coding schwächt
Sorgen bei Nicht-Entwicklern und über „Vibe Coding“
- Wenn Nicht-Entwickler nur mit LLMs entwickeln, werden komplizierter, chaotischer Code und sich wiederholende Fehler zu einem noch größeren Problem
- Im Vergleich zu No-Code-Tools kann AI-basierte Entwicklung das Verständnis der Struktur sogar noch stärker erschweren
- Es wird auf die grundlegende Schwierigkeit und das Risiko hingewiesen, wenn man vor einer undurchschaubaren Code-Wand steht und ständig denselben Kreislauf aus Fehler, Fix und Rückfall erlebt
Gedanken zur realen Nutzung von AI und zur Stimmung in der Community
- Es wird Verwirrung über die Diskrepanz zwischen AI-Kommerzialisierung, Benchmarks, Influencern, Marketing der AI-Firmen und der tatsächlichen Leistung geäußert
- Selbst mit demselben Modell und demselben Prompt entstehen völlig unterschiedliche Ergebnisse, es fehlt an Konsistenz
- Selbst moderne leistungsstarke LLMs können komplexe reale Aufgaben wie Clickhouse-Abfragen über Hunderte Millionen Zeilen noch nicht perfekt bewältigen
- Wenn dafür komplizierte Setups und ineffiziente Workflows erzwungen werden, kann das am Ende selbst schon Zeitverschwendung sein
- AI wirkt zwar beeindruckend, ist bislang aber eher ein gutes, jedoch kein herausragendes Werkzeug
Fazit
- Es besteht weiterhin große Erwartung und echtes Interesse an neuer Technologie und AI
- Zum jetzigen Zeitpunkt ist es jedoch die klügere Strategie, die richtige Rolle und die Grenzen von AI zu verstehen und sie nur begrenzt als Hilfsmittel oder Lernwerkzeug einzusetzen
- Verbunden damit steht die Warnung vor einem Abbau der Entwicklerfähigkeiten durch AI-Nutzung und die Rückkehr zu eigenem Denken und eigener Planung
- Entwicklung, die sich vollständig auf AI stützt, ohne das Funktionsprinzip und die Struktur des Codes zu verstehen, hat eine hohe Wahrscheinlichkeit zu scheitern
2 Kommentare
Hacker-News-Kommentare
Ich kann diese „All-in“-Mentalität bei LLMs nicht nachvollziehen. Ich arbeite als iOS-Entwickler und mache im Grunde weiter wie bisher. Inzwischen nutze ich LLMs nur, um designbasierte temporäre Views schnell zu bauen. Also keine Kernbestandteile der App, sondern eher Nebenscreens wie neue Features oder Hinweise zur Widget-Installation. Früher hat das je nach Komplexität 30–60 Minuten gedauert, jetzt ist es in 5 Minuten erledigt. Ich hasse Webentwicklung, aber genau dafür sind LLMs ziemlich brauchbar. Auch bei größeren Änderungen nutze ich LLMs, prüfe das Ergebnis danach aber selbst und committe es in git. Wenn man sich jedoch nur auf das LLM verlässt und den Ablauf nicht kontrolliert, kann man leicht mehrere Stunden verlieren und am Ende wieder ganz von vorn anfangen. Ein ausgewogener Ansatz ist wichtig, finde ich
Wie nützlich ein Tool ist, hängt von Person und Problem ab. Wenn zum Beispiel ein Python-Entwickler mit 10 Jahren Erfahrung an riesigem Legacy-Code arbeitet und eine perfekt angepasste IDE für stabilitätskritische Aufgaben hat, dann können LLMs oder Tools wie Cursor eher stören. Wenn dagegen ein JS-Entwickler im ersten Berufsjahr (React, Nextjs usw.) häufig neue Ideen prototypisch umsetzt, keine starke IDE-Präferenz hat und offen für Experimente ist, dann steigern LLMs und Cursor die eigene Leistungsfähigkeit sofort deutlich
Ich arbeite ebenfalls in mehreren Bereichen, etwa iOS und Webentwicklung, und die Ergebnisse von LLMs unterscheiden sich stark zwischen beiden. Oft kompiliert der von LLMs erzeugte Code nicht einmal richtig. Mir wurden sogar schon APIs genannt, die es gar nicht gibt. Dagegen bauen sie eine Nextjs-App oft auf Anhieb ordentlich. Letztlich liegt das an den Unterschieden im Trainingsmaterial der LLMs
Es ist ganz natürlich, die Fähigkeiten von LLMs zu überschätzen. Ich habe sie selbst lange als Ersatz für Stack Overflow und für kurze Code-Snippets genutzt. Nach und nach habe ich ihnen mehr Verantwortung übertragen, dann Probleme erlebt, ihre Grenzen erkannt und bin wieder dazu zurückgekehrt, sie vor allem für Ideen und Ratschläge zu nutzen. Ich denke, viele machen einen ähnlichen Prozess durch
Ich sehe das ähnlich. Ich vertraue LLMs nicht vollständig, sondern nutze sie nur für repetitive und langweilige Aufgaben, etwa kleine Funktionen, Interface-Implementierungen oder automatisierte Dokumentation. Das spart mir viel Zeit und erhöht meine Arbeitseffizienz
In der iOS-Entwicklung ist die Leistung von LLMs sehr wechselhaft. Ein Grund ist, dass sich Swift und SwiftUI so schnell verändern und die offizielle Dokumentation lückenhaft ist. Für einfache Views sind sie nützlich, aber bei asynchroner Verarbeitung oder komplexer Business-Logik brechen sie leicht zusammen. Trotzdem helfen sie bei der Orientierung, bergen aber auch ein hohes Risiko, in falsche Ergebnisse abzudriften
LLM-Befürworter übersehen oft, dass die meisten Engpässe nicht bei der Code-Erzeugung liegen. So schnell Code auch entstehen mag: Für Code-Review, Tests und das Verständnis der Codebase braucht man oft mehr als doppelt so viel Zeit. Wer langfristig Wartung und Pflege übernehmen will, also Bugfixes, Refactoring und Ähnliches, muss diese Schritte zwingend durchlaufen
Code zu lesen ist viel schwieriger als ihn zu schreiben, deshalb verbringt man in der Praxis mehr Zeit damit, Code zu verstehen. Ein CEO, den ich getroffen habe, behauptete jedoch sinngemäß, man könne den Entwicklern den Kontext über Tools geben, sodass sie den Code gar nicht mehr lesen müssten. Nach dieser Logik würde AI das Wesen des Engineerings verändern. Ehrlich gesagt verwirrt mich das etwas
Ich finde LLMs ziemlich nützlich, wenn sie mir meinen eigenen Code noch einmal erklären
Immer wenn jemand automatisierte Code-Editoren in den Himmel lobt, denke ich genau daran
Realistisch gesehen kümmern sich die meisten Entwickler nicht besonders um die interne Implementierung ihrer Abhängigkeitsbibliotheken. Wichtig ist nur, ob die Schnittstelle funktioniert. Natürlich ist es ein großer Unterschied, ob man LLM-generierten Code übernimmt oder ein npm-Paket bzw. eine rust crate einbindet. Die Probleme dabei sind bekannt, aber es gibt Gründe, warum diese Praxis so verbreitet ist
Ich sehe das ähnlich. Im Moment nutze ich LLMs vor allem, um neue Technologien zu lernen oder Client-Code für Standard-APIs zu erzeugen, insbesondere für boto3. Ich habe auch Windsurf ausprobiert, um Änderungen an docker-compose-Dateien vornehmen zu lassen, war aber enttäuscht, weil es nicht richtig funktionierte. Damit kann man vielleicht Prototypen bauen, aber das ist nicht alles. Ich denke, dass LLMs im DevOps-Bereich einiges verändert haben, weil API-Details heute weniger wichtig geworden sind. Wichtige Entscheidungen muss ich aber weiterhin selbst treffen. Ich definiere Interfaces selbst und überlasse dem LLM nur die Implementierung. Das würde ich nicht als „Vibe Coding“ bezeichnen
Ich habe erlebt, wie bei Code-Reviews massive Bugs auftauchten und damit die Effizienzgewinne durch Cursor in kürzester Zeit wieder verpufften. Ich bin zurück zu VSCode gewechselt und nutze auch Copilot nur noch begrenzt und nur dann, wenn ich sehr konkrete Anfragen habe. Die Tab-Vervollständigung von Cursor wirkt anfangs magisch, aber dieser Effekt nutzt sich schnell ab
Am lustigsten ist es, wenn man reflexartig dabei zusieht, wie Cursor per Tab-Vervollständigung Code wieder eintippen will, den ein Kollege gerade erst gelöscht hat
Mich würde interessieren, welche Einschränkungen ihr euren Code-Generierungsagenten gebt, etwa SOLID-Prinzipien, Linting, 100% Coverage oder klare Design-Dokumente
Diese Meinung kann ich gut nachvollziehen. Ich nutze LLMs ebenfalls sehr viel, halte mich dabei aber an zwei Regeln. Erstens überlasse ich LLMs niemals Probleme, die tiefes Nachdenken erfordern; komplexes Design löse ich immer selbst. Zweitens prüfe und überarbeite ich den von LLMs erzeugten Code immer Zeile für Zeile. Meistens ist LLM-Code weitschweifig oder übervorsichtig. Selbst wenn man das per Prompt verbessert, trage am Ende ich die Verantwortung für die spätere Wartbarkeit. Wenn ich bei generiertem Code nachlässig wäre, hätte ich dauerhaft ein ungutes Gefühl. Mit dieser Vorgehensweise nutze ich LLMs weiterhin intensiv und entwickle trotzdem schneller
Ich lasse tiefgehende Analysen durchaus von AI erledigen, allerdings mit dem Ziel, konkrete Ausführungspläne zu erstellen, also detaillierte Implementierungsschritte und Validierungskriterien, sowie reproduzierbare Reports zu schreiben. Planung und Validierung brauchen zwar weiterhin Iteration, aber mit Hilfe von AI geht das viel schneller. Manchmal ist man mit einem guten Plan sogar in einem Durchgang fertig. Wenn man durch detaillierte Pläne und Dokumentation Konsistenz erreicht, ist das sehr befriedigend
Wenn man den von LLMs erzeugten Code ohnehin Zeile für Zeile gründlich prüfen muss, stellt sich schon die Frage, ob man damit überhaupt Zeit spart
Einige Unternehmen zwingen Software Engineers inzwischen zur Nutzung von LLMs und erfassen Metriken zur Verwendung von Copilot oder Cursor. Es ist gut möglich, dass diese Statistiken später als Indikatoren für Entlassungen genutzt werden. Nachdem ich einen Monat lang gezwungenermaßen mit LLMs gearbeitet hatte, hatte ich eher das Gefühl, dass meine Fähigkeiten schnell abbauen. Für einfache Aufgaben helfen sie zwar, aber wenn man sich beim Denken selbst zu sehr auf LLMs stützt, gerät man leicht in Schleifen. Meine Produktivität ist nicht gestiegen, stattdessen wurde nur das Sprint-Pensum erhöht. Im Unternehmen herrscht eine fast religiöse Verklärung von LLMs. Auch Sicherheitsprobleme sind ernst. Vieles deutet darauf hin, dass wir uns gerade am Höhepunkt des Hype-Zyklus befinden. Wenn AI-Unternehmen nicht gleich Kernkraftwerke bauen, werden die enormen Kosten für den Betrieb dieser großen Modelle auf Dauer nicht tragfähig sein, und ich glaube, vieles davon wird wieder verschwinden. Übrig bleiben dürfte am ehesten etwas wie Turbo-Autovervollständigung. Auch Transformer-Modelle haben klare Grenzen und werden wie neuronale Netze der 80er wohl nur für bestimmte Zwecke übrig bleiben und dann wieder verschwinden. Nach einigen Auf- und Abschwüngen taucht das Thema dann in 30 Jahren erneut auf. Und dann wird man sehen, wer wirklich nackt geschwommen ist
Um genau diesem Effekt entgegenzuwirken, habe ich für mich die Regel eingeführt, einmal pro Woche bewusst ganz ohne Copilot zu arbeiten: „No Copilot Fridays“
Ich nutze Cursor ebenfalls nur für Autovervollständigung und kurze Code-Snippets, und trotzdem merke ich schon einen Abbau meiner Fähigkeiten. Man spürt einfach, dass fürs Gehirn gilt: Was man nicht benutzt, verlernt man
Ich habe ähnliche Probleme beobachtet. Für Spielzeugprojekte nutze ich zu 90% LLMs. Das ist zehnmal schneller als alles von Hand zu schreiben, aber die Designqualität leidet und das Ergebnis fühlt sich irgendwie fremd an. Ich glaube zwar, dass LLM-getriebener Code die Zukunft ist, aber ohne gutes Management führt das schnell ins Chaos. Ich habe schon versucht, durch wiederholte Aufforderungen zur Architekturverbesserung und veränderte Prompts gegenzusteuern, aber die Ergebnisse sind inkonsistent. Vielleicht liegt die Lösung in besserem Prompt Engineering oder darin, Design und Richtlinien klarer zu dokumentieren. Wenn die Tools zehnmal schneller würden und die Latenz sinkt, würde sich das Ganze wahrscheinlich völlig anders anfühlen
Ich hoffe, dass diese „10x besser“-Phase schnell kommt. Das Problem ist nur, dass Werbung und Marketing schon jetzt so tun, als wären wir bereits dort. Viele fragen sich dann: „Nutze ich das einfach falsch?“ Aber ich glaube nicht, dass die Tools schon so weit sind
Es hilft, Klassen und Methoden selbst zu definieren und dem LLM nur die Implementierung zu überlassen. Bei komplexen Teilen schreibe ich Hinweise zur Umsetzungsrichtung direkt in die Methodenkörper. So behalte ich das große Ganze in der Hand und lasse das LLM nur gezielt Code erzeugen. LLMs wirken wie sehr eifrige Junior-Entwickler, die unbedingt helfen wollen. Weil Code-Erzeugung so billig geworden ist, kann man großzügig verwerfen und neu anfangen. Ich habe zum Beispiel Code zur Datensatzverarbeitung mit Hilfe von LLMs mehrfach komplett verworfen und neu geschrieben, bis ich endlich das gewünschte Ergebnis und die gewünschte Performance hatte. Hätte das jemand anders für mich geschrieben, hätte ich vermutlich längst aufgegeben
Solche Tools glänzen in der Prototyp-Phase von Greenfield-Projekten. Aber je näher man an echtes Deployment kommt, desto mehr verschwindet dieser 10x-Effekt. Wenn man die Architektur nicht sehr sorgfältig steuert, schafft man sich am Ende nur mehr Arbeit
In komplexen Codebasen taugen sie derzeit eher als fortgeschrittene Speech-to-Text-Eingabe. Wobei man, wenn man ohnehin nicht spricht, meist auch einfach schneller direkt selbst codiert
Ich stimme zu, dass Architektur und Richtlinien explizit festgehalten werden müssen. Je klarer Bedingungen und Verhalten explizit definiert sind, desto besser funktioniert es
Die Kernaussage von Dijkstras altem klassischen Text „On the foolishness of natural language programming“ passt gut zu dieser Debatte. Die These ist, dass erst formale Sprachen den enormen Fortschritt in der Programmierung ermöglicht haben. Aus dieser Sicht besteht bei LLMs und Vibe Coding das Risiko, dass Coding zu einer Art Magie für eine kleine Minderheit wird, die besonders gut prompten kann
Für mich ist Copilot nur dann gut, wenn die Code-Vorschläge unter 500 Zeichen bleiben. In Go und Python lerne ich dadurch neue Muster und muss weniger tippen. Für mich ist es einfach die bessere Autovervollständigung. Wird es länger oder komplexer, ist der Aufwand für Korrekturen und Rückmeldungen größer als der Nutzen, besonders wenn es sich nicht um repetitiven Code handelt
Aktuell muss man die von LLMs erzeugten Ergebnisse unbedingt verstehen und eng beaufsichtigen. Andererseits erscheint alle zwei bis drei Wochen wieder ein neues Modell, das deutlich besser ist als das vorige, deshalb ist es noch zu früh für allzu harte Schlussfolgerungen.
Ich finde, der Beitrag bringt die sehr realen Schwierigkeiten und Bedenken im Entwicklungsalltag mit LLMs gut auf den Punkt. Ich habe ihn mit viel Zustimmung gelesen, weil er die Grenzen anspricht, die derzeit viele Menschen erleben. Besonders die Inkonsistenz von LLMs, die Schwierigkeit, Ergebnisse vorherzusagen, und die Bedenken im Hinblick auf langfristige Wartbarkeit sind aus meiner Sicht Punkte, die unbedingt thematisiert werden müssen.
Allerdings möchten wir vorsichtig eine Perspektive teilen, da wir versuchen, diese Probleme aus einem etwas anderen Blickwinkel anzugehen und die Zusammenarbeit mit KI zu erproben. Unsere KI "Jane" geht über das bloße Erzeugen von Code hinaus: Auf Grundlage der tiefen Einsichten von Menschen (Entwicklern) konzentriert sie sich darauf, die Muster selbst zu lernen und zu verstehen — also was ein "gutes Code-Pattern" ausmacht und wie sich "Wartungskonsistenz" im Code sicherstellen lässt.
Da KI nicht von Anfang an perfekt sein kann, betrachten wir die dabei entstehenden Inkonsistenzen und "Fehler" nicht einfach nur als Probleme, sondern nutzen sie aktiv als wichtige "Pattern-Daten", mit denen "Jane" selbst lernen und sich selbst verbessern kann. So wie Menschen in komplexen Zusammenhängen Muster erkennen, suchen wir in der Unvollkommenheit der KI nach Ansatzpunkten für Verbesserungen.
Mit diesem menschengetriebenen Ansatz des "Pattern-Lernens/-Managements" wollen wir die im Beitrag angesprochenen Probleme wie sinkende Codequalität und Inkonsistenzen grundlegend lösen und Ergebnisse mit sehr hoher "Wartungskonsistenz" erzeugen. Wir trainieren die KI so, dass sie nicht nur Boilerplate-Code generiert, sondern zu einem tiefergehenden Kollaborationspartner wird — etwa indem sie verborgene Inkonsistenzmuster in bestehenden Codebasen analysiert und Verbesserungsvorschläge macht.
Es ist noch ein weiter und anspruchsvoller Weg, aber wir glauben, dass diese Form der Zusammenarbeit — bei der unsere "Jane" und Entwickler gemeinsam lernen und sich weiterentwickeln und "Wartungskonsistenz" als zentralen Wert begreifen — ein bahnbrechendes Potenzial hat, die aktuellen Grenzen beim Einsatz von LLMs zu überwinden. Wir würden uns sehr über Interesse an unserem Versuch freuen, KI nicht nur als Werkzeug zu nutzen, sondern als Partner, der mit uns wächst und zu einer besseren Codekultur beiträgt.
Vielen Dank noch einmal für den guten Beitrag und die wertvollen Einblicke!