Welches KI-Modell zur App-Generierung

Warum es keinen einzigen Sieger gibt

Ein vollständiger Build durchläuft Schritte, die einander nicht ähneln:

Planen heißt entscheiden, was aus einer mehrdeutigen Anfrage gebaut werden soll. Das verlangt Nachdenken und verträgt Wartezeit: zehn Sekunden für eine Entscheidung, die eine halbe Stunde falscher Arbeit erspart, sind gut angelegt.

Erzeugen heißt viele Dateien schreiben, die bekannten Regeln folgen. Das verlangt Durchsatz und Formattreue, und es ist der Schritt, in dem das teure Modell fast genau das liefert, was das billige liefert.

Reparieren heißt eine Compilermeldung lesen und die richtige Stelle ändern. Das ist der am stärksten vom Nachdenken abhängige Schritt, denn eine falsche Reparatur zerstört, was funktioniert hat.

Das Gebaute prüfen heißt Code gegen ein in klarer Sprache formuliertes Kriterium halten. Das ist Lesen, nicht Schreiben, und ein kleines Modell macht es gut.

Die Bildschirme prüfen verlangt Sehvermögen. Das ist keine Vorliebe: ein Modell ohne Vision kann schlicht nicht auf den Screenshot schauen und sagen, dass der Text aus der Karte gelaufen ist.

Ein Modell, das alle fünf gewinnt, wäre Zufall. In der Praxis gewinnt das System, das in jedem Schritt ein anderes Modell einsetzt.

Was Benchmarks messen, und was nicht

Die kursierenden Zahlen stammen fast alle aus Software-Engineering-Benchmarks: gegeben ein bestehendes Repository und ein gemeldeter Fehler, erzeugt das Modell einen Patch, der den Test bestehen lässt.

Das ist ein gutes Maß, und es misst etwas anderes. Eine App von Grund auf zu erzeugen unterscheidet sich in drei Punkten, die der Benchmark nicht erfasst:

Es gibt kein Repository zu verstehen. Die halbe Schwierigkeit im Benchmark besteht darin, in fremdem Code die Stelle zu finden. Beim Erzeugen entfällt dieses Problem, und an seine Stelle tritt die Stimmigkeit zwischen dreißig gleichzeitig entstehenden Dateien.

Es gibt keinen Test zu bestehen. Im Benchmark ist das Erfolgskriterium objektiv und bereits geschrieben. Bei einer neuen App ist das Kriterium das, was die Person verlangt hat, in natürlicher Sprache, vermutlich unvollständig.

Nichts misst, ob es schön geworden ist. Eine App, die kompiliert und hässlich ist, fällt beim Nutzer durch und besteht jeden Benchmark.

Praktischer Schluss: Nutzen Sie Benchmarks, um ein bei Code schwaches Modell auszusortieren, nie um zwischen den ersten beiden zu wählen.

Die Familien, und wofür sie taugen

Ohne Versionen zu nennen, denn die wechseln monatlich und die Seite wäre veraltet, bevor Sie hier ankommen.

Denkende Modelle. Sie überlegen vor der Antwort, verbrauchen mehr Token und mehr Zeit und entscheiden dort richtig, wo andere danebenliegen. Ihren Preis wert sind sie in den Entscheidungsschritten: beim Planen und beim Reparieren, nachdem eine einfache Reparatur bereits gescheitert ist.

Schnelle Modelle. Ein Bruchteil des Preises, ein Großteil der Qualität bei Aufgaben mit klarer Regel. Dort sollte der größte Teil des Build-Volumens laufen, denn der größte Teil eines Builds ist mechanisch.

Modelle mit Vision. Nötig für alles, was das gerenderte Ergebnis anschauen muss. Ohne sie gibt es keine visuelle Durchsicht, nur Code-Durchsicht.

Offene Modelle. Sie haben bei der Codeerzeugung viel aufgeholt und verlangen deutlich weniger. Sie sind der Grund, warum die Kosten pro App in zwei Jahren so stark gefallen sind.

Wie Fabapp das löst

Wir sind Partei, das Folgende ist also Beschreibung, keine Empfehlung. Beurteilen Sie es an dem, was sich durch Öffnen der Plattform überprüfen lässt.

