Warum QA das eigentliche Nadelöhr in der KI-Entwicklung ist

Das schwerste ungelöste Problem in der KI-Softwareentwicklung ist heute die Qualitätssicherung, nicht das Generieren. Features mit KI zu bauen ist billig und so gut wie gelöst. Die echte Grenze ist es zu prüfen, ob diese Features wirklich laufen, und zwar im Tempo und Umfang, in dem du sie jetzt erzeugen kannst. QA ist gerade die Decke für die Autonomie von Agents, weil Prüfen sich nicht so parallelisieren lässt wie Generieren.

Wir liefern seit rund 18 Monaten KI-gebaute SaaS aus, von Claude Opus 4.1 bis Claude Fable 5. In dieser Zeit wurde das Bauen drastisch schneller, während das Prüfen kaum vorankam. Diese Lücke ist die ganze Geschichte.

---

---

Bauen war nicht mehr der harte Teil

Build This Now ist ein KI-gestütztes SaaS-Build-System: eine Produktions-Codebasis plus 18 spezialisierte KI-Agents, die Features planen, bauen, testen und ausliefern, in normalem Deutsch beschrieben. Mit einem guten Agent-Gerüst und einer echten Produktions-Codebasis darunter ist das Generieren nicht mehr die Grenze.

Ein MVP, für das wir früher einen Monat brauchten, dauert jetzt einen Tag. Auth, Payments, Datenbank-Security, E-Mail, Background-Jobs: das meiste davon ist schon angebunden, und die KI baut die eigenen Features obendrauf. Die Kosten, ein funktionierendes Feature zu produzieren, fielen um eine Größenordnung.

Also taten wir das Naheliegende. Wir versuchten, mehr davon parallel laufen zu lassen.

Da liefen wir gegen die Wand.

Die Wand: Du kannst nicht alles prüfen, was du bauen kannst

Aus unserer Erfahrung ließen sich nicht mehr als etwa vier Features parallel verlässlich laufen, bevor es im Chaos endete. Die Build-Agents hielten locker mit. Das Prüfen nicht.

Ab etwa vier gleichzeitigen Features ging dreierlei schief:

1. Test-Läufe begannen zu kollidieren. Geteilter State, geteilte Datenbankzeilen, geteilte Ports. Das Test-Setup des einen Features trat dem Teardown des anderen auf die Füße.
2. Der State driftete weg. Die Umgebung, von der die Tests ausgingen, passte nicht mehr zu der, die wirklich da war, weil ein Geschwister-Agent sie unter ihnen verändert hatte.
3. Die Testing-Agents drehten sich in Schleifen. Sie wiederholten und prüften dieselben Abläufe erneut, ohne anzukommen, verbrannten Zeit und Tokens und wussten nicht, ob ein Fehler echt war oder bloß eine Kollision.

Nichts davon sind Probleme beim Generieren. Es sind Probleme beim Prüfen. Und sie werden schlimmer, nicht besser, je mehr parallele Arbeit du dazupackst.

Generieren skaliert. Prüfen nicht.

Das ist die zentrale Schieflage. Ein Feature zu generieren ist größtenteils eine eigenständige Aufgabe: gib einem Agent eine Spec und eine Codebasis, und er kann für sich allein arbeiten. Ein Feature zu prüfen ist eine Aufgabe in einer geteilten Welt: der Test muss echtes Verhalten in einer echten Umgebung beobachten, und genau diese Umgebung fasst auch jeder andere Agent an.

Du kannst zehn Agents auf zehn Features werfen und kriegst zehn Features. Du kannst nicht zehn Agents auf zehn Test-Suites in einer Umgebung werfen und zehn saubere Urteile kriegen. Die Prüfer streiten um dieselbe Welt.

Genau deshalb ist QA das Nadelöhr. Nicht, weil Testen abstrakt gesehen schwer wäre. Sondern weil Testen sich gegen genau das sträubt, was Generieren billig gemacht hat: viele Kopien gleichzeitig laufen zu lassen.

Die Verlässlichkeit fällt, je mehr du parallelisierst

So sah das aus, was wir beobachtet haben, aufgetragen als Features-parallel gegen die Frage, wie verlässlich das Prüfen blieb. Das sind unsere beobachteten Bänder, keine Benchmarks.

Die Build-Linie blieb über all das flach. Sieben Features konnten wir so leicht erzeugen wie zwei. Wir konnten den Testergebnissen für sieben nur nicht glauben.

Warum bessere Modelle helfen, es aber nicht lösen

Stärkere Modelle bringen echt etwas. Mehr Kontext heißt, ein Agent kann mehr vom System im Kopf behalten und macht weniger Fehler, also gibt es weniger nachzufangen. Weniger erzeugte Bugs sind weniger Bugs zu prüfen.

