Was ein KI-Builder nicht bauen kann: ehrliche Grenzen

Was kann ein KI-Builder nicht bauen?

Ein KI-Builder scheitert selten an der Größe eines Projekts, fast immer an dessen Eigenheit. Websites, Shops, kleine Arbeitswerkzeuge und 2D-Spiele für den Browser entstehen verlässlich. Nicht geliefert werden dagegen: sehr spezifische Fachlogik aus einem einzigen Prompt, Anwendungen für den App-Store, 3D-Spiele und Produkte, die dauerhaft von einem Team betreut werden müssen.

Diese Antwort ist unbequemer als das übliche Marketing, und genau deshalb steht sie oben. Wer die Grenze vorher kennt, plant um sie herum. Wer sie erst nach drei enttäuschten Anläufen entdeckt, hält das Werkzeug für schlecht, obwohl es nur für etwas anderes gebaut war.

Warum ist „zu groß" fast nie das eigentliche Problem?

Der Umfang einer Website sagt wenig darüber aus, wie schwer sie zu erzeugen ist. Eine Plattform mit zwölf Seiten besteht aus zwölf Mal derselben Art von Arbeit, und wiederholte Arbeit ist genau das, was ein Generator gut kann. Länge ist Menge, und Menge ist billig.

Schwer wird es an anderer Stelle: bei Regeln, die nur in Ihrem Kopf existieren. Ein Preis, der von Wochentag, Mitgliedsstatus und Restbestand abhängt. Eine Freigabe, die zwei Personen brauchen, aber nur, wenn die Summe über einer Grenze liegt. Solche Regeln kann niemand erraten, auch kein Modell.

Der Unterschied lässt sich in einem Satz zusammenfassen. Was in einem Satz beschreibbar ist, entsteht in einem Durchgang. Was eine halbe Seite Bedingungen braucht, entsteht über mehrere Änderungen, und das ist kein Fehler des Werkzeugs, sondern die normale Form, in der Software entsteht.

Was entsteht zuverlässig, und was nicht?

Die folgende Aufstellung ist bewusst grob gehalten. Sie soll vor dem ersten Versuch eine Erwartung setzen, nicht jeden Sonderfall abdecken.

Die untere Hälfte der Tabelle ist der Teil, den man vorher lesen sollte. Sie beschreibt keine vorübergehenden Lücken, die im nächsten Quartal verschwinden, sondern die Bauart des Werkzeugs.

Warum scheitert sehr spezifische Fachlogik am einzelnen Prompt?

Weil ein Prompt eine Beschreibung ist und Fachlogik eine Sammlung von Ausnahmen. Sie beschreiben ein Buchungssystem in vier Sätzen, und in Ihrem Betrieb gelten dazu neun Regeln, die Sie so verinnerlicht haben, dass sie Ihnen beim Schreiben gar nicht einfallen.

Das Ergebnis ist dann nicht falsch, sondern allgemein. Es bucht Termine, aber es kennt Ihre Vorlaufzeit nicht, Ihre Doppelbelegung nicht und Ihre Stornoregel nicht. Diese drei Dinge kommen als Änderungen dazu, eine nach der anderen, jede für sich beschreibbar und prüfbar.

Genau so arbeitet man mit einem Builder sinnvoll: erst das Gerüst, dann die Eigenheiten. Wie ein tragfähiger erster Prompt aussieht, steht ausführlich in Guten Prompt für eine Website schreiben. Der zweite Teil des Wegs ist in KI-Website nachträglich bearbeiten beschrieben.

Welche Projekte brauchen weiterhin ein Entwicklungsteam?

Es gibt eine klare Trennlinie, und sie verläuft nicht bei der Komplexität, sondern bei der Dauer. Ein Projekt, das einmal gebaut und danach gelegentlich gepflegt wird, ist Builder-Gebiet. Ein Produkt, an dem über Jahre hinweg mehrere Personen gleichzeitig arbeiten, ist es nicht.

Dazu kommen drei Fälle, bei denen ich ohne Umschweife zu Menschen raten würde. Erstens: strenge regulatorische Anforderungen, etwa im Gesundheits- oder Finanzbereich, wo jemand für die Umsetzung haften muss. Zweitens: Anbindungen an Altsysteme, deren Schnittstellen niemand außerhalb Ihres Hauses kennt. Drittens: Leistungsanforderungen, die aus großen Datenmengen kommen.

