Ein Prototyp beschreibt das "Was". Das "Wie" fehlt (und wird dann häufig vergessen)

Vor ein paar Wochen hat Volker Gruhn einen Satz geschrieben, der mir nicht mehr aus dem Kopf ging: "wer sein Fachproblem nicht präzise genug versteht und beschreibt, bekommt vom Agenten präzise das Falsche geliefert." Gruhn ist Aufsichtsratsvorsitzender bei adesso und Professor für Software Engineering in Duisburg-Essen, sein Beitrag in der Computerwoche vom 20.08.2026 trifft den wunden Punkt genau.

Er hat recht mit der Diagnose. Bei den Abstellmaßnahmen bin ich allerdings etwas anderer Meinung.

Worum es im Beitrag "Deutsch ist keine Programmiersprache" geht

Gruhns These, kurz zusammengefasst: Wenn Agenten den Code schreiben, verschiebt sich der Engpass. Früher war die knappe Ressource das Programmieren selbst. Jetzt ist es die Frage davor: was soll überhaupt gebaut werden. Wer sein Fachproblem schwammig beschreibt, bekommt ein präzises, aber falsches Ergebnis.

Mittlerweile ist diese Haltung, diese Analyse ja schon fast Allgemeinwissen.

Sein Rezept dagegen formuliert er ganz einfach: Die Lösung ist die Beschreibung als gemeinsame Aufgabe von Fachbereich, IT, Architektur und Compliance. Eine "Unternehmensgrammatik", ausdrücklich keine neue formale Sprache, sondern gemeinsame Strukturen, an die sich alle Beteiligten halten. Annahmen aussprechen, Grenzen ziehen, Klarheit als Ziel statt Vollständigkeit. Und, das ist der Teil, der bei mir hängen geblieben ist: Beschreibungen behandeln wie Code. Testen, versionieren, verbessern, wiederverwenden.

Das ist ein durchdachter Vorschlag. Ein Unternehmen, das seine Anforderungen tatsächlich versioniert und testet, macht etwas, das die meisten heute nicht tun und vielleicht auch nie getan haben. Trotzdem bleibt für mich eine Frage offen: Wer testet eine Beschreibung eines Zustands, eines Produkt, bevor sie gebaut wurde? Getestet wird am Ende doch immer das Ergebnis, nicht der Text davor. Am Ende ist das ganze eine Meinung...

Wo ich der These ganz klar zustimme

Die Diagnose stimmt. Ich habe in den letzten Jahren genug Projekte gesehen, in denen die Software am Ende technisch sauber war und trotzdem am eigentlichen Problem vorbeigebaut wurde. Das ist wahrhaftig kein neues Phänomen, KI-Agenten machen es nur schneller sichtbar, weil der Weg von der Idee zum lauffähigen Ergebnis (also testbarem Protoyp oder MVP) kürzer geworden ist. Früher hat ein missverstandenes Problem oder ein mangelndes Verständnis eines fachlichen Zusammenhangs Wochen gebraucht, um sich in schlechtem Code zu zeigen. Heute liefert KI-gestützte Softwareentwicklung in Minuten etwas, das genau diese falsche oder unvollständigen Annahme perfekt umsetzt. So werden Fehler schneller sichtbar und schneller korrigierbar sofern jemand genau hinschaut!

Präzision zählt also, keine Frage. Die Lösung steckt aber nicht in mehr Text, mehr Prompting.

Mit KI zeigen statt beschreiben

Jede Beschreibung, egal wie sorgfältig formuliert, bleibt eine Behauptung, bis sie läuft. Ein Satz kann sich stimmig lesen und trotzdem zwei Leuten zwei verschiedene Bilder im Kopf erzeugen, ohne dass es beim Schreiben auffällt. Das merkt man erst, wenn beide unabhängig voneinander beschreiben würden, was sie gerade gelesen haben.

Das präziseste Beschreibung ist also eine konkrete Visualisierung.

Der Gedanke, den wir bei software. but right. mit AI-Shoring schon länger vertreten: Ein KI-Prototyp, mit Lovable, Bolt oder ähnlichen Werkzeugen zusammengebaut, ist eine hervorragende funktionale Spezifikation. Er zeigt, wie sich etwas anfühlen soll, welche Schritte ein Nutzer geht, wo die erwarteten Ergebnisse liegen. Er ist gleichzeitig eine miserable nicht-funktionale Spezifikation. Sicherheit, Skalierung, Wartbarkeit, sauberer Datenumgang, dazu sagt so ein Prototyp nichts.

Die Arbeitsteilung, die daraus folgt: Du bringst das Was. Wir machen es richtig und liefern das fertige Produkt.

Das Fraunhofer IESE hat es so formuliert, KI-generierter Code sei oft unstrukturiert, redundant oder schwer wartbar, fehlende Security-Checks eingeschlossen. Genau die Lücke, die wir meinen.

Wie KI-gestützte Softwareentwicklung bei uns konkret aussieht

Zeigen statt beschreiben heißt bei uns: ein fester Ablauf, nicht nur ein Grundsatz. Er beginnt mit einem Workshop, in dem wir den Prototyp oder den vorhandenen Prozess gemeinsam durchgehen, statt zuerst ein Anforderungsdokument zu schreiben. Danach folgt eine Architektur-Phase, in der wir festhalten, was der Prototyp offenlässt: Sicherheitskonzept, Datenmodell, Skalierung.

Der eigentliche Unterschied kommt danach. Wir liefern wöchentlich einen lauffähigen Stand, den du selbst testest, nicht einen Statusbericht darüber. Eine falsche Annahme fällt damit in Woche zwei auf, nicht erst nach sechs Monaten. Das kostet dann eine Woche Korrektur statt eines halben Jahres. Was das für einen bestehenden Vibe-Coding-Stand konkret bedeutet, wenn er produktionsreif werden soll, steht ausführlicher in einem eigenen Beitrag.

Wichtig am gesamten Vorgehen: Es setzt voraus, dass das Produktkonzept selbst stimmt! Ein technisch sauberer Prototyp am falschen Bedarf wird durch professionelle Entwicklung nicht richtig. Wir lösen die technische Frage, nicht automatisch die Produktfrage, aber wir können dich dabei unterstützen kritisch auf die Prozesse und Buisinesslogik zu schauen, um zu eruieren, ob das so passt. Am Ende kannst du durch die kurzen Zyklen auch testen und wir können korrigieren, falls etwas nicht so funktioniert wie erwartet. Und am Ende wartet DEIN Produkt auf dich.