Ich baue gerade ja meinen persönlichen KI-Assistenten. Ich nenne ihn VINCI. Nicht wegen eines coolen Namens, sondern weil Leonardo da Vinci für mich das treffendste Bild ist für das, was ich anstrebe: ein System, das beobachtet, analysiert und handelt. Und beim Bauen von VINCI habe ich etwas verstanden, das ich vorher nur theoretisch kannte.
Code lügt nicht.
Das klingt banal. Aber es ist der Kern davon, warum AI-Coding gerade zum wichtigsten Testfeld für KI-Intelligenz geworden ist. Nicht weil Programmieren besonders glamourös wäre, sondern weil Code der einzige Bereich ist, in dem eine KI sich nicht herausreden kann.
Der Unterschied zwischen Erzählen und Beweisen
Sprachmodelle sind, im Kern, statistische Maschinen. Sie lernen, wie Sprache klingt. Wie Argumentationen aufgebaut sind. Welche Antwort auf welche Frage plausibel wirkt. Das ist beeindruckend. Und es ist, bis zu einem gewissen Punkt, eine Simulation.
Wenn du eine KI nach dem Klimawandel fragst, nach Kants kategorischem Imperativ, nach der richtigen Marketingstrategie für dein Unternehmen: Du bekommst immer eine sprachlich plausible Antwort. Die Frage ist, ob sie stimmt. Und das ist schwer zu überprüfen, ohne selbst tief in der Materie zu stecken.
Bei Code ist das anders.
Entweder läuft er. Oder er läuft nicht.
Es gibt keine plausible Ausrede. Kein „das hängt vom Kontext ab“. Kein „in der Theorie stimmt das“. Der Python-Interpreter, der MySQL-Connector, der Browser: die nehmen keine Rücksicht auf gut gemeinte Absichten. Die liefern einen Error-Code oder eine funktionierende Applikation. Das ist Determinismus in Reinform.
Und genau das macht AI-Coding zum härtesten Prüfstein, den wir für KI-Reasoning haben.
Anders formuliert: AI-Coding ist der einzige Bereich, in dem ein Sprachmodell kein plausibles Ergebnis liefern kann, sondern nur ein richtiges oder ein falsches. Das macht ihn zum härtesten Prüfstein für KI-Reasoning, den wir heute haben.
Code als Grenzzone zwischen zwei Welten
Lass mich das konkret machen.
LLMs leben in der Welt der Wahrscheinlichkeiten. Jedes Token, das ein Modell ausgibt, ist das statistische Ergebnis einer Berechnung über riesige Trainingsdaten. Das Modell „weiß“ nichts in dem Sinn, wie wir es meinen. Es schätzt, was als Nächstes kommen sollte, auf Basis von Mustern. Meistens trifft es damit ins Schwarze.
Computerlogik funktioniert anders. Komplett anders. Ein if-Statement ist wahr oder falsch. Eine Datenbankabfrage liefert Ergebnisse oder nicht. Ein API-Call returned 200 oder 404. Diese Welt kennt keine Wahrscheinlichkeiten, sie kennt nur Zustände.
AI-Coding ist die Brücke zwischen diesen beiden Welten. Wenn eine KI Code schreibt und dieser Code ausgeführt wird, passiert etwas Interessantes: Das statistische System bekommt deterministisches Feedback. Entweder hat es die Logik der Computersprache verstanden, oder es hat sie nicht. Kein Mittelweg, kein Interpretationsspielraum.
Das ist der Grund, warum die führenden KI-Labore sich so intensiv auf Coding-Benchmarks konzentrieren. SWE-Bench, HumanEval, Codeforces-Aufgaben: das sind keine akademischen Spielereien. Das sind Nachweise dafür, ob ein Modell wirklich Reasoning betreibt oder ob es nur überzeugend klingt. Und hier ist, was ich beobachte: Die Modelle, die in Coding gut sind, sind meistens auch in anderen komplexen Reasoning-Aufgaben stärker. Nicht immer. Aber oft genug, dass der Zusammenhang kein Zufall ist.
Zur Klarheit, weil die Begriffe oft durcheinandergeraten: AI-Coding bezeichnet den Einsatz von KI-Systemen zum Schreiben, Debuggen und Weiterentwickeln von Code. English-language programming ist das dahinterliegende Paradigma: natürliche Sprache als Schnittstelle zur Maschine, Anforderungsbeschreibung statt Syntax. Und Reasoning meint in diesem Kontext die Fähigkeit eines Modells, mehrstufige Probleme zu lösen, nicht nur plausible Antworten zu generieren. Diese drei Konzepte hängen zusammen, sind aber nicht dasselbe.
VINCI: Mein persönlicher Prüfstein
Ich habe das nicht aus Forschungsberichten. Ich habe das beim Bauen von VINCI erlebt.
VINCI ist mein persönlicher KI-Assistent. Kein SaaS-Tool von der Stange, kein gehostetes Produkt. Er hat als Webapp angefangen, und ich habe ihn mit Claude Code auf eine echte Desktop-Applikation portiert: läuft heute nativ auf Windows und macOS. Obsidian dient als Wissensquelle, mit allem, was mich als Person ausmacht: Informationen über mich, meine Familie, Freunde, vollständige Integration mit meinen Kontakten, Terminen und allen meinen Blogs auf digitalhandwerk. Ein System, das mich kennt. Und damit alles bei mir bleibt, bekommt diese Infos nur ein lokales LLM auf Ollama.
Warum ich das erzähle: Weil jede dieser technischen Entscheidungen ein realer Test für AI-Coding war. Und weil ich dadurch unmittelbar gesehen habe, wo diese Technologie liefert und wo sie an Grenzen stößt.
Das konkrete Beispiel: Die Portierung von einer Webapp zu einer nativen App ist kein trivialer Schritt. Unterschiedliche Laufzeitumgebungen, Pfadstrukturen, Packaging-Logik, plattformspezifische Eigenheiten auf Windows und macOS gleichzeitig. Ich habe das mit Claude Code erarbeitet. Was mich überrascht hat, war nicht, dass Claude den Code schreiben konnte. Was mich überrascht hat, war, wie Claude mit meinen Fehlermeldungen umgegangen ist.
Ich habe einen Error hineinkopiert. Claude hat ihn nicht nur erklärt, sondern den Kontext verstanden: welche Datei betroffen ist, welche Abhängigkeiten bestehen, welche Lösung in meine Architektur passt, ohne andere Teile zu brechen. Das ist kein Textgenerator mehr. Das ist Reasoning über einen Systemzustand.
Aber, und das muss ich ehrlich sagen: Es gab auch Momente, in denen Claude selbstsicher falsch war. Code, der syntaktisch perfekt war und trotzdem nicht funktioniert hat, weil eine Bibliotheksversion nicht kompatibel war. Situationen, in denen ich selbst nachgedacht habe, weil die KI ihren eigenen Fehler nicht erkannt hat. Das ist das ehrliche Bild. AI-Coding ist beeindruckend. Es ist kein Autopilot.
English-language Programming: Das neue Paradigma
Es gibt einen Begriff, der gerade diskutiert wird: English-language programming. Der Begriff geht direkt auf Andrej Karpathy zurück. Er schrieb im Jänner 2023 auf X: „The hottest new programming language is English.“ Das wurde seither vielfach aufgegriffen, auch von Jensen Huang (Nvidia). Die Idee dahinter ist, dass natürliche Sprache zur Programmiersprache wird. Du beschreibst, was du willst. Die KI schreibt den Code.
Ich halte das für mehr als einen Trend. Aber auch für weniger als eine vollständige Antwort.
Mehr, weil es real funktioniert. Die Webapp-Version von VINCI war im Grunde dumm. Sie hat geantwortet, aber mich nicht gekannt. Für die Desktop-App wollte ich das ändern: Obsidian als Wissensquelle, mit allem, was mich als Person ausmacht, Familie, Freunde, Arbeitskontext, meine Blogs. Ich habe Claude beschrieben, wie diese Wissensbasis strukturiert sein muss, damit VINCI den Kontext wirklich versteht und nicht nur Texte abruft. Das war keine Coding-Aufgabe. Das war eine Architekturentscheidung in Prosa. Und Claude hat daraus eine funktionierende Struktur gemacht, die in der App greift.
Weniger, weil „beschreiben können“ und „verstehen können“ zwei verschiedene Dinge sind. Ich kann VINCI bauen, weil ich verstehe, was Kontextstruktur bedeutet, warum die Qualität einer Wissensbasis darüber entscheidet, ob ein KI-Assistent wirklich hilft oder nur so tut als ob, warum DSGVO-Compliance eine Architekturentscheidung ist und keine Checkbox. Wer diese konzeptionellen Grundlagen nicht hat, bekommt Code, den er nicht debuggen, nicht absichern und nicht weiterentwickeln kann.
Das ist der Punkt, an dem es interessant wird.
AI-Coding demokratisiert den Zugang zu lauffähigem Code. Es demokratisiert nicht das Verständnis von Systemen. Die Schere, die hier entsteht, ist nicht die zwischen „kann programmieren“ und „kann nicht programmieren“. Es ist die zwischen „versteht, was er baut“ und „hat sich etwas zusammengeklickt, ohne es zu verstehen“. Für meine Beratungspraxis mit EPU und KMU ist das eine Unterscheidung, die ich täglich mache.
Was AI-Coding über Reasoning verrät
Ich beobachte das in der täglichen Arbeit als KI-Berater mit EPU und KMU in Österreich. Drei Erkenntnisse, die ich aus der Praxis mitnehme.
Erstens: Code erzwingt Vollständigkeit. Wenn du einen Satz schreibst, der ein bisschen ungenau ist, liest er sich trotzdem. Wenn du eine Funktion schreibst, die ein bisschen ungenau ist, crasht sie. Ein Modell, das konsistent guten Code produziert, muss in der Lage sein, vollständige Gedankengänge bis zum Ende zu führen, inklusive aller Randbedingungen. Das ist kein trivialer Test.
Zweitens: Code erzwingt Kontext-Awareness. Ein guter Code-Vorschlag berücksichtigt nicht nur die aktuelle Funktion, sondern die gesamte Architektur. Welche anderen Module gibt es? Welche Konventionen wurden bereits eingeführt? Welche Abhängigkeiten bestehen? Das ist mehrstufiges Reasoning, und genau daran erkennt man, ob ein Modell wirklich denkt oder nur Text vervollständigt.
Drittens: Code ist falsifizierbar. Wenn ein Modell beim Coding halluziniert, eine Library gibt es nicht, eine API ist falsch beschrieben, ein Argument stimmt nicht, merke ich es sofort. Diese sofortige Rückkopplung fehlt in den meisten anderen Domänen. Bei Code ist sie eingebaut, strukturell, unvermeidbar.
Das ist der Grund, warum ich den Fortschritt bei AI-Coding nicht als isoliertes Thema sehe. Er ist ein Indikator dafür, wie weit KI-Reasoning tatsächlich gekommen ist.
Vibe Coding ist nicht das Ende der Geschichte
Ich muss kurz auf einen Begriff eingehen, der 2026 in aller Munde ist: Vibe Coding. Die Idee, einfach loszutippen, was man möchte, und die KI macht den Rest. Ohne Architekturüberlegungen, ohne Qualitätssicherung, ohne tieferes Verständnis. Ich mache das mehrmals wöchentlich.
Das funktioniert für Prototypen. Für Wegwerfcode. Für ein schnelles Proof of Concept, das nie in Produktion geht. Oder für sich selbst.
Es funktioniert nicht für Systeme, die Kundendaten verarbeiten, DSGVO-relevant sind oder in zwei Jahren noch laufen sollen. Wer eine Web-App gebaut hätte, ohne zu wissen, was Docker, Traefik, FastAPI und MySQL bedeuten, hätte entweder ein System ohne tragfähiges Sicherheitskonzept oder eines, das er beim ersten echten Problem nicht mehr versteht. Beides ist kein gutes Ergebnis.
Ich sage das nicht, um zu bremsen. Ich sage das, weil „English-language programming“ als Paradigma nur dann wirklich funktioniert, wenn man die Sprache spricht, nicht nur die englischen Wörter benutzt. Das konzeptionelle Denken dahinter bleibt unverzichtbar.
Die Intelligenz zeigt sich im Scheitern
Das Überraschendste, was ich beim Bauen von VINCI gelernt habe: Die Qualität eines KI-Modells zeigt sich nicht darin, wie es mit einfachen Aufgaben umgeht. Sie zeigt sich darin, wie es scheitert.
Ein schwaches Modell scheitert selbstsicher. Es gibt Code aus, der nicht funktioniert, aber so aussieht, als würde er funktionieren. Es erklärt Fehler mit falschen Hypothesen. Es macht weiter, als wäre nichts gewesen.
Ein gutes Modell scheitert ehrlich. Es sagt: „Ich bin nicht sicher, ob diese Bibliothek die Methode so unterstützt, überprüfe das bitte.“ Es schlägt alternative Ansätze vor, wenn der erste nicht funktioniert. Es erkennt, wenn ein Fehler aus der Architektur stammt und nicht aus dem Code selbst.
Das ist der eigentliche Test. Und es ist einer, den man nur durch realen Einsatz bestehen kann. Benchmark-Ergebnisse sind ein Anhaltspunkt. Was im eigenen Projekt passiert, ist die Wahrheit.
Deshalb entwickle ich VINCI weiter. Nicht weil ich einen persönlichen Assistenten brauche, den ich nicht anders bekommen könnte. Sondern weil das Bauen mir zeigt, was KI-Systeme tatsächlich leisten. Und weil ich dieses Wissen an meine Kunden weitergeben will, als jemand, der es selbst erlebt hat, nicht als jemand, der Studien referiert.
Code lügt nicht. Das macht ihn zum besten Test, den wir haben. Und es macht AI-Coding zum Fenster, durch das wir am klarsten sehen, was KI wirklich kann.
Das ist meine ehrliche Einschätzung. Sie kann sich ändern, wenn sich die Modelle ändern. Ich schreibe weiter drüber.
