- Der Autor nennt als Hauptgrund, dass AI-Tools ihn nicht schneller machen, und nutzt deshalb keine generativen AI-Coding-Tools
- Er ist der Ansicht, dass die Zeit für das Prüfen und Verstehen von AI-generiertem Code länger dauern kann, als ihn selbst zu schreiben
- Codequalität und Verantwortung liegen weiterhin beim Entwickler selbst, daher ist es riskant, AI-Code ohne Prüfung zu verwenden
- Auf die Behauptung, man solle AI wie einen Praktikanten betrachten, entgegnet er, AI gleiche eher einem Praktikanten mit Gedächtnisverlust, weil sie nicht lernen kann
- Er erklärt den Unterschied zwischen Open-Source-Beiträgen und AI-Code und betont den Wert der Interaktion mit Menschen, die neue Ideen liefert
Einleitung
- Viele Menschen fragen mich, ob ich generative AI-Coding-Tools verwende und was ich davon halte
- In diesem Text fasse ich jenseits von Pro und Contra nur meine persönlichen technischen Erfahrungen zusammen
- Ich erkläre aus technischer Sicht die Gründe, warum AI mir beim Programmieren nicht hilft
AI ist nicht schneller
- Auch mit generativen AI-Coding-Tools wird meine Arbeit nicht schneller
- Selbst wenn AI Code schreibt, liegt die Verantwortung für den Code bei mir; ich kann ihn nur dann in ein Projekt übernehmen, wenn ich den gesamten Code gründlich prüfe und vollständig verstehe
- Code Review erfordert genauso viel Zeit und Konzentration wie das Schreiben von Code, und in der Branche gibt es das Sprichwort, dass „Code lesen schwieriger ist als ihn zu schreiben“
- Dem von AI geschriebenen Code wie einer „Blackbox“ zu vertrauen, ist eine sehr verantwortungslose Entscheidung. Wenn Fehler im Code auftreten, liegt auch die rechtliche und finanzielle Verantwortung beim Programmierer
- Ohne Qualitätsverlust und steigendes Risiko sind Produktivitäts- oder Gewinnsteigerungen durch AI nicht möglich
AI ist kein Hebelwerkzeug
- Manche behaupten, AI-Coding-Tools würden die Effizienz vervielfachen, aber das ist nur ein subjektiver Eindruck
- Einige Nutzer verwenden von AI erzeugten Code ohne Review oder prüfen ihn nur teilweise, um Zeit zu sparen; ich kann diesen Schritt jedoch nicht überspringen, deshalb hilft es mir nicht
- Auch der Behauptung, AI sei beim Lernen neuer Sprachen oder Technologien effizient, stimme ich nicht zu. Der Prozess, etwas Neues zu lernen, ist selbst Teil der Freude am Programmieren
- Tatsächlich lerne ich verschiedene Sprachen wie Rust, Go und TypeScript direkt selbst, und ich delegiere diese Erfahrung nicht an AI
- Denn die Verantwortung für jeden Code liegt am Ende bei mir
AI-Code ist anders als menschlicher Code
- Ich werde oft mit der Frage konfrontiert: „Auch Open-Source-Beiträge sind Code, den ich nicht selbst geschrieben habe – warum behandelst du ihn anders als AI-Code?“
- Tatsächlich investiere ich auch in Open-Source-PRs Zeit und prüfe sie gründlich. Aber die Zusammenarbeit mit Nutzern führt zu neuen Ideen und Motivation
- Manche sagen, es sei ein Gamechanger, mehrere AI-Agenten laufen zu lassen und so PRs zur Behebung von Bug-Issues zu erhalten; letztlich bleibt aber das Code Review ein menschlicher Flaschenhals, sodass es eher langsamer wird
- Mit der Verbreitung von AI-Tools entstehen immer häufiger PRs von niedriger Qualität. AI-Code hat etwas subtil Fremdartiges an sich, und wenn man den Einreicher eines PRs etwas fragt, bekommt man oft keine Antwort
- Verantwortungsvolle Code-Beiträge und die Kommunikation in der Open-Source-Community sind wichtige Unterscheidungsmerkmale menschlichen Codes
Der Unterschied zwischen AI und Praktikanten
- Es gibt auch den Vergleich, AI sei wie ein Praktikant, aber das ist grundlegend anders
- Der frühe Code eines Praktikanten erfordert zwar viel Review und Zeit, aber er wächst durch Feedback schnell
- Durch diese Investition in seine Entwicklung wird er schließlich zu einem wichtigen Kollegen, dem man eigenständig Aufgaben anvertrauen kann
- AI-Tools vergessen bei jeder neuen Aufgabe ihr Wissen und beginnen wieder von vorn, sie können weder wachsen noch Erfahrungswissen ansammeln
- Das ist wie ein Praktikant, der sich nie weiterentwickelt, und kann daher nichts zur Produktivitätssteigerung beitragen
Fazit
- Mit diesem Text möchte ich die technischen Probleme beim Einsatz generativer AI-Coding-Tools klar benennen
- Beim AI-Coding gibt es kein „Gratis-Mittagessen“
- Behauptungen, man werde durch AI schneller oder produktiver, beruhen entweder darauf, die Qualitätsmaßstäbe zu senken und zusätzliche Risiken in Kauf zu nehmen, oder auf den Interessen der AI-Verkäufer
- Programmierer sollten stets im Blick behalten, dass sie die letztverantwortliche Instanz sind
5 Kommentare
Ich habe mich inzwischen vollständig auf den Agent-Modus von copilot (claud) + codex (o3/4o/codex-mini, drei Modelle gleichzeitig per mcp) eingespielt, aber ich denke, wie wirksam das ist, hängt enorm von der Person und vom Projekttyp ab, die es einsetzen.
Ich starte parallel Arbeiten in 5–6 Workspaces und prüfe sie dann in der Reihenfolge, in der sie fertig werden. Dass das Modell sogar bis in den Open-Source-Code hineinschaut und die Verifikation komplett übernehmen kann, finde ich ziemlich gut. Wenn ich zur Mittagspause Arbeit anstoße, sind ein oder zwei Aufgaben danach oft schon fertig. Manchmal läuft es auch über Nacht, aber das copilot rate limit ist eben eine Blackbox ...
Auch Aufgaben wie High-Performance-Kernel, die Vereinfachung eines kompletten call stack oder das Sicherstellen von readability, die für Menschen wegen der vielen Kontextwechsel Zeit kosten, bekommt es hin, wenn man Prompt und Ziel sauber vorgibt (schließlich kann es mehr Code gleichzeitig im Speicher halten als ein Mensch). In solchem Code ist es dann leicht, Patches zu reviewen ... Und für Leute, die schon Ausfälle erlebt haben, weil APIs falsch verwendet wurden oder weil Open-Source-Projekte selbst Bugs hatten, ist es auch für die eigene mentale Gesundheit hilfreich, das mit einem Agenten sauber verifizieren zu lassen ...
Allerdings muss die entwickelnde Person die Patches am Ende verstehen können. Und man muss wissen, wie man Prompts formuliert. Man muss aus Erfahrung schnell erfassen können, wie das Problem zu fassen ist, und es entsprechend formulieren — erst dann kann man von dort aus starten. So wie High-Performance-Kernel-Entwicklung ohne Formeln nicht möglich ist. Ob ein Problem auf Chip-/OS-Ebene liegt, auf Anwendungsebene oder an einer remote resource, das einzuschätzen scheint weiterhin eher die Aufgabe von Seniors zu sein.
Aus der Perspektive von jemandem, der Copilot, ChatGPT-artige Tools, Cursor usw. in gewissem Maß verwendet hat, eignen sie sich gut für die Rolle von Vorlagen oder Snippets in Entwicklungstools, sind aber nicht auf dem Niveau eines Agenten oder Coworkers.
Ich nutze Cursor.
Im Chat-Modus bevorzuge ich
askgegenüberagent, weil ich möchte, dass es nach einer Prüfung auf meinen Code angewendet wird, und insgesamt stimme ich den im Artikel genannten Nachteilen zu.Trotzdem werde ich generative KI weiter nutzen, weil sie oft Ideen oder Code erzeugt, auf die ich selbst nicht gekommen wäre, und ich sie deshalb als Referenz durchaus für wertvoll halte.
Das deckt sich mit meinen persönlichen Erfahrungen beim Einsatz generativer Coding-Tools.
Hacker-News-Kommentare
Manche haben jedes Mal Fragen, wenn sie eine neue Sprache oder Technologie lernen; früher suchte man dann bei Google oder stellte eine Frage auf Stack Overflow und wartete auf Antworten. Heute fragt man direkt ChatGPT oder Gemini und bekommt viel schneller eine Antwort, was die Produktivität deutlich erhöht. Ich möchte betonen, dass schon allein dieser schnelle Zugang zu Antworten den Lernprozess beschleunigt.
Dass ChatGPT und Gemini richtige Antworten geben können, liegt daran, dass sie bereits vorhandenes Wissen aus dem Web, einschließlich Stack Overflow, gelernt haben. Wenn alle nur noch AI für Fragen nutzen, könnten verlässliche öffentliche Wissensquellen irgendwann versiegen. Das wäre ähnlich wie eine Rückkehr ins Enzyklopädie-Zeitalter, als Informationen mit hohen Kosten gesammelt und verkauft wurden. Außerdem sollte man klar unterscheiden zwischen AI-Coding-Tools, die direkt Code schreiben, und Tools, die Fragen beantworten; die Kritik des Autors richtet sich gegen Ersteres.
Früher ist mir einmal ein Programm abgestürzt, als ich eine mir unbekannte API benutzt habe. Ich habe den Stack Trace in Gemini eingefügt und sofort einen Hinweis auf die Ursache bekommen, sodass ich das Problem mit nur zwei geänderten Zeilen lösen konnte. Schon an solchen Erfahrungen merkt man den Wert von AI. Gerade in unbekannten Bereichen ist es ein großer Vorteil, nicht mehr lange an dummen Fehlern hängen zu bleiben.
Die Suche priorisiert inzwischen immer stärker Blog-Spam; sinnvoller und lehrreicher ist es, von Grund auf mit guter offizieller Dokumentation oder Benutzerhandbüchern zu lernen. Wenn man gute API-Dokumentation liest, lernt man oft ganz nebenbei auch das Gesamtdesign und zusätzliche Funktionen kennen. Blog-Beispiele oder Tutorials lösen vielleicht das akute Problem, helfen aber nicht wirklich dabei, echte Fähigkeiten aufzubauen. Sie machen im Grunde nur die Hausaufgaben für einen, daher glaube ich nicht, dass ChatGPT echtes selbstgesteuertes Lernen fördert.
Bei schwierigen Problemen muss man AI-Ergebnisse unbedingt verifizieren. Ich habe auch AI-Autovervollständigung deaktiviert, weil der Effizienzgewinn in der Praxis gering war und stattdessen eher unnötige Änderungen entstanden. Erstaunlicherweise bekommt man selbst mit vollständig offline laufenden lokalen Modellen ziemlich brauchbare Referenzen. Auch die in Google integrierten Gemini-Ergebnisse sind qualitativ eher schwach. Meine größte Sorge ist, dass echte Wissensspeicher wie Stack Overflow verschwinden könnten, wenn Menschen Informationen nur noch über AI beziehen.
Für kleine Boilerplate-Tools ist AI perfekt. Bei einfachen Dingen wie Browser-Erweiterungen oder Tampermonkey-Skripten kann man fast ohne Dokumentation direkt loslegen. Auch bei unkomplizierter Code-Autovervollständigung oder kleinen Änderungen ist AI ziemlich nützlich. Kleine Projekte, mit denen man sonst gar nicht erst angefangen hätte, lassen sich so schnell erledigen.
Ein möglicher Vorteil des direkten Codens ist, dass sich ein starkes mentales Modell des Problems im Kopf festsetzt. Das wirkt später bei Problemlösung oder bei der Integration neuer Funktionen enorm, quasi als Effekt unbewussten Lernens. Wirklich besser wird man erst, wenn sich Erinnerungen daran ansammeln, etwas mit den eigenen Händen gemacht zu haben. In den Organisationen, die ich gesehen habe, hat die Einführung von LLMs trotz allem nicht zu einer echten Vervielfachung der Produktivität geführt. Vielleicht verwechselt man es einfach damit, das Gehirn weniger anzustrengen und den leichteren Weg zu nehmen.
Ich finde, das fasst sehr gut zusammen, wie Menschen sich daran gewöhnen, Probleme mit weniger geistiger Energie zu lösen, und diese Illusion dann als Produktivität empfinden. Google Research hat 2024 in einem Experiment zur Produktivitätswirkung von LLMs festgestellt, dass die Gruppe mit LLM-Nutzung sogar länger brauchte als die Gruppe, die aus einem Buch lernte, und dass sich nur bei Anfängern leichte Punktsteigerungen zeigten, nicht aber bei Fortgeschrittenen. Viele Teilnehmer glaubten jedoch fälschlich, schneller und genauer zu sein, und die Forschenden interpretierten das als Folge einer „reduzierten kognitiven Belastung“. Relevantes Paper: https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
Wenn man weniger geistige Energie aufwendet und dadurch länger arbeiten kann, könnte man dann nicht tatsächlich mehr Arbeitsvolumen bewältigen? Schon jetzt sind bei sehr anspruchsvoller Arbeit 3 bis 4 Stunden oft die Grenze. Wenn man einen Marathon im Gehtempo laufen kann, steigt am Ende vielleicht trotzdem die Gesamtleistung.
Ich stimme zu, dass traditionelles Coden und AI-Coding zwei getrennte Skills sind. Ich selbst bin auch sehr skeptisch gegenüber der Behauptung, AI werde das Coden ersetzen. Gleichzeitig glaube ich aber, dass auch „AI-Coding“ selbst eine erhebliche Lernkurve hat, etwa bei Prompt-Management oder beim Halten von Kontext, und dass viele seinen Wert gerade dort unterschätzen. Es ist ein bisschen wie Handzeichnung und Fotografie: Schon das Ziel, das jeweils verfolgt wird, kann unterschiedlich sein. Meine bevorzugte Arbeitsweise ist: „AI übernimmt die mühsame Arbeit, ich kümmere mich um Gesamtdesign und Koordination.“
LLM-basiertes Coding geht über einfache Autovervollständigung hinaus; es ähnelt eher dem Auslagern von Arbeit, bei dem man wiederholt Aufgabe definiert, Feedback gibt und iteriert. Der Unterschied liegt in der Bearbeitungsgeschwindigkeit, wo LLMs im Vorteil sind, und in der Verlässlichkeit, wo Menschen vorne liegen; langfristig dürfte diese Grenze aber immer unschärfer werden. Wichtig ist für mich: Ich bin grundsätzlich der Typ, der Details einer Aufgabe selbst bearbeiten möchte. Ich habe diesen Beruf gewählt, weil ich Infrastruktur und Programmierung lernen und darin tief eintauchen wollte. Deshalb meide ich Management-Rollen und bestehe lieber darauf, selbst Dinge zu bauen, auch wenn ich dadurch weniger verdiene. Wenn AGI eher das Niveau eines Kollegen erreicht, werde ich mich vielleicht wieder stärker dafür interessieren. Auch die Bezeichnung „AI“ selbst könnte in Zukunft gar nicht mehr als etwas Besonderes wahrgenommen werden.
Selbst wenn die Lernkurve für AI-Coding größer ist als gedacht, ist das etwas anderes als beim Klavier, in das man Jahre investieren muss. Selbst die derzeit erfahrensten AI-Coder haben höchstens etwa drei Jahre Erfahrung, und die Modelle ändern sich ständig, sodass ältere Erfahrungen oft nicht gut auf die aktuelle Modellgeneration übertragbar sind. Dass es keine Struktur gibt, in der man von einem Meister lernen kann, ist ebenfalls eine Grenze.
Ist AI-Coding-Skill langfristig überhaupt wertvoll? Ich bin skeptisch, wie gut sich die Skillsets heutiger AI-Tools auf zukünftige Generationen übertragen lassen. Selbst wenn die Effizienz aktuell steigt, muss man einkalkulieren, dass das Wissen mit neuen Modellen oder Tools schnell wertlos werden könnte.
Ich denke, AI-Coding beherrscht man in ein paar Minuten oder vielleicht in einer Stunde. Bildlich gesprochen ist das kein Gebiet wie GDB oder UNIX, in das man sich buchweise vertiefen müsste. So wie man Zeichnen und Fotografieren nicht verwechselt, weil Prinzipien und Ziele grundverschieden sind, ist auch AI-Coding eine völlig andere Tätigkeit als klassisches Programmieren.
Ich kann dem Selbstvertrauen nicht zustimmen, mit dem manche unterstellen, die Vorliebe für direktes Coden liege einfach nur an mangelnder AI-Coding-Kompetenz. Schon der ROI aus kleineren bezahlten Tests und Free Trials reicht aus, um das für mich beurteilen zu können.
Tatsächlich entsteht eine Kultur, in der statt AI-Code-Review oder Ergebniskontrolle der von AI erzeugte Code einfach als PR eingereicht und das Review auf andere abgewälzt wird. In so einer Situation ist GenAI weniger wirklich nützlich, sondern hat eher den Nebeneffekt, dass Arbeit weitergeschoben wird.
Diese Erfahrung habe ich auch gemacht. Wenn ein Manager wenig Kompetenz hat, kann er nicht unterscheiden, wer tatsächlich Wert schafft. Ich ziehe aus Coding-Agenten wirklich viel Nutzen, aber ich halte es für ein ernstes Problem, wenn unfähige Organisationen schlampige Ergebnisse belohnen.
Wenn die eingereichten PRs immer wieder einfach nur unveränderte AI-Ergebnisse sind, dann sollte sich das Feedback ansammeln und der Teamleiter das Thema unbedingt ansprechen.
Als jemand, der Claude Code häufig nutzt, stimme ich der Aussage zu 100 % zu, dass beim Prüfen von Code anderer der Zeitunterschied zum eigenen Schreiben fast null ist. LLMs sind durchaus brauchbar, aber je mehr Kontrolle man abgibt, desto länger dauert es am Ende oft bis zum tatsächlichen Release. Für die Linderung von RSI-Symptomen war es hilfreich, aber der Zeitspar-Effekt wird meiner Meinung nach oft übertrieben.
Ich wurde gefragt, ob man Code wirklich unbedingt reviewen müsse. Ich mache meist eher Spot-Reviews von AI-Ergebnissen, lasse die Spezifikationsdokumente von AI schreiben und übernehme dann selbst die abschließende gründliche Prüfung und das Testen. Tatsächlich reviewe ich den Großteil des Codes in Open-Source-Bibliotheken auch nicht von Anfang an selbst.
Dahinter steckt die Annahme: „Code, den ich selbst geschrieben habe, muss ich nicht noch einmal aus einer anderen Perspektive prüfen.“ In Wirklichkeit bin aber auch mein zukünftiges Ich ein potenzieller Leser des Codes. AI-Coding erzwingt diese Denkweise geradezu: klare Akzeptanzkriterien festlegen und dann über Tests und konsistente Regeln verifizieren. Das führt letztlich zu einer robusteren Entwicklungskultur mit besserer Nachvollziehbarkeit.
Mit Claude Code ist Bug-Debugging so, dass, wenn man zuerst Tests schreibt, AI den Fehler in wenigen Minuten behebt, und das ist inzwischen Alltag. Seit der Einführung der neuen Suchfunktion lassen sich sogar komplexe Aufgaben in 5 Minuten erledigen; die Zeitersparnis an dieser Stelle ist subjektiv sehr deutlich spürbar.
Als Mittel gegen RSI-Symptome würde ich außerdem empfehlen, die Arme immer warm zu halten.
Es wurde die Frage aufgeworfen: „Ich möchte nicht alles über ein dialogbasiertes Interface erledigen; gibt es Beispiele für eine UI mit Hybridansatz?“
Generative-AI-Coding-Tools beschleunigen nur die einfachen Teile der Arbeit und machen die schwierigen Teile eher noch schwieriger. Tatsächlich nimmt das eigentliche Schreiben von Code gar nicht so viel Zeit ein; selbst wenn genau dieser Teil 100-mal schneller würde, würde sich die Gesamtproduktivität nicht dramatisch verändern. Deshalb möchte ich dafür nicht extra Zeit investieren.
Wer einen bestimmten Stack und Problemraum bereits vollständig durchdringt, braucht möglicherweise überhaupt kein Tool und muss auch nichts mehr lernen. Diese Logik ist aber in der Realität wenig hilfreich. Am Ende ist die Toolwahl eine Frage der persönlichen Optimierung.
Ich lasse AI Algorithmen schreiben, Ursachen in Code erklären, API-Aufrufe erstellen oder bestimmte Funktionen implementieren. Es ist nicht immer kompletter Code, aber zusammen mit dem Debugger nutze ich das zunehmend häufiger.
Die scherzhafte Frage: Bist du vielleicht Klempner?
Die Stelle des Autors, wonach das Review von fremdem Code genauso viel oder sogar mehr Zeit kosten kann wie das eigene Schreiben, konnte ich gut nachvollziehen; ich habe selbst Erfahrung mit präzisen Code-Reviews wie bei Security-Audits. Wenn AI sich aber auf extrem einfache Routinearbeit spezialisiert, könnte vielleicht eine umfassende Prüfung wie bei einem eBPF-Verifier ausreichen, ohne dass man den Code Zeile für Zeile ansehen muss. Bei zu komplexen Problemen lehne ich den PR einfach ab. Bei einfachem, repetitivem Code muss ein Mensch vielleicht gar nicht mehr alles akribisch abnehmen.
Trotzdem frage ich mich, ob das wirklich effizient ist. Wenn man Dutzende PRs öffnet und am Ende nur einen durchlässt, wäre der Code eines Kollegen vermutlich deutlich vertrauenswürdiger. Eine Struktur, die nur Zeit, Geld und Umweltressourcen verschwendet, halte ich nicht für wünschenswert.
Wenn es wirklich nur um eine „repetitive Go-Funktion“ geht, frage ich mich schon, ob dieser Code überhaupt geschrieben werden musste. Bei ineffizientem und schlecht wiederverwendbarem Code, den man mit ein oder zwei Zeilen einer gängigen Bibliothek erledigen könnte, sehe ich keinen Grund, dafür extra AI einzusetzen.
Für Menschen, die schneller lesen als schreiben, ist GenAI nützlich; wer umgekehrt schneller schreibt, braucht es eher nicht.
Es wurde die Frage gestellt, warum von AI geschriebener Code anders geprüft werden sollte als von Menschen geschriebener Code.
Für repetitive und einfache Aufgaben reichen oft auch IDE-Template-Bindings und automatische Variablenvervollständigung, und dieser Ansatz ist kostenlos.
In der Diskussion über den Vergleich zwischen Praktikanten und AI-Coding-Assistenten hieß es: Ein Praktikant lernt echten Code, das Geschäft und die Systemhistorie, während man AI den Kontext immer wieder neu erklären muss. Diese Grenze besteht weiterhin.
Wichtige Kontexte könne man in mdc-Dateien speichern, sodass auch der nächste Verantwortliche darauf zugreifen kann; aus dieser Sicht verbessert sich sogar die Dokumentation und die Beständigkeit von Wissen.
Bei manchen LLMs ist genau das der Grund, warum System-Prompts auf 14k Länge anwachsen.
Ein Praktikant kümmert sich oft wirklich.
Es wäre auch möglich, wichtigen geschäftlichen Kontext einfach in den System-Prompt zu packen.
Aktuelle AI-Modelle lernen im Kern nur Muster aus bestehenden Daten. Sie kombinieren Vorlagen erfolgreicher Fälle, statt von Grund auf neue Lösungen herzuleiten. Wenn sie ein Problem sehen, suchen sie eher nach der ähnlichsten bisherigen Erfahrung, statt von Prinzipien aus neu zu denken. Menschliche Experten sind stark in First-principles, also in logischen Ansätzen aus grundlegenden Prinzipien, womit AI Schwierigkeiten hat. AI priorisiert Ähnlichkeiten und liefert deshalb oft schematische Lösungen; besonders deutlich werden ihre Grenzen in Bereichen, die Innovation erfordern oder in denen gewohnte Muster nicht greifen. Auch mit context poisoning gehen Menschen deutlich effizienter um.
Ich erwarte von AI im Bereich generierter Codes nicht allzu viel, aber bei repetitiver und langweiliger Boilerplate-Arbeit ist AI N-mal schneller, gefühlt also um ein Vielfaches. Ein konkretes Beispiel aus meiner Praxis: Ich habe ChatGPT um ein Beispiel für eine modalbasierte Struktur mit React Context gebeten, und es hat Hooks, Provider und die ganze zugehörige Struktur sofort ausgegeben. Das hat mir direkt etwa 30 Minuten gespart; für solche repetitiven Aufgaben sind 20 Dollar im Monat überhaupt nicht verschwendet.
In solchen Fällen nimmt man oft auch einfach Beispiele aus der Bibliotheksdokumentation und verwendet sie, und in 5 Minuten kann man die allernotwendigste Minimalimplementierung selbst fertigstellen. Generierter Code liefert aber meist gleich eine Gesamtlösung für die aktuelle Situation, was spätere schrittweise Strukturverbesserungen und Refactorings eher unbequem macht.
Auch ich nutze AI vor allem für Boilerplate oder ad-hoc-Skripte. Wirklich komplexe reale Probleme würde ich AI noch nicht vollständig überlassen. Besonders bei Problemen, die tief in ein System hineingehen, muss der Mensch selbst ran, und die dabei gewonnenen Einsichten sind wichtig. Je größer das Projekt und je stärker die Elemente miteinander verflochten sind, desto deutlicher spüre ich die Grenzen von AI.