Ein Beispiel aus der Wissenschaft zeigt derzeit sehr deutlich, wo die Stärken prompt-getriebener Arbeit liegen – und wo ihre Grenzen. Der Harvard-Physiker Matthew Schwartz hat beschrieben, wie er mit dem Open-Source-Werkzeug BootLoops und dem Sprachmodell Claude innerhalb von drei Monaten 36 Manuskripte in 18 Fachgebieten erstellt hat, von der Teilchenphysik bis zur Linguistik. Wissenschaftlich wertvoll wurden die Resultate nach seiner Darstellung aber erst durch menschliche Steuerung. Sein Fazit ist unmissverständlich: Jedes Ergebnis muss selbst überprüft werden.
Für Unternehmen, die KI in Entwicklungs- oder Content-Prozesse einbauen, ist das die relevantere Nachricht als die Zahl der Manuskripte. Denn sie beschreibt nicht ein Modell, das autonom arbeitet, sondern einen Arbeitsablauf, in dem Mensch und Werkzeug klar verteilte Rollen haben.
Was ein Harness überhaupt leistet
Der Begriff Harness – wörtlich: Geschirr oder Gurtzeug – bezeichnet in der KI-Praxis eine Schicht, die um ein Sprachmodell herum gebaut wird. Sie organisiert, was das Modell wann tun soll, übergibt Aufgaben, nimmt Ergebnisse entgegen und leitet sie weiter. BootLoops ist genau so ein Werkzeug: Es unterstützt KI-Modelle bei exakten wissenschaftlichen Berechnungen und ist als Open Source verfügbar.
Der Punkt dahinter ist wichtiger als das einzelne Tool. Ein Sprachmodell erzeugt Text, der plausibel klingt. Exaktheit ist dabei kein eingebautes Merkmal, sondern etwas, das von außen hergestellt werden muss – durch Prüfschritte, durch Werkzeuge, die rechnen statt formulieren, und durch Menschen, die das Ergebnis gegen die Realität halten. Ein Harness ist der organisatorische Rahmen, der genau diese Schritte verlässlich wiederholt, statt sie dem Zufall einzelner Prompts zu überlassen.
Der Unterschied zwischen Menge und Wert
36 Manuskripte in drei Monaten ist eine bemerkenswerte Durchsatzzahl. Sie sagt für sich genommen aber nichts über Qualität aus. Genau das macht den beschriebenen Fall lehrreich: Der Output entstand schnell, der Wert entstand langsamer – nämlich dort, wo ein Fachmensch Richtung gab, verwarf, nachschärfte und nachrechnete.
Dieses Muster lässt sich eins zu eins auf Projekte übertragen. KI verschiebt den Aufwand, sie beseitigt ihn nicht. Was früher in das Erstellen eines ersten Entwurfs floss, fließt heute in Spezifikation, Bewertung und Korrektur. Wer diesen Aufwand nicht einplant, bekommt viel Material und wenig verwertbares Ergebnis.
Vibe Coding braucht denselben Rahmen
Unter Vibe Coding versteht man Entwicklung, bei der Code überwiegend per Prompt erzeugt und nur noch oberflächlich gesichtet wird. Das funktioniert für Prototypen und kleine Hilfsskripte oft überraschend gut. In Kundenprojekten mit Datenschutzanforderungen, Schnittstellen und mehrjähriger Wartung reicht es nicht.
Die Lehre aus dem Wissenschaftsbeispiel gilt hier genauso: Nicht das Modell entscheidet über Qualität, sondern der Rahmen, in dem es arbeitet. Für Softwareprojekte heißt das konkret:
- Automatisierte Tests als erste Prüfinstanz, damit generierter Code nicht nur kompiliert, sondern auch das Richtige tut.
- Verbindliches Code-Review durch Menschen, die den fachlichen Kontext kennen – nicht als Formalie, sondern als Entscheidungsschritt.
- Klare Spezifikation vor dem Prompt, weil unscharfe Aufgaben zu unscharfen Ergebnissen führen, nur eben schneller.
- Nachvollziehbarkeit: Es sollte dokumentiert sein, welche Teile KI-gestützt entstanden sind und wer sie geprüft hat.
- Werkzeuge für exakte Aufgaben, wo Genauigkeit zählt – Berechnungen, Validierungen und Migrationen gehören nicht in die Hände eines Textgenerators allein.
Was das für die Rollenverteilung heißt
Organisatorisch läuft diese Entwicklung auf eine Verschiebung von Kompetenzprofilen hinaus. Gefragt ist weniger die Fähigkeit, schnell Zeilen zu produzieren, und mehr die Fähigkeit, Ergebnisse zu beurteilen. Fachliche Tiefe wird dadurch nicht entwertet – sie wird zur Voraussetzung dafür, KI-Output überhaupt sinnvoll bewerten zu können.
Das betrifft auch die Projektplanung. Wenn Review zum eigentlichen Nadelöhr wird, ist es keine gute Idee, Review-Kapazität als Restposten zu behandeln. Sinnvoller ist es, Prüfschritte früh und fest einzuplanen und den Durchsatz daran auszurichten, was tatsächlich geprüft werden kann.
Realistische Erwartungen schlagen große Versprechen
Der beschriebene Fall ist kein Argument gegen KI-gestützte Arbeit – im Gegenteil. Er zeigt, dass sich mit einem guten Rahmen erstaunlich viel erreichen lässt, und zwar auch in anspruchsvollen Domänen. Er zeigt aber ebenso, dass der Rahmen nicht optional ist. Die Vorstellung, man könne ein Modell beauftragen und das Ergebnis ungeprüft weiterverwenden, hält der Praxis nicht stand.
Für Web- und Softwareprojekte folgt daraus eine nüchterne Rechnung: KI beschleunigt Entwürfe, Varianten und Routinearbeit, verschiebt den Engpass aber zu Prüfung und Steuerung. Projekte, die Review, Tests und klare Verantwortlichkeiten von Anfang an einplanen, profitieren deshalb deutlich stärker als solche, die auf reinen Output setzen. Wer KI einführt, sollte also nicht zuerst nach dem besten Modell fragen, sondern nach dem Rahmen, in dem dessen Ergebnisse überprüfbar werden.