Das heißt nicht, dass der Builder in diesen Fällen nutzlos ist. Er ist dort ein hervorragendes Mittel für den ersten sichtbaren Stand, mit dem sich intern diskutieren lässt. Wie die Übergabe an eine Entwicklerin oder einen Entwickler abläuft, beschreibt Kann ein Entwickler ein KI-Projekt später übernehmen.

Was gilt bei Spielen?

Spiele entstehen bei Zugo als 2D-Projekte, die im Browser laufen. Das deckt eine überraschend große Bandbreite ab: Puzzle, Plattformer, Endless Runner, Kartenspiele, Quiz, Tower Defense. Fünf der insgesamt 25 Vorlagen sind Spielvorlagen, und für einen Prototyp ist der Weg dorthin kurz.

Nicht abgedeckt ist alles, was darüber hinausgeht. Dreidimensionale Welten gehören dazu, ebenso ein Mehrspielermodus mit Servern im Hintergrund und alles, was als installierbare Fassung in einem Store landen soll. Wer damit plant, ist mit einer klassischen Spiele-Engine besser bedient, und das ist keine Schwäche des einen oder des anderen Werkzeugs.

Was innerhalb der Grenze möglich ist, zeigt Kann KI wirklich ein spielbares Spiel bauen. Kurz gefasst: ja, und schneller als erwartet, solange der Rahmen 2D und Browser heißt.

Woran erkenne ich vorab, dass mein Vorhaben an der Grenze liegt?

Drei Fragen genügen meistens. Erstens: Kann ich das Vorhaben einer fremden Person in fünf Sätzen so erklären, dass sie es korrekt nachbauen könnte? Wenn nein, fehlen Regeln, die nur Sie kennen, und die müssen als Änderungen nachgereicht werden.

Zweitens: Läuft es im Browser? Alles, was Zugo erzeugt, wird unter einer Adresse veröffentlicht und dort geöffnet, standardmäßig auf zugo.run, auf Wunsch unter Ihrer eigenen Domain. Wer eine installierbare Anwendung braucht, sucht ein anderes Werkzeug.

Drittens: Wer pflegt das Ding in zwei Jahren? Gibt es darauf keine Antwort, ist das kein Argument gegen den Builder, aber ein Grund, die Quellen früh über die GitHub-Anbindung in ein eigenes Repository zu holen.

Was kostet der Versuch, wenn ich es trotzdem probiere?

Ein Versuch an der Grenze ist selten teuer, und das ist der beste Grund, ihn zu machen statt lange zu diskutieren.

Die Tarife dazu: Free enthält 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business 99 $ im Monat mit 800 Credits. Zweihundert Credits entsprechen etwa 16 mehrseitigen Plattformen oder 33 Builds oder 66 Änderungen. Ein Hinweis, der vorher fair ist: Die 5 Credits im kostenlosen Tarif liegen unter den 6, die ein einzelner Build kostet.

Zeitlich steht eine einfache Seite in etwa einer Minute, eine mehrseitige Plattform in einigen Minuten. Jeder Build wird vorher in einer Sandbox geprüft, und was dort nicht öffnet, wird gar nicht erst ausgeliefert. Das garantiert, dass etwas startet. Es garantiert nicht, dass es fachlich richtig ist.

Was ist der vernünftige Umgang mit diesen Grenzen?

Nicht Vermeidung, sondern Zuschnitt. Nehmen Sie den Teil Ihres Vorhabens, der standardisiert ist, und lassen Sie ihn erzeugen: Seitenstruktur, Texte, Formulare, Zahlungen, Anmeldung. Das ist meistens der größere Teil und fast immer der langweiligere.

Den eigenwilligen Rest bauen Sie in Schritten dazu, jede Regel als eigene Änderung. Und wenn sich beim dritten Anlauf herausstellt, dass der Kern Ihres Produkts genau dieser Rest ist, dann haben Sie eine wertvolle Information gewonnen und dafür weniger ausgegeben als für ein Vorgespräch mit einer Agentur.

Ausprobieren, wo bei Ihrem konkreten Vorhaben die Grenze verläuft, können Sie auf zugo.dev. Die ehrlichste Antwort auf die Frage nach den Grenzen ist am Ende der erste Build, den Sie sich ansehen.