Bauen ist nicht mehr der Flaschenhals

Ein SaaS zu bauen ist nicht mehr der schwere Teil. Wir liefern seit fast zwei Jahren Produktiv-Apps mit KI-Agenten aus, von Claude 3.5 Sonnet bis hin zu Claude Fable 5. In der Zeit ist der Flaschenhals zweimal umgezogen. Es ist nicht die Forschung. Es ist nicht der Code. Zwei Dinge tun immer noch weh: Qualitätssicherung im großen Maßstab und Distribution.

Das hier haben wir gelernt, während echte Leute auf unserem Stack gebaut haben. Und das hat sich verändert, jedes Mal wenn ein neues Modell kam.

---

---

Das Bauen war schneller gelöst, als irgendwer geplant hatte

Vor zwei Jahren war der Bau selbst die Mauer. Auth, Payments, Datenbank-Sicherheit, E-Mail, Background Jobs. Monate an Klempnerarbeit, bevor du überhaupt am Produkt warst. Diese Mauer ist weg. Mit einem guten Gerüst und einer Produktiv-Codebasis darunter dauert ein MVP, das früher einen Monat brauchte, jetzt einen Tag.

So schnell hatten wir es nicht erwartet. Wir haben mit Claude 3.5 Sonnet angefangen und zugesehen, wie die ganze Sonnet- und Opus-Reihe Release für Release besser wurde. Jedes Modell ließ uns den Agents mehr Leine geben. Der Code war irgendwann nicht mehr die Sorge. Klingt nach Ziellinie. Ist es nicht. Er legt nur frei, was die ganze Zeit hinter dem Bauen versteckt war.

Neuer Flaschenhals #1: QA im großen Maßstab

Das schwerste ungelöste Problem in der KI-Entwicklung gerade ist die Qualitätssicherung, nicht die Generierung. Ein Feature zu generieren ist billig. Zu beweisen, dass es funktioniert, in großer Menge, ohne dass ein Mensch jeden Lauf babysittet, hat noch keiner ganz geknackt.

Hier ist die konkrete Grenze, an die wir gestoßen sind: Mehr als ungefähr vier Features parallel konnten wir nicht zuverlässig laufen lassen, bevor es ein Chaos wurde. Darüber hinaus kollidierten Test-Läufe, der State driftete, und die Test-Agents drehten manchmal Schleifen, liefen und prüften immer wieder, ohne je auf ein Ergebnis zu kommen. Die Bau-Seite skalierte. Die Prüf-Seite nicht. Diese Lücke ist heute die echte Decke für Autonomie. Und jeder, der dir erzählt, er fahre voll autonome Agent-Schwärme im großen Maßstab, löst genau dieses Problem im Stillen (oder ignoriert es).

Bessere Modelle helfen, weil fähigere Modelle mehr Kontext halten und weniger der Fehler machen, die man abfangen muss. Aber QA im großen Maßstab ist immer noch die Grenze. Da liegt der nächste echte Durchbruch.

Neuer Flaschenhals #2: Distribution

Die zweite Mauer ist Distribution, und in die rennen die meisten Builder direkt rein. Als das Bauen Monate dauerte, fühlte sich Distribution nach einem späteren Problem an. Jetzt, wo das Bauen einen Tag dauert, ist Distribution das ganze Spiel. Du kannst an einem Wochenende ein tolles Produkt ausliefern, und keiner kriegt es je zu sehen.

Genau deshalb haben wir nicht nur ein Build-System gebaut. Wir haben ein Ökosystem gebaut: etwas zum Bauen und etwas zum Verteilen. Topr.io ist unsere Antwort auf der Distributions-Seite, ein UGC-Marktplatz auf demselben Build This Now Stack, direkt auf den Teil gerichtet, der schwerer wurde, nicht leichter. Die Lehre dahinter ist simpel. Wenn das Bauen Massenware ist, liegt der Burggraben darin, gefunden zu werden.

Was Fable 5 ändert: mehr Auslauf

Claude Fable 5 ist Anthropics neuestes Modell für komplexe, lang laufende Arbeit. Der praktische Unterschied ist, wie viel Freiheit du ihm geben kannst. Du kannst ihm mehr Auslauf geben, längere Aufgaben, mehr Autonomie in einem einzigen Durchgang, und es hält durch. Für ein Agent-Gerüst ist das die Variable, auf die es am meisten ankommt. Je zuverlässiger ein Modell eine lange Kette durchläuft, ohne abzudriften, desto mehr vom QA-Problem fängt es von allein ab.

Wir haben jede Stufe dieser Kurve gespürt. Ungefähr so ist der Flaschenhals umgezogen:

