Overfitted Promises: KI in der Coding-Forschung – Hype vs. Evolution

Auf einen Blick

• Die These: Aktuelle KI-Coding-Tools funktionieren eher wie Alchemie als wie etablierte Wissenschaft – Trial and Error mit Black-Box-Ergebnissen.
• Das Gute: Das ist nicht negativ. Newtons alchemistische Forschungen führten zur modernen Chemie.
• Der strategische Punkt: Sie müssen verstehen, wo KI wirklich produktiv macht (Boilerplate, Bug Fixes, Dokumentation) und wo sie scheitert (Architekturentscheidungen, komplexe Sicherheit, domänenspezifische Logik).
• Die Konsequenz: Nicht alle Teams, nicht alle Aufgaben eignen sich gleich gut für KI-Coding-Tools. Die Einführung braucht Strategie, nicht nur Enthusiasmus.

Zur Einordnung: Dieser Beitrag ist ein opinionated vision piece, kein Playbook. Die Technologie bewegt sich so schnell, dass es nicht ehrlich wäre, hier endgültige Best Practices zu formulieren. Was Sie lesen, ist eine Hypothese — und vor allem ein Plädoyer dafür, frische Bewertungsrahmen zu entwickeln, statt bestehende Software-Engineering-Routinen einfach mit "und jetzt mit KI" zu umetikettieren. Die Tools, die Sprache, die Anwendungsfälle und die Erwartungshaltung in den Vorständen sind neu — die Brille, mit der wir das beurteilen, sollte es auch sein. Wer das kritisch liest und mitdenkt, ist hier richtig. Wer eine fertige Roadmap erwartet, wird unzufrieden bleiben — das ist Absicht.

Bei neurons&neckar 2025 habe ich diese provokante These aufgestellt: Die aktuellen KI-Coding-Tools ähneln der Alchemie mehr als der modernen Wissenschaft. Aber das ist weder reine Kritik noch Hype. Es ist eine nüchterne Bestandsaufnahme – und ein Blick darauf, wie Ihre Entwicklungsorganisation damit umgehen sollte.

Newton: Zwischen Alchemie und Revolution

Isaac Newton schrieb über eine Million Worte über Alchemie – größtenteils zu seinen Lebzeiten unveröffentlicht. Er suchte den Stein der Weisen, um Metalle zu verwandeln und Unsterblichkeit zu erlangen. Er experimentierte mit "Diana's Tree" und glaubte, dass Metalle "wachsen" könnten und lebensähnliche Eigenschaften hätten.

Sein Fazit: Das Ziel verfehlte er. Die Folgen aber waren enorm. Seine alchemistischen Experimente waren methodisch und detailliert dokumentiert. Sie führten zu wissenschaftlichen Durchbrüchen in Chemie, Optik und Thermodynamik. Newton brauchte die Alchemie, um die Wissenschaft zu erfinden.

Das ist das Muster, das ich heute bei KI-Coding-Tools sehe: Trial and Error mit unsichtbarem Mechanismus – aber nicht ohne Wert.

Die Parallele: AI-Coding heute

Das Problem, das ich in Unternehmen beobachte: Man führt GitHub Copilot oder Cursor ein, erwartet einen 30%-Produktivitätssprung und ist dann verwirrt, wenn die Realität komplexer ist.

Aktuelle KI-Coding-Tools funktionieren wie Alchemie, nicht wie etablierte Wissenschaft:

• Sie verlangen nach den richtigen Worten (Prompt Engineering), aber die Regel ist unsichtbar
• Sie liefern erstaunliche Ergebnisse bei simplen Aufgaben, versagen aber bei subtilen Anforderungen
• Warum ein Prompt funktioniert oder nicht, lässt sich nicht systematisch erklären
• Man muss experimentieren, anpassen, neu versuchen – Trial and Error

AI Coding ist ein neuer Layer mit dem wir noch lernen müssen umzugehen, ihn einzuhegen.

Aber es gibt ein Muster. Und sobald wir das Muster verstehen – sobald wir wissen, wo diese Tools funktionieren und wo nicht – können wir sie gezielt einsetzen.

Wo KI-Coding-Tools wirklich funktionieren – und wo nicht

Die gute Nachricht: Es gibt ein Muster. Nicht alle Aufgaben sind gleich.

Was funktioniert konsistent:

• Boilerplate und Standard-Patterns: Repetitive Strukturen, die überall gleich aussehen
• Code Completion und Vorschläge: Intelligente Auto-Vervollständigung bei 80% Ähnlichkeit zu Trainingsdaten
• Einfache Bug Fixes: Offensichtliche Fehler (Typos, falsche Funktionsaufrufe, einfache Logikfehler)
• Dokumentation und Erklärungen: Code in Prosa umwandeln; Anfängern Konzepte erklären
• Triviale Konvertierungen: Code zwischen ähnlichen Sprachen übersetzen (Python ↔ JavaScript)

Hier wird es alchemistisch – und Sie müssen aufpassen

• Architektur-Entscheidungen: Wann Sie Microservices vs. Monolithen brauchen, erfordert Geschäftsverständnis, nicht Code-Gen
• Sicherheit: Sicherheitslücken sind oft kontextabhängig. Ein generierter Token-Handler kann aussehen, aber nicht sein, ob er sicher ist
• Performance-Optimierungen: Subtile Verbesserungen brauchen Systemverständnis; KI kann Variationen vorschlagen, nicht Warum verstehen
• Domänenspezifische Logik: Banking-Regeln, Compliance, Geschäftslogik – das ist etwas, das kein LLM von außen vollständig erfassen kann
• Debugging komplexer Probleme: Wenn zehn Systeme zusammenhängen und eines funktioniert nicht, ist systematisches Denken nötig, nicht Pattern-Matching

