Zum Inhalt springen
Michael Seel
Zurück

AI Engineering ist nicht Vibe Coding

Abstraktes Titelbild zu AI Engineering ist nicht Vibe Coding

Ich habe zusammen mit André und Robert einen Workshop zu AI Engineering gehalten. Was davon vor allem hängen bleibt, ist kein bestimmtes Tool. Es ist ein klareres Bild davon, was AI Engineering eigentlich ist und wo die Arbeit anfängt.

Im Schulungsteil haben wir eine Abgrenzung bewusst deutlich gemacht: Agentic Software Engineering ist nicht dasselbe wie AI Engineering. Agentic Software Engineering meint vor allem, wie wir mit Coding Agents Software bauen. AI Engineering meint, wie wir AI-Features in Produkte einbauen und wie wir ihre Qualität bewerten. Beides hängt zusammen, ist aber nicht dasselbe. Uns war wichtig, genau diese zweite Hälfte sichtbar zu machen.

Dafür war die Aufgabe absichtlich bodenständig. Wir haben eine Web-App zur Verwaltung von Skill-Profilen gebaut. Dazu kam ein AI-Feature: unstrukturierte Profile rein, strukturierte Skills und eine brauchbare Kurzbeschreibung raus. Gerade solche Aufgaben finde ich interessant, weil sie zeigen, was durch AI Engineering plötzlich realistisch wird. In vielen Unternehmen liegen relevante Informationen längst in Profilen, Wikis, Tickets oder PDFs herum. Früher wären solche Daten oft nie sauber nutzbar geworden, weil die manuelle Pflege zu mühsam gewesen wäre. Mit einem guten AI-Feature rückt so etwas plötzlich in Reichweite.

Natürlich hatte der erste Teil der Übung diesen typischen Vibe-Coding-Effekt. Ein paar gute Prompts, ein Coding Agent, etwas Hartnäckigkeit, und plötzlich steht eine brauchbare App im Browser. Genau das ist aber auch die Falle. Ein Prototyp sieht schnell nach Produkt aus. Nur ist ein hübscher Prototyp noch kein gutes AI-Feature.

Sobald Markdown-Profile hochgeladen und daraus automatisch Tags und Ein-Satz-Beschreibungen erzeugt werden sollten, wurde es interessanter. Dann kommen die Fragen, die man nicht wegdrücken kann: Sind die extrahierten Skills wirklich im Profil belegt? Stimmen die Kategorien? Ist die Kurzbeschreibung konkret oder nur freundlich formulierter Nebel? Genau an dieser Stelle beginnt AI Engineering.

Und genau dort muss man anders denken lernen. Nicht nur in Datenmodell, UI und Prozessschritten, sondern auch in Aufgaben-Zuschnitt, Kontext und Qualitätskriterien. Welche Informationen sind Anweisungen, welche sind Daten? Wie eng führen wir das Ausgabeformat? Wie viel Kontext hilft wirklich, und ab wann produziert er nur noch Rauschen? Bei klassischer Software fragt man oft: Funktioniert es oder funktioniert es nicht? Bei AI-Features lautet die wichtigere Frage viel öfter: Unter welchen Bedingungen ist die Antwort gut genug, wo kippt sie, und wie merken wir das rechtzeitig?

Deshalb haben wir im Workshop nicht beim Bauen aufgehört. Der wichtigere Teil kam danach: Traces exportieren, Prompts und Responses ansehen, Fehlerfälle sammeln, Labels bilden, Kategorien finden. Unser wichtigstes Learning: Bei AI Engineering geht nicht alles automatisch. Man kann sich beim Bauen viel beschleunigen lassen. Die Validierung verschwindet dadurch aber nicht. Im Gegenteil. Prompt Evaluation ist notwendig und aufwendig. Notwendig, weil man ohne sie keine Qualität der Ergebnisse sicherstellen kann. Aufwendig, weil gute Bewertung Zeit kostet und gründlich gemacht werden muss. Dafür braucht es Domänenwissen - das LLMs im Zweifel nicht haben.

Besonders spannend fand ich, wie unterschiedlich die Ergebnisse der Teilnehmer aussahen. Gleiche Aufgabe, ähnliche Rahmenbedingungen, und trotzdem kamen komplett verschiedene Oberflächen heraus: SAP-R/3-Look, Netscape-Nostalgie, moderne Dark-UI. Gerade daran sieht man, dass solche Workshops mehr sind als Prompt-Lotterie. Wenn aus derselben Übung so unterschiedliche Produkte entstehen, ist noch Produktdenken im Raum.

Skill-App im SAP-R/3-Look

Skill-App im Netscape-Look

Skill-App mit moderner dunkler Oberfläche

AI Engineering erweitert gerade den Möglichkeitsraum von Softwareprojekten. Es macht Dinge praktikabel, die früher oft zu teuer, zu unscharf oder zu pflegeintensiv gewesen wären. Aber dieser neue Möglichkeitsraum kommt nicht gratis. Man muss umlernen. Ein Teil der Implementierung wird leichter, dafür wird die Validierung wichtiger, gründlicher und oft auch zeitintensiver. Genau deshalb bleibt Prompt Evaluation für mich das zentrale Learning.



Vorheriger Artikel
Wider den Modell-Hype
Nächster Artikel
Make or Buy: Individualsoftware wird günstiger