Fable 5 läuft zu einem höheren Preis als Opus 4.8 ($10 Input / $50 Output pro Million Tokens), weil es für die langen, harten, autonomen Läufe gebaut ist. Für den Alltags-Code ist Opus 4.8 immer noch das bessere Preis-Leistungs-Verhältnis. Für die Jobs, bei denen du eine lange Aufgabe abgeben und weggehen willst, ist genau der extra Auslauf der Punkt.

Der unintuitive Teil: Grundlagen zählen jetzt mehr, nicht weniger

Das hat uns am meisten überrascht. Je schneller das Bauen wurde, desto mehr zählten die alten Startup-Grundlagen.

Wenn du alles an einem Tag bauen kannst, ist die Versuchung, zehn Dinge zu bauen. Das ist der schnellste Weg zu scheitern. KI schafft die Gesetze von Startups nicht ab. Sie industrialisiert den Bau-Schritt und lässt jedes andere Gesetz genau dort, wo es war. Fokus. Differenzierung. Liebe zum Detail. Such dir eine Sache aus, mach sie gut, liefere sie vor allen anderen aus.

Wenn überhaupt, erhöht das Tempo den Einsatz darauf, die Grundlagen richtig hinzubekommen, denn alle anderen können beim Bauen jetzt genauso schnell sein. Der Bau ist nicht mehr dein Vorsprung. Die ersten Prinzipien sind es.

Wie wir heute bauen

Das Muster, das jedes Mal funktioniert:

1. Geh zu den ersten Prinzipien. Schäl die Idee auf die eine Sache runter, die sie können muss. Nicht die Roadmap. Die eine Sache.
2. Liefere das erste MVP in 24 Stunden aus. Nicht eine Woche. Nicht zwei. Einen Tag. Das Tooling macht das jetzt real, also behandel es als Standard, nicht als ehrgeiziges Ziel.
3. Renn zum Product-Market-Fit. Das MVP existiert, um Feedback zu holen, nicht Applaus. Bring es vor Nutzer und lass die Realität dir sagen, was als Nächstes zu bauen ist.
4. Steck die gesparte Zeit in Distribution und QA. Da leben die schweren Probleme wirklich. Der Bau ist jetzt der billige Teil, also leg deine Aufmerksamkeit auf die teuren Teile.

Eine Sache machen, sie gut machen, schnell ausliefern, gefunden werden. Das ist das ganze Spiel in 2026.

FAQ

Ist ein SaaS zu bauen mit KI immer noch schwer?

Der Code ist nicht mehr der schwere Teil. Mit einer Produktiv-Codebasis und einem guten Agent-Gerüst dauert ein MVP, das einen Monat brauchte, jetzt etwa einen Tag. Die schweren Teile sind zur Qualitätssicherung im großen Maßstab und zur Distribution gewandert, also dazu, dein Produkt gefunden zu kriegen, wenn es erst mal existiert.

Warum können KI-Agents noch nicht unbegrenzt Features parallel laufen lassen?

Qualitätssicherung lässt sich nicht so sauber parallelisieren wie Generierung. Aus unserer Erfahrung kannst du ungefähr vier Features parallel laufen lassen, bevor Test-Läufe kollidieren, der State driftet und Test-Agents anfangen, Schleifen zu drehen, ohne zu einem Ergebnis zu kommen. Features zu generieren skaliert; sie in großer Menge zuverlässig zu prüfen ist immer noch die Grenze.

Was macht Claude Fable 5 für die Agent-Arbeit anders?

Claude Fable 5 ist für komplexe, lang laufende Aufgaben gebaut und kann in einem einzigen Durchgang mehr Autonomie bekommen, ohne abzudriften. Für ein Agent-Gerüst ist diese Zuverlässigkeit über lange Ketten die wichtigste Eigenschaft, weil sie einen Teil der QA-Last abnimmt. Es kostet $10 Input / $50 Output pro Million Tokens.

Wenn KI das Bauen schnell macht, was ist dann der echte Wettbewerbsvorteil?

Die Grundlagen. Wenn alle schnell bauen können, hört der Bau auf, ein Burggraben zu sein. Der Vorsprung wandert zu Fokus, Differenzierung, Distribution und dazu, vor allen anderen zum Product-Market-Fit zu kommen. Das Tempo erhöht den Einsatz auf die ersten Prinzipien, es nimmt sie nicht weg.

---

Wir sind in etwa achtzehn Monaten von "Bauen ist die Mauer" zu "Bauen ist der leichte Teil" gekommen. Die Teams, die die nächste Strecke gewinnen, sind nicht die, die am schnellsten bauen. Schnell baut jetzt jeder. Es sind die, die sich eine Sache aussuchen, sie perfekt machen und sie vor Leute bringen. Schau dir an, wie die ganze Pipeline funktioniert, oder fang an, genau das jetzt zu bauen.