Ein strategisches Beispiel: Das Problem der agentic AI

Ein weiteres Muster zeigt sich bei KI-Agenten (ausführliche Diskussion siehe Post "Agentic AI"). Automatisierte Systeme, die eigenständig handeln sollen, brauchen klare Guardrails. Das ist dasselbe Problem: Menschen müssen die Grenzen definieren, wo die KI handeln darf und wo nicht. Die KI selbst wird das nicht richtig entscheiden, ohne menschliche Vorgaben.

Das gilt auch für Code-Generierung: Eine KI kann nicht selbst entscheiden, ob generierter Code "gut genug" ist für Production. Sie kann schnell iterieren, aber die letzte Entscheidung – die kritische Entscheidung – bleibt bei Menschen.

Die Evolution: Von Alchemie zur Wissenschaft

Newton brauchte 50 Jahre, um von Alchemie zur Wissenschaft zu gelangen. Wir werden schneller sein. Aber wir sind noch nicht da.

Die Richtung ist klar:

• Bessere Erklärbarkeit: Tools, die aufzeigen, warum eine Suggestion funktioniert (oder warum nicht)
• Spezialisierung: Nicht ein General-LLM für alles, sondern spezialisierte Modelle für SQL, Sicherheit, Testschreibung, etc.
• Reproduzierbarkeit: Nicht jedes Mal ein anderes Ergebnis für dieselbe Anfrage
• Messung statt Gefühl: Klare Metriken für Produktivitätssteigerung, nicht nur "fühlt sich schneller an"
• Systematische Qualitätssicherung: Nicht hoffen, dass der generierte Code gut ist, sondern es wissen
• Neue Bewertungsrahmen: Die Frage "funktioniert der Code?" reicht nicht. Wir brauchen Methoden, die ko-evolvierende Mensch-KI-Systeme bewerten — Software-Engineering-Reviews aus der Vor-LLM-Welt sind eine Hilfsbrille, kein passendes Werkzeug

Was das strategisch bedeutet: Vier Heuristiken für die Übergangszeit

Diese vier Punkte sind keine Best Practices — die Technologie ist zu jung, das Material, um Best Practices zu destillieren, ist nicht da. Sie sind Heuristiken, die in der heutigen Phase belastbar sind und in zwölf Monaten neu bewertet gehören.

1. Kartographieren, nicht evangelisieren

Bevor Sie KI-Coding-Tools einführen, müssen Sie wissen: Welche Aufgaben dominieren bei uns? Sind das 70% Boilerplate (große Chancen) oder 70% komplexe Domänenlogik (begrenzte Chancen)? Keine Einheitslösung – unterschiedliche Teams brauchen unterschiedliche Strategien.

2. Mit kleinen Piloten beginnen

Starten Sie mit einem Team, das viel mit Boilerplate und Bug Fixes arbeitet. Messen Sie: Was wird schneller, was nicht? Welche Bugs entstehen? Wo braucht es mehr Reviews? Dann skalieren Sie nur wenn die Bilanz positiv ist.

3. Quality Gates sind nicht optional

Code von KI braucht genauso gute Reviews wie jeder andere Code – nur anders. Nicht "funktioniert es?", sondern "ist der Ansatz sicher?" und "haben wir das so schon mal gemacht, oder ist das neu?". Diese Reviews müssen Ihre Architekten machen, nicht Junior Developer.

4. Risiken einhegen

Manche Codebases sind zu kritisch für KI-Experimente. Sicherheit, Zahlungsverarbeitung, Kernlogik – da gehört KI-generierter Code nicht hin, bis die Tools reifer sind. Das ist nicht Technophobia, das ist Risikomanagement.

Die unbequeme Wahrheit – und die Chance

Die aktuellen KI-Coding-Tools sind overfitted auf ihre heutigen Anwendungen. Das bedeutet: Sie funktionieren hervorragend in ihrem Trainingskorridor (Boilerplate, APIs, simple Patterns) und weniger gut, je weiter Sie sich entfernen.

Das ist nicht böse. Das ist Physik.

Das ist, was mit KI-Coding heute passiert. Wir haben die "alchemistische" Phase. Wir sind mitten in der Entdeckung. Die Unternehmen, die das jetzt verstehen – die ihre Teams ermutigen, systematisch zu experimentieren, die Quality Gates einführen, die lernen, wo diese Tools sind und wo nicht – die werden die Vorteile nutzen, wenn die Wissenschaft auftaucht.

Die anderen werden sich später fragen, warum sie so viel Zeit verloren haben.

Fazit: Unterscheiden Sie Hype von Chance

Ich höre oft in Vorständen: "Wir müssen in KI investieren" oder "Alle nutzen Copilot schon." Das ist Orientierungslosigkeit im Hype. Die richtige Frage ist nicht "Brauchen wir KI-Coding?" sondern "Wo funktioniert KI-Coding wirtschaftlich in unserer Organisation, und wo fügt sie Risiken hinzu?"

Die Antwort unterscheidet sich bei jedem Unternehmen. Und wenn Sie unsicher sind – wenn Sie nicht wissen, wie Sie diese Bewertung machen, welche Tools zu Ihnen passen, wie Sie Ihre Teams einführen ohne Chaos zu erzeugen – dann ist genau das, wofür ich hier bin.