Transcription
Du hast über 200 PMS eingegeben. Die App sollte eigentlich nur ungefähr 2wei Stunden dauern. Jetzt ist du schon zwei Tage [musik] daran. Irgendwas bricht immer wieder. Dann fickst du das und hast aber drei neue Probleme. Und das Schlimmste dabei, du weißt gar nicht warum. Weil du keine einzige Zeile Code davon wirklich selber geschrieben hast. Wenn du selber jemals irgendwas mit KI gebaut [musik] hast, dann kennst du diesen Moment.
Und das, was dir keiner sagt ist, das ist nicht ein Tourproblem, das ist auch keine Pechsträhne, das ist die Decke von Wipecoding [musik] und fast jeder erreicht sie. Aber der Mann, der den Begriff Wipecoding erfunden hat, hat schon rausgefunden, was als nächstes kommt. Und sobald du das verstehst, verschwenden die Decke und die Grenzen von Vibecoding. Und der Begriff, den er statt Vibecoding nimmt, heißt Atantic [musik] Engineering. Was steckt dahinter? Ich will dir eine Geschichte erzählen.
Vor ca. anderthalb Jahren saß ich an meinem Schreibtisch, zwei Bildschirme, vier Tools offen und ein kalten Kaffee. Und ich habe gerade meinen 15. prompt eingegeben und das Tool, was ich für einen Kunden bauen sollte, hat immer noch nicht funktioniert. Nicht, weil meine Tools schlecht waren oder weil ich keine Ahnung von dem Thema hatte, sondern weil ich immer nur beschrieben habe, was ich wollte, aber nie definiert habe, was ich wirklich brauche. Und das ist genau der Unterschied, über den wir heute reden. Und ich verspreche dir, wenn du dieses Video bis zum Ende anschaust, wirst [musik] du KI nie wieder so nutzen wie vorher. Und nicht, weil ich dir irgendwie den krassesten Hack zeige, sondern weil ich dir aufzeige, wie du aktuell denkst.
Lass uns mal noch mal einmal kurz zurückspulen. 2025 hat Andrew Kapaty, einer der größten KI Forscher, den wir haben und ehemaliger [musik] Tesla AI Chef, folgenden Begriff geprägt: Vibecoding. Die Idee war ziemlich simpel. Beschreib, was du haben möchtest, lass die KI umsetzen und iteriere darüber. Du brauchst dafür kein irgendwie jahrelangen technische Education, um dahinzukommen. Und es hat auch funktioniert, wenn man sich das heute anschaut. 95% der Y combinator Projekte sind 95% mit KI umgesetzt und geschrieben. Menschen haben Produkte äh ja geschippt in Tagen und nicht wie sonst in Monaten. Das war neu, das war real und das war super aufregende Zeit. Und wenn du selber so angefangen hast, dann bist du auf dem richtigen Weg. Aber hier ist die Wahrheit, die noch niemand so richtig ausspricht. Wipecoding war immer nur der Startpunkt, niemals das Ziel.
[musik] Hier ist was passiert, wenn du Wibecoding als Zielhorizont für dich definiert hast. Jeden Prompt, den du abschickst, ohne klaren Plan oder oder Outcome, ist eine Ungewissheit, was wirklich dabei rauskommt oder nicht, da du selber nicht vollständig verstehst, was überhaupt passiert. Und alles was du nicht verstehst macht die Reise bis zum Outcommen deutlich schwerer und du baust dir möglicherweise viele Steine in den Weg und das kann seit gehen, dass plötzlich nichts mehr funktioniert und du selber weißt gar nicht, wo du anfangen sollst dabei. Stack Overflow hat letztes Jahr um die 50.000 Entwickler befragt. Das Vertrauen in KI generierten Code ist von 49% auf 21% gefallen. Und das ist kein Zufall, weil die Leute mit Wibecoding schneller geschippt haben, aber per se gar nicht verstanden haben, worum es da wirklich geht und was das Outcome oder das Tool können soll. Die haben [musik] dann sich selbstbrechende Apps, die haben zwei Features, die sich gegenseitig eigentlich behindern oder aufheben. Das Projekt, was am Anfang super schnell war, ist hinten raus komplett langsam, weil man so viele Baustellen erstmal fixen muss. Und da ist, glaube ich, ein ganz wichtiger Satz. Man hat einfach beschrieben, was man haben wollte, nicht definiert, was man braucht.
Und ich selber bin da auch reingelaufen. Ich habe ähm krass viele Us Cases schon umsetzen dürfen mit Firmen zusammen Innenhaus Softwarep Projekte umgesetzt und nicht alle sind zum Erfolg gekommen oder hatten den gewünschten Output, den man sich vorgestellt hatte, aber das war niemals technischer Natur. Es war meistens strategischer Natur, weil auch ich am Anfang erstmal nur gebaut habe, ohne zu wissen, wo es überhaupt richtig hingehen soll. Ich habe geprompt, bevor ich definiert habe. Ich habe [musik] mit der KI gewiped und nicht delegiert. Und das hat mir wirklich viel Zeit, Geld und ähm ja, einfach Gehirnkapazität gekostet, [musik] die ich hätte besser investieren können. Dann habe ich für mich verstanden, was wirklich gefragt ist heute.
Dann lass uns mal reingehen, was quasi hinter dem Begriff Gentic Engineering eigentlich steckt. Zwei Begriffe. Das ist eigentlich der neue Standard ist nicht, dass du 99% deiner Zeit damit verbringst, Sachen umzusetzen. Beispiel Code schreiben oder Copywriting und so weiter, sondern du managest Agenten, die das für dich tun. Und der zweite Begriff ist Engineering. Ähm was den Begriff einfach von Gefühl, von Skill geben soll, also eine Tiefe, damit die Leute auch wahrnehmen, okay, das ist jetzt nicht, was man mal schnell wiben kann, sondern wirklich lernen muss äh und verbessern kann über die Zeit, wenn man es halt praktiziert. Das ist so ein bisschen mit dem Antic Engineering gemeint.
Was ist jetzt ein typischer Unterschied zwischen Vibecoder und ein Gentic Engineer? Der Vibecoder würde vielleicht sagen: "Ey, bau mir ein Dashboard für oder basierend auf meiner Finanztabelle und ein TIC Engineer würde sagen, baue mir ein Dashboard basierend auf meiner Finanztabelle mit folgenden drei Metriken, fetche der Daten über den Curl bla bla blaabla und eine Animation, solange der Fetch läuft." Ähm, also du hast viel mehr definiert, du hast im Vorfeld die Gedanken gemacht, okay, was für Daten kriege ich woher und ähm was soll passieren, damit der Output richtig ähm greifbar ist? Und das ist, glaube ich, super wichtig, ähm einfach jetzt zu verstehen. Hör auf Sachen zu beschreiben. Fang an Sachen zu definieren.
Der Wibecoder würde basier auf dem ersten Output Reverse engineieren. Okay, ich muss das noch fixen, ich muss da noch hin und ich will das umsetzen. Und der Agentic Engineer würde im Vorfeld definieren, wo wir hin wollen und den Step by Step da hinkommen. Und nicht quasi Fehler aufkommen lassen an der Stelle. Und dieser MFT Shift ist, glaube ich, super wichtig, um quasi jetzt aus diesem Trend ein richtigen Skill zu machen.
Okay, jetzt wird's praktisch und ich will, dass du dir das jetzt richtig aufschreibst, weil das jetzt nicht nur Theorie ist, das ist wie ich täglich aktuell arbeite. Enic Engineering ist keine Codingfähigkeit, es ist eine Denkfähigkeit und drei Habits, die dabei helfen, das richtig zu implementieren, will ich dir jetzt mal zeigen. Da geht's darum, definiere den Output, bevor du einen Agent loslaufen lässt. Das heißt, bevor du auch überhaupt ein Tool öffnest, macht die Gedanken, was will ich haben, wie soll es dargestellt werden, wo kommen die Daten her, wie sehen die Daten aus, was muss ich vielleicht, bevor ich die Daten darstellen kann, noch mit den Daten machen, um sie zu verändern, wenn ich sie verändern will, ähm welcher Form muss ich vielleicht externe Service oder Tools dafür benutzen? Was sind meine Kosten dahinter und so weiter und so fort.
Ein anderer Begriff, den vielleicht die meisten kennen, ist auch Context Engineering und das war auch ein Feedback, was ich bekommen habe. Da eine Firma, mit der ich mal Wipecoding in der Vergangenheit gemacht hatte, kam zu mir: "Ey, Sascha, ähm, wir haben jetzt hier versucht ein KI Agenten für unser Content System zu bauen und nach ein paar Wochen schläft das immer wieder ein. ich gesagt, okay, zeigt mir mal, was ihr habt. Und per se haben sie sehr gut gewallcodet, aber ganz schlecht Context Engineering betrieben. Sie haben sich keine Gedanken gemacht, okay, was für Inhalte brauchen wir, ähm wie müssen die Aufgabitet sein, in welcher Struktur und wo legen wir die ab? Und diese ganze Vorbereitung ähm hat natürlich den Agent dazu gebracht, dass der Output nicht gut war, ähm dass es lange gedauert hat zu iterieren, er hat Fehler gemacht und ihn ist es sehr schwer gefallen, das ja zu optimieren.
Dann lass uns jetzt zum zweiten Habit kommen. Das ist quasi gebe dem Agent Aufgabe bei Aufgabe. Ich selber habe auch schon Experience gemacht. Du sagst, das ist mein äh Outcome, kann sehr detailreich sein. Wir hatten vorhin ein Prom Beispiel, der schon fast zu lang oder zu groß war, äh mit den drei Metriken und so weiter und so fort. Ähm es ist halt wichtig als Mensch zu diedigen, okay, welche Scope ist jetzt richtig? Also, es ist nicht der richtige Scop zu sagen, bau mir eine Fitness App mit einer Landing Page und ich brauche noch eine API dazu, sondern bau mir eine Landing Page. Hier ist die Copy, die wir dazu haben wollen und das ist mein Style Guide. Darauf basierend als nächste Aufgabe, jetzt bauen wir den Login Flow. Bitte connecte jetzt den die Datenbank, damit der User sich anmelden kann. Testen und dann erst danach, okay, jetzt bauen wir das App Dashboard, wenn man sich eingeloggt hat. Also, du musst als Mensch sinnvoll delegieren und separieren. Es gibt jetzt natürlich die Funktionalitäten von Subagents und Agent Teams, gerade bei Cloud Code extrem michtig und umso besser euer Skill bei Magentic Engineering ist, könnt ihr diese Tools auch weiter nutzen. Ich würde euch raten, anzufangen mit einem Agent, einem reaktiven Agent z.B. Cloud Code. Dann könnt ihr mit mehreren reaktiven Agents, also Subagents und Agent Themes in Cloud Code arbeiten und wenn ihr das auf die Spitze treiben wollt, könnt ihr natürlich mit aktiven Agents wie Open Claw oder Hermes Agent in Verbindung mit Open Paperclip arbeiten. Das ist jetzt die Tool [schnauben] Stack, den ihr innerhalb von Jantic Engineering nutzen könnt und das ist so sieht halt die Zukunft aus, wo es hingeht mit Arbeiten.
Und der letzte Habit, den ich euch quasi empfehlen würde, ist menschlicher Review und macht dann erst weiter. Das heißt, mit dem was ich beschrieben habe, Aufgabe bei Aufgabe, solltet ihr als Human Loop dazwischen sein, kontrollieren, funktioniert es richtig? Hat er alles richtig verstanden, challengen, Test schreiben und so weiter, dass quasi ihr sagt, okay, jetzt funktioniert das einwandfrei und erst dann geht ihr zum nächsten Milestone. Ich nenn es mal Milestones oder Breakdowns, das könnt ihr definieren, wie ihr wollt, aber das ist eine die Kette, die ich immer empfehle. Definiere sehr gut. Mach gutes Kontext Engineering. Gebe den Agenten Step by Step Aufgaben, dass sie auch der Scope nicht zu groß wird. Da ist viel Kontextwinde und so ein großes Thema und natürlich der menschliche Review. Also du als Mensch bist immer noch der der managed oder orchestriert. Ist auch ein auf oft genannter Begriff, um quasi ans Ziel zu kommen.
Wie bin ich aber überhaupt jetzt selber quasi zu diesem ganzen Erkenntnis gekommen? Ich war ultra ein Vibecode Ultra. So, ich habe das jeden Tag nur gemacht und ähm kam natürlich immer zu meinen Ergebnissen, aber wenn mit dem Wissen heute wä ich da deutlich schneller und besser vorangekommen. Ich war der krasse Tool Junky, hatte irgendwie 20 KI Tools und habe die links und rechts immer wieder versucht anzuschließen und zu connecten und ja, das hat ehrlicherweise war das nicht zielführend und genau deswegen möchte ich das teilen, weil ich selber sehr lange daad durchgelaufen bin und sehr viel Pain dabei erfahren habe. Ich möchte halt dich schützen, dass du jetzt hier nicht weitere 50 Subscription irgendwo haben musst, sondern eher ein Skillset aufbaust, der die nächsten 10 Jahre krass krasse Bewandnis für dich und dein Ökosystem oder deine Nische quasi haben wird. Daher quasi versuch für dich diese Arten neuzudenken anzunehmen, von beschreiben zu definieren, von hoffen zu delegieren, vom Vibe Coding zuic Engineering.
Ich will dir noch etwas mitgeben, was ich mir selber gewünscht hätte, mir jemand geraten hätte vor zwei Jahren ungefähr. KI wird nicht langsamer. Es wird nicht einfacher Tools oder neue Tools zu ignorieren und die Konkurrenz wird auch nicht aufhören schneller und besser KI zu nutzen. Aber da ist auch die gute Nachricht drin versteckt. Die Barriere ist niedriger als je zuvor. KI macht es nicht schwerer, es macht es leichter. Aber die Nachfrage von Menschen, die strategisch Systeme implementieren und aufbauen können mit KI, die Nachfrage wird immens steigen. 26 wird für mich auf jeden Fall das Jahr, wo sich die Spreu vom Weizen trennt, denn die einen werden immer weiter versuchen, das nächste krasse KI Tool zu finden, zu meistern und dann wieder weiterz springen zum nächsten krassen Competitor, der im Markt irgendwie auftaucht und die anderen werden halt verstehen, wie man KI managen kann ohne Toolos und ich glaube, du weißt schon, auf welcher Seite du stehen möchtest, weil sonst wärst du jetzt nicht hier im Video. Der Erfolg, den du nämlich gerne hättest, steckt einfach hinter harter Arbeit. Nicht hinter dem nächsten Tool, nicht hinter dem nächsten krassen Promt, sondern den Skill zu lernen, KI richtig zu managen, also Jantic Engineering.
Also was kannst du jetzt step by Step machen, um heute anzufangen? Nimm dir eine Aufgabe, die du mit KI lösen möchtest und schreib in zwei Sätzen hin sehr präzise, was ist der Outcome, die du damit erreichen möchtest? Kein Feature, ein Outcome, was du damit erreichen möchtest. Zerlege dein Projekt in drei Schritte. Nicht alles auf einmal, in drei Schritten. Und das arbeitest du step bei Step bei Step ab. Und der dritte Schritt: Review nach jedem Step genau was der Stand ist. Funktioniert alles einwand frei? Perfekt. Weiter zum nächsten. Funktioniert es doch nicht, okay, find das Problem, löse das Problem und versteh das Problem, dass es dir beim nächsten Projekt nicht noch mal passiert. Das ist antic Engineering. Kein Hexenwerk, keine Raketenwissenschaft, einfach nur ein neuer Denkansatz.
Wenn du tiefer einsteigen willst, dann würde ich mich über ein Abo auf diesem Kanal freuen. Lass mir auch gerne ein Like und Kommentar da. Ähm, wenn irgendwas unklar ist oder du Fragen hast, hau gerne raus. Ich versuche immer alle Fragen zu beantworten und bis dann erstmal Happy Building und Peace