Die Integration von Künstlicher Intelligenz und insbesondere von großen Sprachmodellen (Large Language Models, LLMs) in den Programmieralltag hat in den letzten Jahren für enormes Aufsehen gesorgt. Viele Entwicklerinnen und Entwickler sehen in diesen Technologien die Zukunft der Softwareentwicklung, in der repetitive Aufgaben automatisiert und kreative Prozesse effizienter gestaltet werden können. Doch trotz aller Begeisterung und technischer Fortschritte zeigen sich nach intensiver Nutzung dieser Systeme auch gravierende Einschränkungen – besonders wenn es um komplexe Projekte und langfristige Wartbarkeit geht. Nach mehreren Monaten intensiver Arbeit mit LLMs in einem realen Softwareprojekt habe ich für mich entschieden, wieder verstärkt auf meine eigenen Fähigkeiten und traditionelle Methoden zurückzugreifen. Dieses Umdenken war nicht nur eine bewusste Entscheidung für mehr Kontrolle und Qualität, sondern auch ein Schritt hin zu nachhaltigerem und durchdachtem Codieren.
Mein Projekt begann mit der dringenden Notwendigkeit, die bestehende Infrastruktur meines SaaS-Angebots grundlegend zu überarbeiten. Die alte Kombination aus PHP und MySQL war schlicht nicht mehr geeignet, um die neuen Anforderungen zu erfüllen. Gleichzeitig bot die rasante Entwicklung von KI-gesteuerten Codierungswerkzeugen die Möglichkeit, kreative und innovative Ansätze zu verfolgen. Ich entschied mich, anstatt direkt zu programmieren, zunächst eine Rolle als Produktmanager einzunehmen und gemeinsam mit einer KI, genannt Claude, die beste Herangehensweise zu erarbeiten. Dieses Vorgehen ermöglichte es mir, Ziele und Anforderungen präzise zu formulieren und einen Plan zu entwickeln.
Die Wahl fiel auf Go und Clickhouse – zwei Technologien, mit denen ich zuvor wenig Erfahrung hatte, aber die in Kombination vielversprechend erschienen. Nachdem das Konzept stand, begann die rein praktische Phase. Mit Hilfe des Tools Cursor Notepads fütterte ich das LLM mit umfangreichem Kontext über bestehende Strukturen, geplante Ziele und funktionale Anforderungen. Das System generierte daraufhin den ersten Code. Anfangs war ich mit den Resultaten zufrieden: Der Code funktionierte, wenn auch nicht immer optimal strukturiert.
Mein Fokus lag anfangs auf Geschwindigkeit, um den Kunden schnell neue Features anbieten zu können, da ich wusste, dass jeder Tag Verzögerung Umsatzeinbußen bedeutete. Doch bald kamen die ersten Schwierigkeiten. Fehler und unvorhergesehene Probleme stellten meine Geduld auf die Probe. Das Gefühl, eigentlich nah am Ziel zu sein, wurde immer wieder durch neue Rückschläge getrübt. Ursprünglich schob ich diese Herausforderungen auf meine fehlende Erfahrung mit Go und Clickhouse.
Doch selbst mit wachsender Expertise reichten die Antworten der KI immer weniger aus. Cursor reagierte zwar auf Fehlermeldungen mit vorgeschlagenen Fixes, doch diese führten oft zu neuen Problemen an anderer Stelle. Je komplexer die Fehler wurden, desto weniger hilfreich erwiesen sich die KI-Unterstützung und ich begann, den Code intensiver selbst zu begutachten. Meine Erfahrung aus 15 Jahren Softwareentwicklung half mir dabei, die Zusammenhänge besser zu verstehen. Obwohl ich Go und Clickhouse nicht durch und durch kannte, wusste ich, worauf es bei sauberer Softwareentwicklung grundsätzlich ankommt.
Parallel zur Fehlerbehebung bildete ich mich gezielt fort, indem ich Dokumentationen, Fachartikel und Tutorials studierte. Mit zunehmendem Wissen stellte ich auch anspruchsvollere Fragen an die KI und hinterfragte deren Antworten kritisch. Es kam der Punkt, an dem ich mir bewusst Zeit für eine gründliche Code-Review nahm. Diese Analyse offenbarte eine chaotische Codebasis, die dem Stil von mehreren unerfahrenen Entwicklern glich, die in Isolation gearbeitet hatten. Methodenjobbezeichnungen waren uneinheitlich, Parameter wurden unterschiedlich benannt und mehrfach vorgefunden, Konfigurationsdateien wurden inkonsistent eingebunden.
Trotz der hohen Menge an Kontext, die ich der KI beim Programmieren gab, gelang es nicht, eine kohärente und wartbare Struktur zu erhalten. Durch dieses Studium der eigenen Arbeit wurde klar, dass ich mein Vorgehen ändern musste. Als erfahrener Softwareentwickler durfte ich mich nicht darauf verlassen, dass mir Technik die komplette Arbeit abnimmt. So begann ich, die problematischsten Codeabschnitte selbst zu überarbeiten und Umstrukturierungen vorzunehmen – auch wenn ich dadurch langsamer vorankam. Aus dem „Ich lasse das AI-System schreiben und passe dann an“-Ansatz wurde wieder handfeste Entwicklerarbeit, unterstützt von gezieltem KI-Einsatz als hilfreiches Werkzeug für spezifische Aufgaben.
Seit dieser Umstellung ist das Debugging merklich einfacher geworden. Ich habe nicht mehr das Gefühl, Code zu verwenden, dessen genaue Funktionsweise ich nicht verstehe. Zwar verliere ich manchmal Zeit im Vergleich zu schnellen KI-generierten Lösungen, aber die Qualität und Wartbarkeit meiner Software ist deutlich besser. KIs nutze ich vor allem für klar umrissene Aufgaben, etwa Parameter umbenennen oder Pseudocode in Go übertragen. Der schwierigste Kampf in diesem Prozess war wohl, der Versuchung zu widerstehen, die KI ständig für alles Mögliche zu nutzen.
Die Versuchung, zehn Dateien binnen Minuten erstellen zu lassen, ist immens. Doch durch den bewussten Verzicht darauf halte ich meine kognitiven Fähigkeiten auf Trab. Ich erkenne wieder die Wichtigkeit von Planungsphasen mit Stift und Papier. Ich bin wieder der schöpferische Kopf, nicht die Maschine. Diese Erkenntnisse machen mir auch Sorgen im Hinblick auf andere, vor allem weniger erfahrene Entwicklerinnen und Entwickler oder solche, die wenig Programmierkenntnisse besitzen.
Für sie sind heutige KI-Coding Tools wie Cursor oft eine große Herausforderung. Der Prozess ähnelt dem verzweifelten Abschreiben von Fehlermeldungen in einen Chat und dem Erhalten trotzdem missverständlicher Lösungen, die den Code verschlimmern. „Vibe Coding“ – das Programmieren mit KI ohne fundiertes Verständnis – führt oft nicht zu stabilen, produktionsreifen Ergebnissen. Trotz zahlreicher Versuche, verschiedene Modelle und Workflows auszuprobieren, bleibt meine Erfahrung: Die KI schafft viele Aufgaben nicht zuverlässig. Selbst die neuesten und größten Modelle scheitern häufig bei herausfordernden und komplexen Anwendungsfällen wie der Erstellung komplexer SQL-Abfragen für umfangreiche Datenbanken mit großen Datenmengen.
Außerdem ist das Tooling in seiner Performance inkonsistent. Selbst wenn man einen idealen Workflow gefunden hat, lässt dessen Qualität oft schnell nach oder funktioniert nur, wenn sich die Anforderungen nicht ändern. Ich schreibe diese Worte aus Überzeugung und Begeisterung für Technik, nicht aus Frustration oder Angst vor Veränderung. Die KI-Technologie wird sich weiterentwickeln und verbessert werden. Dennoch befinden wir uns derzeit in einer Übergangsphase, in der die Systeme zwar beeindruckend wirken, aber in der Praxis vielen Entwicklerinnen und Entwicklern noch mehr Probleme bescheren als lösen.
Die Verlockung, effiziente Raumschiffe zu nutzen, deren Steuerung jedoch geheimnisvoll und uneindeutig ist, beschreibt die Situation gut. Man kann mit Aufwand und Geduld große Erfolge erreichen, doch manchmal wäre der schlichte Fußweg – das sorgfältige, disziplinierte Programmieren mit Verstand – am Ende die bessere Option gewesen. Nicht zuletzt erleben wir auch eine Art kollektives Gaslighting durch Selbstvermarktung, Benchmark-Hypes und Aussagen von Unternehmen, die ihre Tools als revolutionär anpreisen. Tatsächlich sind Erfahrungen mit denselben KI-Modellen am selben Tag extrem unterschiedlich – von genial bis frustrierend. Gründe hierfür liegen vielleicht in Hardware-Beeinträchtigungen, undurchsichtigen Algorithmen und der schieren Komplexität der Systeme.
