TL;DR
Vibe Coding funktioniert: Man beschreibt, was man will, und ein Agent erstellt eine lauffähige Anwendung, ohne dass es dafür technisches Wissen braucht. Wo nichts davon abhängt und bei einem Fehler nichts verloren geht, ist das genau der richtige Weg. Eine geschäftskritische Anwendung verlangt eine andere Disziplin: andere Leute, eine andere technische Umgebung und andere Anforderungen. Agenten haben es fast jedem leichter gemacht, Software zu schreiben. Ingenieure, die geschäftskritische Software entwickeln können, sind dagegen schwerer zu finden. Der Hype lebt von der Demo, denn «in drei Tagen fertig» verkauft sich, und sorgfältige Ingenieurarbeit gibt keine Schlagzeile her. Leg den Modus fest, bevor die Arbeit beginnt: Vibe Coding oder Agentic Engineering.
Entscheide zuerst, was aus dem Code werden soll, und erst dann, wie er entsteht. Verlässt sich dein Unternehmen später auf diesen Code, braucht es Agentic Engineering. Für eine Demo reicht Vibe Coding. Die Werkzeuge sind dieselben, also sagt dir nur diese Entscheidung, woran du bist.
Vibe Coding passt überall, wo ein falsches Ergebnis nichts kostet
#Technischen Hintergrund braucht es dafür keinen: Man sagt, was man will, und ein erstellt etwas, das läuft. Dieser Teil des Versprechens hat sich erfüllt, und das darf man neidlos anerkennen. Wo nichts davon abhängen wird und sich ein Fehler ohne Kosten rückgängig machen lässt, ist genau das richtige Werkzeug. Das trifft etwa auf einen schnellen Prototyp zu, auf ein internes Tool, das nichts beschädigen kann, oder auf eine statische Website.
Den Ausschlag gibt dabei nicht die Lebensdauer. Ein Skript, das ein einziges Mal auf der Produktionsdatenbank läuft, ist nach wenigen Sekunden erledigt. Ein Fehler darin kann trotzdem Daten vernichten, die niemand zurückbekommt. Dafür ist Vibe Coding das falsche Werkzeug.
Die Pflichten folgen aus der Verantwortung, nicht aus der Technik
#In vielen Unternehmen läuft ein wichtiger Prozess über eine Excel-Anwendung, die sich jemand aus der Fachabteilung selbst gebaut hat. Eine Weile geht das gut. Dann wechselt diese Person die Stelle. Niemand pflegt die Anwendung mehr, niemand testet sie, und Fehler darin bleiben unbemerkt, weil nie eine Kontrolle vorgesehen war.
Gescheitert ist die Excel-Anwendung nicht an dem Tag, an dem sie entstand, sondern an dem Tag, an dem das Unternehmen anfing, sich auf sie zu verlassen, ohne dass jemand für sie zuständig war. Sie war schnell gebaut, aber auf Kredit. Bezahlt wurde später, mit Zinsen. Mit einer per Vibe Coding erstellten Anwendung, auf die sich ein Unternehmen verlässt, läuft es genauso, nur schneller.
Regeln für Zuständigkeit und Code-Review greifen erst bei Software, die jemand als geschäftskritisch eingestuft hat. Die Excel-Anwendung hat nie jemand so eingestuft; sie ist es einfach geworden. Einer Vibe-Coding-Anwendung kann es still und leise genauso gehen.
Vibe Coding kann jeder, Agentic Engineering nur wenige
#Der Hype stellt das genau auf den Kopf. Seit Vibe Coding die Einstiegshürde beseitigt hat, ist die Zahl der Leute, die etwas Lauffähiges hinbekommen, praktisch unbegrenzt. Bei ist es umgekehrt. Gebraucht wird jemand, der die Entwicklung geschäftskritischer Software bereits beherrscht, also Struktur, Sicherheit und die Folgekosten eines Systems beurteilen kann, und der obendrein gelernt hat, Agenten gut zu führen.
Vor den Agenten genügte es, geschäftskritische Software entwickeln zu können. Heute muss man auch Agenten gut führen können, und beides können deutlich weniger Ingenieure als nur das eine. Und die Arbeit, für die es sie braucht, ist kein bisschen weniger kritisch geworden.
Verkauft wird das Tempo, nie die Ingenieurarbeit, die das Ergebnis sicher macht
#Ich habe oft erlebt, wie einem Unternehmen KI mit einer Vibe-Coding-Demo verkauft wurde. Solche Demos sorgen für einen Wow-Effekt, weil in kurzer Zeit sehr viel entsteht. Doch was dort per Vibe Coding entsteht, ist nur für den Moment gebaut. Damit sich ein Unternehmen darauf verlassen kann, braucht es noch viel zusätzliche Arbeit. «Wir hatten es in drei Tagen fertig» kann jeder weitersagen, und jeder hat sofort ein Bild dazu. Für die Ingenieurarbeit, mit der man ein System sicher betreiben kann, gibt es keinen solchen Satz, und was sie kostet, kommt in der Demo nie vor. Also werden die drei Tage zitiert, und die Kosten bleiben im Verkaufsgespräch aussen vor.
Keiner der beiden Modi ist ein Fehler; ein Fehler ist es, den einen für die Aufgaben des anderen zu verwenden
#Wer ein Zelt aufstellt, plant nicht, zwanzig Jahre darin zu wohnen. Niemand wirft dem Zelt vor, dass es kein Haus ist. Ein Prototyp kann durchaus viel bewirken: eine Entscheidung stützen, ein Budget begründen, eine Richtung vorgeben. Ein Prototyp bleibt er trotzdem.
Weiter erkunden