vi3ecoding Team
Zwei Builder setzen sich mit denselben AI-Tools hin. Gleicher Lovable-Account. Gleiches ChatGPT. Gleiches Supabase.
Einer shippt ein Produkt, das designt wirkt. Der andere shippt etwas, das sich anfühlt wie eine Demo.
Der Unterschied ist nicht der Prompt. Es ist der Kontext.
Context Engineering ist 2026 der eigentliche Job eines AI-Builders. Prompt Engineering war das Klebeband, das wir nicht mehr brauchen.
Weiterlesen auf vi3ecoding:
- Die vier Kontext-Ebenen, die jeder AI-Agent braucht
- Context-Dateien für Lovable-Projekte
- Was ist Vibe Coding wirklich?
Vor zwei Jahren hätte ich das nicht geglaubt. Heute schon. Nach genug echten Kunden-Projekten — foodla.eu ist das öffentlichste, wo Lovable und Supabase eine ganze Restaurant-Plattform tragen — sehe ich mich nicht mehr als Prompt-Schreiber. Ich bin ein Context Engineer, der gelegentlich Prompts tippt.
Was Context Engineering in einem Satz ist
Context Engineering heißt: der AI alles geben, was sie für eine gute Entscheidung braucht — bevor du sie etwas tun lässt.
Kein cleverer Prompt. Kein magischer Satz. Ein Stapel strukturierter, relevanter, aktueller Informationen, der aus einem generischen Modell etwas macht, das sich wie ein Senior-Teammitglied in deinem Projekt verhält.
Warum Prompt Engineering sterben musste
2023 war "Prompt Engineer" ein Jobtitel auf LinkedIn. 2026 ist es ein Witz. Der Grund ist einfach: Prompt Engineering war immer ein Workaround für schwache Modelle.
Wir brauchten magische Sätze — "think step by step", "you are an expert" — weil die Modelle das nicht zuverlässig konnten, ohne angestupst zu werden. Prompts waren Klebeband. Es funktionierte. Es entstand eine ganze Industrie aus Leuten, die Prompt-Packs verkauften wie geistiges Eigentum.
Dann änderten sich zwei Dinge:
- Modelle wurden drastisch besser darin, Intent zu erkennen.
- Tools wurden drastisch besser darin, Kontext über Turns hinweg zu tragen.
Ein 2026-Modell mit reichem Kontext produziert aus einem 5-Wort-Prompt besseren Output als ein 2023-Modell aus einem 500-Wort-Prompt. Der Hebel hat sich verschoben.
Das Mental Model: AI als brillanter Neueinsteiger
Stell dir vor, du stellst Montag früh einen Senior-Entwickler ein.
Du gibst ihm kein einzeiliges Ticket und erwartest ein Feature bis zum Mittag. Du gehst durch das Produkt. Du zeigst die Codebase. Du erklärst den Kunden. Du teilst das Design System. Du sagst, was letzte Woche gelaufen ist und was nächstes Quartal kommt.
Dieses Onboarding ist Context Engineering. Alles, was ich mit AI-Tools mache, ist das gleiche Onboarding — einmal aufgeschrieben, für immer wiederverwendbar.
Die 4 Kontext-Ebenen, die ich für jedes Projekt schreibe
Ich halte sie als simple Markdown-Dateien im Repo. Die AI liest sie, bevor sie irgendetwas tut.
- Produkt-Kontext — was das Produkt ist, für wen, welches Problem es löst, wie Erfolg aussieht.
- Technischer Kontext — Stack, Konventionen, Ordnerstruktur, Naming-Regeln.
- Design-Kontext — Farben, Typografie, Spacing, Voice und Tone.
- Entscheidungs-Kontext — was wir probiert haben, was wir verworfen haben, und warum. Diese Ebene überspringen die meisten — und es ist genau die, die verhindert, dass die AI tote Ideen neu vorschlägt.
Fehlt eine Ebene, füllt die AI die Lücke mit Durchschnitt. Durchschnitt ist der Grund, warum so viele AI-Apps aussehen wie dieselbe App.
Ein echtes Beispiel: der foodla.eu-Rebuild
Als ich Teile von foodla.eu neu gebaut habe, habe ich die ersten ~30 Minuten keine Zeile Code geschrieben. Ich habe Kontext geschrieben.
- Eine Seite über den Restaurant-Onboarding-Flow.
- Eine Seite über das Datenmodell und die Supabase-RLS-Regeln.
- Eine Seite über die visuelle Sprache — die runden Ecken, das Spacing, den "warm aber praktisch"-Ton.
- Eine Seite mit Dingen, die wir schon probiert und verworfen hatten.
Danach hat der eigentliche Build etwa 10 Stunden gedauert statt der 40, die er ohne dieses Setup gebraucht hätte. Nicht weil die AI schlauer wurde. Weil sie endlich dieselben Informationen hatte wie ein Teammitglied.
Prompt vs Context Engineering — der ehrliche Vergleich
Prompt Engineering: "Du bist ein Senior React Developer. Schreibe ein Sign-up-Form nach Best Practices."
Context Engineering: "Hier ist unser Auth-Flow. Hier ist unsere Komponenten-Library. Hier ist das Design System. Hier ist, was wir letzten Monat probiert haben und warum es nicht funktionierte. Jetzt baue das Sign-up-Form."
Gleiches Ziel. Komplett anderes Ergebnis. Das zweite ist, wie ich heute arbeite.
Was die meisten Builder falsch machen
Sie behandeln Kontext wie Dokumentation — etwas, das man einmal schreibt, in einen Ordner legt und vergisst.
Kontext ist keine Dokumentation. Dokumentation ist für Menschen, die überfliegen können. Kontext ist für AI-Tools, die ihn jedes Mal wörtlich lesen.
- Kurz halten. Langer Kontext verwässert das Wichtige.
- Aktuell halten. Veralteter Kontext ist schlimmer als kein Kontext.
- Spezifisch halten. "Wir bevorzugen sauberen Code" ist nutzlos. "Wir nutzen kebab-case Dateinamen und named exports" ist Gold.
Was es für dein Hiring und deine Arbeit ändert
Wenn du wie Vi3ecoding ein kleines Studio führst, ist das die größere Verschiebung: Die wertvollste Person im Team ist nicht die mit den schnellsten Fingern. Es ist die Person, die echte Kunden-Intentionen extrahieren, strukturieren und so an die AI übergeben kann, dass die AI handeln kann.
Das ist eine Produkt-Fähigkeit. Eine Strategie-Fähigkeit. Eine Editor-Fähigkeit. Es ist im klassischen Sinne keine Coding-Fähigkeit — und genau deshalb unterschätzen klassische Entwickler sie oft.
Also — was unterscheidet gute AI-Builder von großartigen?
Es ist nicht das Modell. Nicht die IDE. Nicht der Stack.
Es ist, wie viel Kontext du der AI gibst, bevor du sie um etwas bittest.
Prompt Engineering hat dir eine Demo gebracht. Context Engineering bringt dir ein Produkt.