Ich war nie ein richtiger Programmierer. Aber ich war einer. Irgendwie.
Das klingt wie ein Widerspruch, und das ist es auch. Ich habe als Teenager auf einem Commodore VC 20 gelernt, was eine Schleife ist. Ich habe auf dem C64 eigene Programme geschrieben, die damals für mich das Aufregendste der Welt waren. Ich habe auf dem Amiga 1000 in Assembler reingeschnuppert, weil mich die Maschine fasziniert hat, nicht weil mir jemand befohlen hat, es zu tun. Und dann: nichts. Jahrzehntelang.
Bis Vibe Coding kam. Und ich plötzlich gemerkt habe: Ich kann das wieder. Nicht weil ich besser geworden bin. Sondern weil sich verändert hat, was es bedeutet, etwas zu bauen.
Der Anfang: Ein VC 20, eine Zeitschrift und sehr viel Geduld
Wer den Commodore VC 20 kennt, weiß, wie das war. Du hast eine Zeitschrift aufgeschlagen, auf den abgedruckten BASIC-Code gestarrt, und ihn Zeile für Zeile abgetippt. Fehler eingebaut ohne es zu wissen. Stundenlang gesucht. Irgendwann lief das Programm. Kurz. Dann gecrasht.
Aber das Gefühl, wenn es funktioniert hat: das war real.
Ich habe damals nicht „gelernt zu programmieren“ im akademischen Sinn. Ich habe verstanden, wie Maschinen denken. Dass Logik eine Sprache ist. Dass ein Computer exakt das tut, was du sagst, nicht das, was du meinst. Dieser Unterschied ist, glaube ich, der Kern von allem, was danach gekommen ist.
Mit dem C64 wurde es ernster. Ich habe eigene kleine Programme geschrieben: Adressverwaltungen, Spiele, die ich nie zu Ende gemacht habe, Tools für Dinge, die mir wichtig waren. Basic auf dem C64 war direkter, schneller, befriedigender als vieles, was später kam. Dann der Amiga 1000. Ein Computer, der seiner Zeit so weit voraus war, dass das heutige Publikum es kaum glaubt. Und mit ihm: der erste Kontakt mit Assembler. Nicht weil ich ein Hacker werden wollte, sondern weil mich interessiert hat, was tatsächlich unter der Haube passiert, wenn ein Prozessor arbeitet. Ich war kein Experte. Aber ich habe verstanden, worum es geht.
Dann kam das Leben
Und mit dem Leben kamen andere Prioritäten.
Ich habe 1989 meine erste Agentur gegründet. Die Kommunikationsbranche hat mich gefordert, auf eine Art, bei der das Programmieren zur Nebensache wurde. Office-PCs, dann Apple im Büro. Vom Macintosh SE30 über den II fx bis zu den ersten iMacs. Privat vom PowerBook bis zum heutigen MacBook Air M4. Ich war tief im Apple-Ökosystem, habe Photoshop und InDesign auf einem professionellen Level eingesetzt, war zwischen 2005 und 2011 Microsoft MVP für Windows Mobile, habe als Adobe-Trainer am BFI Salzburg gearbeitet, in US-amerikanischen und deutschen Techmagazinen publiziert.
Aber programmiert habe ich nicht mehr. Nicht wirklich.
Das war kein Verlust, den ich aktiv gespürt habe. Die Branche hat sich verändert, ich habe mich verändert, und es gab genug andere Werkzeuge, um das zu tun, was ich tun wollte. Websites gebaut, ja. WordPress konfiguriert, ja. Aber eigenen Code schreiben, eigene Werkzeuge bauen? Das war lange kein Teil meines Alltags mehr.
Bis 2023 ein Begriff auftauchte, der mich sofort elektrisiert hat: Vibe Coding.
Was Vibe Coding eigentlich ist, und was es nicht ist
Zur Klarheit, weil die Begriffe oft durcheinandergeraten:
Vibe Coding bedeutet: Du beschreibst einer KI, was du bauen willst, und du iterierst mit ihr, bis das Ergebnis stimmt. Du schreibst den Code nicht selbst. Aber du steuerst den Prozess: über gute Prompts, klare Anforderungen, ehrliche Fehlerbeschreibungen und die Fähigkeit zu erkennen, wann das Ergebnis tatsächlich das ist, was du wolltest.
Vibe Coding ist nicht: Zaubern. Du sagst „Bau mir eine App“ und es passiert einfach. Das funktioniert für triviale Dinge manchmal. Für alles andere brauchst du Kontext, Struktur und ein Grundverständnis davon, was du baust.
AI-Assisted Coding ist der verwandte Begriff für erfahrene Entwicklerinnen und Entwickler, die KI als Werkzeug einsetzen, nicht als Ersatz für ihr Fachwissen. Der Unterschied zu Vibe Coding: Dort kommt das Fachwissen von der Person. Beim Vibe Coding kommt ein großer Teil des technischen Wissens von der KI, während die Richtung, die Anforderungen und die Qualitätskontrolle von dir kommen.
Andrej Karpathy, ehemaliger KI-Forschungsleiter bei Tesla, hat den Begriff 2025 in einem viel zitierten Post geprägt und beschrieben, wie er ganze Projekte schreibt, ohne noch die Codezeilen selbst zu tippen. Das hat eine Debatte ausgelöst, die bis heute anhält: Ist das echtes Programmieren? Zählt das?
Meine Antwort: Es ist die falsche Frage.
Das ist der Punkt, an dem es für mich interessant wird
Als ich angefangen habe, mit Claude Code mein erstes ernstes Projekt zu bauen, habe ich etwas bemerkt, das mich überrascht hat: Mein Hintergrund war nicht egal. Im Gegenteil.
Ich weiß, wie ein Computer denkt. Ich verstehe, was ein Loop ist, was eine Variable ist, was es bedeutet, wenn Daten in eine Datenbank geschrieben und wieder ausgelesen werden. Ich kenne das Konzept einer API, auch wenn ich keine APIs von Hand schreibe. Ich weiß, was State bedeutet, was ein Event Handler ist, warum eine Datenbankabfrage langsam sein kann. Das alles kommt aus den Jahren auf dem VC 20, dem C64, dem Amiga.
Und dieses Basiswissen macht den Unterschied. Nicht weil ich den Code schreibe, sondern weil ich weiß, was ich verlange, wenn ich ihn beschreibe. Ich mache keine sinnlosen Anfragen. Ich erkenne, wenn eine Lösung technisch fragwürdig ist. Ich kann mit der KI in einer Sprache sprechen, die präzise genug ist, um brauchbare Ergebnisse zu bekommen.
Das ist, denke ich, die eigentliche Kompetenz des Vibe Coders: nicht das Schreiben von Code, sondern das Denken in Systemen. Die Fähigkeit, ein Problem so zu beschreiben, dass eine Maschine es lösen kann, und das Ergebnis so zu beurteilen, dass man weiß, wann es gut genug ist.
Was ich gebaut habe, und warum DSGVO kein optionaler Teil ist
In den letzten Monaten habe ich mehr eigene Software gebaut als in den zwanzig Jahren davor.
VINCI ist mein persönlicher KI-Assistent, zunächst als Webapp gestartet, mittlerweile als native Desktop-Applikation für Windows und macOS, gebaut mit Claude Code, deployed auf meiner eigenen Infrastruktur bei Hetzner mit Coolify. Er kennt meinen Kalender, meine E-Mails, er hat Zugang zu meiner Wissensbasis aus Obsidian. Er ist kein Produkt, das ich verkaufe, er ist ein Werkzeug, das ich für mich gebaut habe, weil kein fertiges Produkt das kann, was ich brauche.
Ein Strom-Dashboard, das live Verbrauchsdaten anzeigt. Ein KMU.DIGITAL-Förderrechner als einbettbares Widget. n8n-Workflows, die meine Morgen-Briefings automatisieren, E-Mails klassifizieren, SEO-Daten über vier Domains überwachen. Nicht alles davon ist elegant. Aber alles davon funktioniert. Und alles davon ist meins.
Was ich dabei nie weggelassen habe: DSGVO.
Ich sage das explizit, weil es in der Vibe-Coding-Community oft ignoriert wird. Wenn du Apps baust, die Nutzerdaten verarbeiten, musst du wissen, welche Daten wo gespeichert werden, wie lange, mit welcher Rechtsbasis. Das ist keine Bürokratie. Das ist Grundanstand gegenüber den Menschen, die dein Werkzeug nutzen. Ich beobachte das seit Jahren in der täglichen Arbeit als KI-Berater mit EPU und KMU in Österreich: Wer DSGVO als nachgelagerten Gedanken behandelt, zahlt die Rechnung später, mit Zinsen.
Genau so ernst nehme ich Code Reviews. Eine KI schreibt nie perfekten Code. Manchmal schreibt sie Code, der auf den ersten Blick funktioniert und strukturell ein Problem hat, das sich später zeigt. Ich lasse jeden Code, den ich deploye, gegenlesen: entweder durch eine zweite KI-Instanz mit anderem Kontext, oder durch jemanden, der die Materie versteht. Das kostet Zeit. Das spart mehr Zeit, als es kostet.
Was ich heute kann und was ich nicht kann
Lass mich ehrlich sein.
Ich kann keine komplexen Algorithmen von Hand implementieren. Ich kann keine Performance-Optimierungen auf Compiler-Ebene vornehmen. Ich kann keine vollständige Systemarchitektur für ein Startup mit hundert Nutzern aus dem Kopf skizzieren, ohne dabei auf KI-Unterstützung zu setzen.
Was ich kann: Ideen in lauffähige Software übersetzen. Anforderungen so präzise formulieren, dass eine KI damit arbeiten kann. Ergebnisse beurteilen: technisch, funktional, sicherheitsrelevant. Iterieren ohne aufzugeben. Den Unterschied erkennen zwischen „das klingt gut“ und „das funktioniert in der Praxis“.
Das sind keine kleinen Dinge. Das sind genau die Dinge, an denen viele scheitern, die mit Vibe Coding anfangen und schnell frustriert aufgeben. Weil sie denken, dass ein guter Prompt automatisch eine gute App ergibt. Das tut er nicht. Ein guter Prompt ergibt einen guten ersten Entwurf. Was danach kommt, ist Handwerk.
Und Handwerk kann man lernen. Dafür braucht man kein Informatikstudium. Man braucht Neugier, eine gewisse Frustrations-Toleranz und die Bereitschaft, zu verstehen, was man baut, nicht nur, dass es funktioniert.
Was Vibe Coding für Nicht-Entwickler bedeutet
Wenn du diesen Artikel liest und dich fragst, ob das auch für dich gilt: Ja. Mit Einschränkungen.
Vibe Coding ist kein Shortcut für Menschen ohne technisches Grundverständnis. Es ist ein Multiplikator für Menschen, die die Logik hinter Software verstehen, auch wenn sie die Syntax nicht beherrschen. Das Basiswissen muss da sein. Nicht als vollständige Ausbildung, aber als Fundament.
Was du brauchst: ein Verständnis davon, wie Daten fließen. Was eine Datenbank ist, was eine API ist, was es bedeutet, wenn Code auf einem Server läuft statt im Browser. Das kannst du dir anlesen. Das kannst du dir mit KI erarbeiten. Das kostet keine drei Jahre Studium, das kostet einige Stunden ehrlicher Auseinandersetzung.
Was du mitbringst: Problemlösungskompetenz. Die Fähigkeit, ein Problem so zu zerlegen, dass du es schrittweise beschreiben kannst. Das ist keine Programmierkompetenz. Das ist eine Denkweise, und die hat nichts mit Code zu tun.
Der Rest ist Übung. Und ja, Frustration. Und dann doch wieder dieses Gefühl vom VC 20: wenn es läuft.
Und jetzt?
Ich baue weiter. Ich lerne weiter. Ich werde kein Senior Developer mehr, das ist nicht mein Ziel. Mein Ziel ist, Ideen in Werkzeuge zu verwandeln, die echte Probleme lösen, für mich und für meine Kunden.
Vibe Coding hat mir dabei nicht das Programmieren beigebracht. Es hat mir zurückgegeben, was ich auf dem VC 20 als Erstes gefühlt habe: die Freude daran, dass eine Maschine tut, was ich mir gedacht habe. Nur schneller. Und mit besserer Fehlerbehandlung.
Du kannst warten, bis „echtes“ Programmieren wieder nötig ist. Oder du fängst jetzt an, mit dem, was du bereits weißt.
Häufige Fragen zum Vibe Coding
Muss ich Code lesen können, um Vibe Coding zu betreiben? Vollständig verstehen: nein. Grob einschätzen können, ob eine Lösung sinnvoll aussieht: ja. Das entwickelt sich mit der Zeit, und KI kann dir dabei helfen, unbekannte Code-Abschnitte zu erklären.
Welche Tools brauche ich für den Einstieg? Claude Code oder Cursor als Entwicklungsumgebung, ein einfaches Hosting wie Hetzner oder Vercel für die ersten Deployments. Mehr brauchst du zu Beginn nicht.
Ist Vibe Coding wirklich sicher, wenn man keine Developer-Erfahrung hat? Für private Projekte und interne Tools: ja, mit Sorgfalt. Sobald echte Nutzerdaten ins Spiel kommen, gilt: DSGVO-Grundlagen verstehen, Code reviewen lassen und nicht einfach deployen, weil es läuft.
Was ist der häufigste Fehler von Vibe Coding-Einsteigern? Zu groß anfangen. Der erste Prompt sollte das kleinste mögliche funktionsfähige Ding beschreiben, nicht die fertige App. Iterieren ist das eigentliche Werkzeug.