Claude Fable 5, Anthropics neuestes Modell für komplexe, lang laufende Arbeit (zu $10 pro Million Input-Tokens und $50 pro Million Output-Tokens), nimmt einen Teil des Problems auf andere Art auf. Es läuft längere Ketten, ohne wegzudriften, sodass ein Prüf-Agent über eine lange Test-und-Fix-Schleife hinweg den Faden hält, statt ihn auf halber Strecke zu verlieren und sich zu verheddern. Das trifft genau den Schleifen-Fehlermodus, gegen den wir immer wieder liefen.

Aber das hebt die Decke nur an. Es nimmt sie nicht weg. Die Schieflage ist strukturell. Solange das Prüfen Verhalten in einer geteilten Umgebung beobachten muss, bringt jeder zusätzliche parallele Prüfer mehr Streit um Ressourcen. Ein besseres Modell kommt schneller an und driftet weniger, was dir mehr gleichzeitige Features vor der Wand verschafft. Es schiebt die Wand nicht ins Unendliche.

QA in großem Maßstab ist immer noch die Grenze, und das ist der nächste echte Durchbruch. Wer herausfindet, wie man das Prüfen so parallelisiert, wie wir das Generieren längst parallelisieren, holt sich den nächsten Sprung um eine Größenordnung bei der Autonomie von Agents. Wir haben aus Grundprinzipien darüber geschrieben, warum Bauen nicht das Nadelöhr ist, und du siehst dieselbe Grenze in der Praxis auftauchen, wenn wir einen autonomen KI-Schwarm laufen lassen und uns auf gegnerische Evaluatoren stützen, um die Prüfer ehrlich zu halten.

FAQ

Warum können KI-Agents Code nicht in großem Maßstab testen?

KI-Agents können Code nicht in großem Maßstab testen, weil das Prüfen an einer geteilten Umgebung hängt, das Generieren aber nicht. Jeder Test muss echtes Verhalten in einem echten System beobachten, und wenn viele Agents parallel testen, streiten sie um dieselbe Datenbank, denselben State und dieselben Ressourcen. Generieren ist isoliert und parallelisiert gut. Prüfen kollidiert. Aus unserer Erfahrung fangen Test-Läufe ab etwa vier gleichzeitigen Features an, sich gegenseitig zu stören.

Wie viele KI-Agents laufen parallel, bevor die Qualität zusammenbricht?

Aus unserer Erfahrung, seit rund 18 Monaten KI-SaaS zu bauen, ließen sich nicht mehr als etwa vier Features parallel verlässlich laufen, bevor das Prüfen unverlässlich wurde. Die Build-Agents skalierten darüber hinaus problemlos, aber die Testing-Agents fingen an zu kollidieren, wegzudriften und in Schleifen zu laufen, ohne anzukommen. Die genaue Zahl hängt von der Isolation der Umgebung ab, aber die Schieflage zwischen Generieren und Prüfen bleibt gleich: Bauen skaliert, Prüfen nicht.

Was ist das eigentliche Nadelöhr in der KI-Softwareentwicklung?

Das eigentliche Nadelöhr in der KI-Softwareentwicklung ist die Qualitätssicherung, nicht das Generieren. Ein funktionierendes Feature mit einem guten Agent-Gerüst zu produzieren dauert jetzt einen Tag statt einen Monat. Diese Features im Tempo zu prüfen, in dem du sie erzeugen kannst, ist ungelöst, weil Prüfen sich nicht so parallelisieren lässt wie Generieren. QA ist heute die echte Decke für die Autonomie von Agents.

Beheben bessere Modelle das QA-Nadelöhr?

Bessere Modelle helfen, beheben es aber nicht. Mehr Kontext und weniger Fehler heißen weniger Bugs zu fangen, und Modelle wie Claude Fable 5 laufen längere Prüf-Ketten, ohne wegzudriften, was den Schleifen-Fehlermodus reduziert. Aber das Nadelöhr ist strukturell: Prüfen beobachtet eine geteilte Umgebung, also bringt jeder zusätzliche parallele Prüfer mehr Streit um Ressourcen. Stärkere Modelle heben die Decke an; sie nehmen sie nicht weg.

Wohin das als Nächstes führt

Generieren ist gelöst genug, dass es nicht mehr interessant ist. Das offene Problem ist Prüfen, das so skaliert wie Generieren. Wer paralleles QA knackt, schaltet die nächste Stufe an Autonomie frei, und genau diese Arbeit beobachten wir und bauen darauf hin, mit Claude Fable 5 und dem Gerüst drumherum.