Grundlagen: wie der Builder denkt

Der Plan, den man überspringt, ist der Ausfall, den man später debuggt

Jedes Framework der Softwareentwicklung sagt Ihnen: schnell handeln, früh ausliefern, in der Produktion iterieren. Bei KI-generierten Websites ist das genau falsch herum. Der Builder hier weigert sich, Code direkt aus Ihrem Prompt zu streamen — er hält an, schreibt einen Plan und wartet, bis Sie ihn sich angesehen haben —, und diese Weigerung ist die eine Entscheidung, auf der alles andere in dieser Pipeline aufbaut. Vorne langsamer, danach überall günstiger. Diesen Tausch gehe ich jederzeit ein, und ich glaube, die meisten, die das Gegenteil vertreten, haben nicht wirklich gesehen, was eine falsche Vermutung im weiteren Verlauf kostet.

Hier ist das Fehlerszenario, das der Plan verhindern soll. Sie tippen „eine Buchungsseite für mein Studio“ ein und drücken Los. Das System muss erraten, was „Buchung“ bedeutet — ein Kalender-Widget, eine eingebettete Drittanbieterlösung oder ein echtes Reservierungssystem mit Konfliktprüfung —, und es muss das erraten, bevor es überhaupt etwas geschrieben hat, weil es keine andere Reihenfolge gibt. Verrät man sich innerhalb eines Plans, kostet die Korrektur einen Satz, fünf Sekunden, erledigt. Verrät man sich im bereits generierten Code, bearbeitet man keinen Satz mehr, sondern muss zehn Dateien zurückbauen, die schon auf der falschen Annahme aufsetzen. Ich habe beide Fälle erlebt. Die Korrektur in der Planphase ist ein Austausch. Die Kurskorrektur nach der Generierung bei derselben Unklarheit ist ein Verwerfen und Neuaufbauen.

Der Plan ist auch nicht nur eine To-do-Liste — das übersehen viele. Er ist ein Vertrag, und das System hält sich selbst daran: Ein Konformitätsprüfer, einer der Agenten, der grünes Licht geben muss, bevor ein Build ausgeliefert wird, gleicht die fertige Seite mit dem von Ihnen genehmigten Plan ab. Wurde jede geplante Seite gebaut? Entspricht die Funktionsliste dem, was ausgeliefert wurde? „Fertig“ ist hier kein Gefühl — es ist relativ zu einem schriftlichen Versprechen, Zeile für Zeile überprüfbar. Das ist eine stärkere Garantie als „der Code läuft“, und die bekommt man nur, weil es ein Dokument gibt, gegen das geprüft werden kann. Nimmt man den Plan weg, nimmt man den Maßstab weg.

Wo sich das wirklich auszahlt

Ihr Einfluss als Person, die den Build vorantreibt, ist vorgelagert — ob Sie ihn nutzen oder nicht. Wenn Ihnen Informationsarchitektur, Seitenstruktur oder die Frage wichtig sind, welche Funktionen in Version 1 gegenüber Version 2 landen, dann ist diese Genauigkeit bei der Plan-Überprüfung zehnmal mehr wert als nach dem ersten Generierungsdurchlauf. Vier zusätzliche Minuten, um den Plan noch einmal durchzulesen, schlagen einen weiteren Durchlauf zur Fehlerbehebung an einem bereits schiefgelaufenen Build.

Das deutlichste Beispiel ist der Produkttyp — reine statische Website, installierbare App, Framework-Build, serverbasierte App mit echter Datenspeicherung. Das sieht aus wie ein Dropdown-Menü. Ist es aber nicht. Es ist die strukturellste Entscheidung im gesamten Prozess, weil sie stillschweigend ein Dutzend Dinge festlegt, die nichts damit zu tun haben, wie die Seite aussieht.

Und man kann den Typ später nicht einfach beiläufig upgraden. Von einer einfachen statischen Seite zu einer serverbasierten App zu wechseln ist kein Schalter in den Einstellungen — es kommt fast einem zweiten Build gleich, weil die Hälfte der Annahmen des Plans (wie Seiten geladen werden, wo Daten liegen, was „veröffentlichen“ bedeutet) auf den alten Typ zugeschnitten waren. Sagen Sie es also schon bei der Planung, auch wenn Sie sich nur halb sicher sind: „Es besteht die Möglichkeit, dass ich Konten brauche.“ Eine serverbasierte App einzuplanen und nur die statischen Teile zu nutzen kostet nichts. Erst im Nachhinein festzustellen, dass man eine gebraucht hätte, kostet einen kompletten Neubau.

Wo die Kritiker recht haben

Nichts davon ist kostenlos, und ich werde nicht so tun, als wäre es das. Isolierte Workspaces pro Lauf bedeuten, dass Ihre Wissensdateien frisch hineinkopiert werden und nichts auf Ihren Rechner zurückgreift — gut für Sie, falls Ihr Laptop mitten im Build abstürzt, schlecht für die Latenz, weil das Bereitstellen eines Workspace und, bei Framework-Builds, das Ausführen einer echten Abhängigkeitsinstallation innerhalb einer Container-Grenze reale Wartezeit kostet. Diese Container-Grenze existiert, weil ein Framework-Build `npm install` und beliebige Build-Skripte ausführt — Code, den Sie nicht geschrieben haben und der mit Build-Zeit-Rechten läuft —, und das auf einem gemeinsam genutzten Host ohne Isolation durchzuführen, ist nur einen Dependency-Confusion-Angriff davon entfernt, die Daten eines anderen Mandanten zu berühren. Schnell und unsicher wäre möglich gewesen. Es war nur kein Tausch, der sich gelohnt hätte.

Bei der Verifizierung ist es dasselbe. Ein fertiger Build verlässt die Pipeline nicht, wenn die Generierung endet; er verlässt sie, wenn eine Reihe unabhängiger Prüfer nichts mehr findet, das eine Blockade rechtfertigt:

• Code-Review
• Sicherheit
• Links und SEO
• Barrierefreiheit
• Konformität
• Ein echter Testlauf im Browser

Das ist kein einzelner Durchgang, sondern Melden-Beheben-Erneutprüfen in einer Schleife, bis niemand mehr etwas anzumerken hat, denn ein einzelner Linter-Durchgang kann eine Regression übersehen, die seine eigene Korrektur verursacht. Einen defekten Link zu reparieren und dabei versehentlich die Überschriftenhierarchie auf derselben Seite zu zerstören ist genau die Art von Fehler, die eine einmalige Prüfung übersieht und eine erneute Prüfung findet. Die ehrlichen Kosten dieser Schleife sind, dass ein Build gelegentlich ganz am Ende eine zusätzliche Minute ohne sichtbaren Grund braucht. Diese Minute fällt den Leuten auf. Nicht auf fällt ihnen, dass sechs Agenten gerade fertig diskutiert haben, ob ihre Website in Ordnung ist. Das ist ein berechtigter Einwand zur Erfahrung — ich halte es nur nicht für ein gutes Argument, ohne diese Diskussion überhaupt auszuliefern.