Ein Katalog, kein Modell. Die Plattform führt einen Katalog von Modellen mehrerer Anbieter, jedes mit Kosten je tausend Token, abgeleitet aus dem öffentlichen Tarif des Anbieters. Dieser Katalog macht es möglich zu ändern, welches Modell welchen Schritt ausführt, ohne den Produktcode anzufassen. Was die Plattform sonst noch kann, steht auf Funktionen.

Der Schritt wählt, nicht Sie. Standardmäßig nutzt jeder Schritt des Builds das passende Modell: Planung und Reparatur auf stärkeren Modellen, Erzeugung auf Durchsatzmodellen, die Abnahmeprüfung auf einem kleinen Modell, die visuelle Durchsicht auf einem Modell mit Vision. Sie müssen davon nichts wissen, um eine App zu bauen.

Wählen dürfen Sie trotzdem. Die Modellauswahl gibt es, und den eigenen Schlüssel auch: ab dem Tarif Builder verbinden Sie Ihren Anbieterschlüssel, und der Verbrauch läuft über Ihr Konto. Das interessiert alle, die bereits einen Anbietervertrag haben oder die Daten über ein bestimmtes Konto führen müssen.

Ein Credit ist eine Kosteneinheit. Der Verbrauch wird gegen ein Referenzmodell normalisiert, ein Credit steht also für ungefähr dieselbe Arbeit, unabhängig vom ausführenden Modell. Das verhindert, dass ein Modellwechsel stillschweigend ändert, wie weit Ihr Tarif reicht.

Die Reparatur zahlen nicht Sie. Wenn die Prüfung durchfällt und das System repariert, wird diese Runde Ihnen nicht berechnet. Dass die Plattform ihre eigene Ausgabe korrigiert, ist keine erbrachte Leistung.

Wann sich ein Modellwechsel lohnt

Meistens nicht. Drei Fälle, in denen doch:

Sie haben einen Vertrag mit einem Anbieter. Der eigene Schlüssel verwandelt Plattformkosten in Kosten, die Sie ohnehin tragen.

Sie haben Vorgaben zum Datenweg. Manche Unternehmensverträge und manche Vorschriften verlangen das, und die Modellauswahl beantwortet diese berechtigte Anforderung.

Sie erzeugen etwas Ungewöhnliches. Eine sehr spezifische Domäne, eine wenig vertretene Sprache, ein seltenes Format. Dort beantwortet ein Test zweier Modelle auf dieselbe Anfrage die Frage schneller als jede Analyse.

Außerhalb dieser drei optimiert ein Modellwechsel den Teil, der nicht der Engpass ist. Der Engpass ist fast immer die Klarheit der Anfrage.

Was das Ergebnis wirklich verbessert

Wenn Ihr Ziel eine bessere App ist und kein Modellexperiment, ist das die Reihenfolge nach Ertrag:

1. Beschreiben Sie besser. Der Abstand zwischen einer vagen und einer präzisen Anfrage ist größer als der Abstand zwischen zwei Spitzenmodellen. Sagen Sie, wer sie benutzt, was jede Person sehen darf und was passieren muss, wenn jemand das Formular absendet.

2. Fragen Sie in Stücken. Eine große Anfrage ergibt eine große, mittelmäßige App. Drei verkettete Anfragen ergeben eine App, die Sie an drei Punkten geprüft haben.

3. Prüfen Sie gegen die Datenbank, nicht gegen den Bildschirm. Die Erfolgsmeldung ist genau das, was ein kaputtes Formular auch zeigt.

4. Erst dann das Modell. Und Sie werden vermutlich feststellen, dass es nicht nötig war.

Das Ende der Modellwahl

Das ist die Richtung der ganzen Branche, und sie ist gut: die Modellwahl ist eine Infrastrukturentscheidung, die zum Nutzer durchgesickert ist, weil der Unterschied zwischen den Modellen eine Zeit lang zu groß war, um ihn zu verbergen. Er schrumpft.

Was nicht schrumpft, ist der Unterschied zwischen einem System, das das Modell nur aufruft, und einem System, das prüft, was zurückkam. Dort entscheidet sich heute die Qualität einer erzeugten App, und das ist der Teil, den kein Modellanbieter fertig ausliefert.

Bei Fabapp fragt der Free-Tarif nicht nach einer Karte, und das ist der billigste Weg, all das mit jeder Alternative zu vergleichen.