Die erste Version steht. Viel früher, als sie ohne AI fertig gewesen wäre. Wer mit diesen Werkzeugen arbeitet, kennt diesen Moment: Man sieht das Ergebnis und denkt sofort daran, was jetzt noch alles möglich wäre.
Genau da lohnt es sich, kurz innezuhalten. Denn auf dem Bildschirm ist schon etwas fertig, das im Kopf erst noch verstanden werden muss. Welche Annahmen stecken darin? Was wurde vereinfacht? Funktioniert die Lösung auch dann, wenn jemand etwas anderes tut als vorgesehen?
Wir werden mit AI schneller. Das erleben wir in unserer Arbeit. Gleichzeitig steigt der Aufwand für Review und Korrekturen. Ein Teil der gewonnenen Zeit fliesst dort wieder hinein. Wer aus einem zehnmal schnelleren ersten Entwurf zehnmal mehr Kapazität ableitet, lässt einen wesentlichen Teil der Arbeit aus der Rechnung.
Der schnelle Teil ist besonders gut sichtbar
Ein Prototyp lässt sich anklicken. Eine Recherche hat ein Ergebnis. Eine Funktion läuft. Das ist sichtbar und fühlt sich nach Fortschritt an. Die Prüfung dahinter hat weniger vorzeigbare Momente. Man liest, hinterfragt, testet und verwirft vielleicht eine Lösung, die gerade noch überzeugend aussah.
Nehmen wir einen Erfassungsprozess in einer Webapp. Die AI baut ein Formular, speichert die Eingabe und zeigt eine Bestätigung. Der Standardablauf funktioniert. Damit sind aber weder die Berechtigungen geklärt noch das Verhalten bei einer unterbrochenen Verbindung oder einer doppelt gesendeten Anfrage. Diese Fragen gehören zum Produkt, auch wenn die Demo ohne sie gut aussieht.
Solche Prüfungen braucht selbstverständlich auch menschlich geschriebener Code. Mit AI kann allerdings sehr viel mehr Code entstehen, bevor jemand seine Entscheidungen im Detail nachvollzogen hat. Wer selbst entwickelt, baut dieses Verständnis während der Arbeit auf. Bei einer generierten Lösung muss ein Teil davon nachträglich entstehen. Das kostet Konzentration.
Derselbe Prompt ist keine Garantie
Zweimal dieselbe Frage, zwei unterschiedliche Antworten: Für die Suche nach Ideen kann das hilfreich sein. Bei einer Umsetzung kann es bedeuten, dass die AI andere Annahmen trifft, eine zusätzliche Bibliothek verwendet oder denselben Sonderfall anders behandelt. Der Prompt allein legt das Ergebnis nicht zuverlässig fest.
Hier spielt Determinismus eine Rolle: Unter denselben Bedingungen entsteht dasselbe Ergebnis. Bei generativen Sprachmodellen ist diese Wiederholbarkeit je nach Modell und Einstellungen nur begrenzt gegeben. Selbst Optionen für reproduzierbare Ausgaben bieten nicht immer eine Garantie. Die API-Dokumentation von OpenAI benennt diese Grenze ausdrücklich.
Daraus folgt für uns, dass wir die Anforderungen und die Prüfung ausserhalb des Prompts festhalten müssen. AI kann ein festes Skript ausführen, Tests schreiben oder einen überprüfbaren Beweis vorschlagen. Ob das Ergebnis trägt, muss sich an diesen Grundlagen zeigen. Eine zweite überzeugende Antwort reicht dafür nicht. Und ein Ergebnis, das jedes Mal identisch ist, kann jedes Mal denselben Fehler enthalten.
Da geht doch noch eine Kleinigkeit
Ein zusätzlicher Filter wäre praktisch. Eine Exportfunktion auch. Und wenn wir ohnehin dabei sind, könnte die AI noch eine zweite Ansicht bauen. Jede Ergänzung wirkt klein, weil ihre erste Umsetzung so wenig Aufwand verlangt.
Zusammen verändern diese Ergänzungen das Vorhaben. Der Filter braucht nachvollziehbare Regeln. Der Export muss Berechtigungen berücksichtigen. Die zweite Ansicht braucht dieselben Zustände wie die erste. Aus einer schnellen Idee werden Beziehungen, die jemand verstehen und dauerhaft pflegen muss. Die Frage, welches Problem wir eigentlich lösen wollten, rückt dabei leicht in den Hintergrund.
Dazu kommen die offenen Vorgänge im Kopf: Hier wartet ein Ergebnis auf Prüfung, dort läuft bereits die nächste Aufgabe. Man wechselt zwischen Lösungen, die jeweils eigenen Kontext verlangen. So kann sich ein produktiver Tag erstaunlich anstrengend anfühlen. Gerade weil so viel möglich wird, entsteht der Druck, diese Möglichkeiten auch auszuschöpfen.
Eine achtmonatige Untersuchung von UC Berkeley Haas in einem Technologieunternehmen beschreibt eine ähnliche Entwicklung: mehr parallele Aufgaben, einen breiteren Arbeitsumfang und Arbeit, die in bisherige Pausen hineinreicht. Das ist eine Beobachtung aus einem Unternehmen, kein allgemeines Urteil über AI. Für uns macht sie eine wichtige Frage greifbar: Wie viel zusätzliche Arbeit verträgt die gewonnene Geschwindigkeit?
Review beginnt mit der ersten Änderung
«Das schauen wir uns am Schluss noch einmal an» klingt vernünftig, solange man sich vorstellen kann, was bis dahin entstanden ist. Wenn sich aber Änderung auf Änderung stapelt, wird aus dem abschliessenden Review eine Rekonstruktion. Warum gibt es diese Abhängigkeit? Welche Funktion nutzt sie? War diese Ausnahme gewollt oder ein Vorschlag der AI?
Dieses Verständnis aufzuholen ist schwer. Die nächste Änderung setzt bereits auf Entscheidungen auf, die niemand sauber eingeordnet hat. Eine Korrektur an einer Stelle kann dann an einer anderen etwas verändern, dessen Zusammenhang erst noch gefunden werden muss.
Deshalb muss Review von Anfang an gelebt werden. Für uns heisst das: Änderungen in überschaubaren Schritten verstehen, die wichtigen Annahmen prüfen und festhalten, warum eine Entscheidung getroffen wurde. Dabei hilft eine Erklärung der AI als Ausgangspunkt. Abgleichen müssen wir sie mit dem tatsächlichen Code, den Anforderungen und dem beobachteten Verhalten.
Der Aufwand richtet sich nach den möglichen Folgen. Eine verworfene Layoutvariante braucht eine andere Prüfung als eine Änderung an Zugriffsrechten. Entscheidend ist, dass die nächste Aufgabe auf einem verstandenen Stand aufbaut. Review ist Teil der Entwicklung und braucht dort seinen Platz im Zeitplan.
Es läuft. Dürfen wir es auch so einsetzen?
Eine weitere Frage bleibt selbst dann offen, wenn die Funktion technisch überzeugt: Was haben wir da eigentlich übernommen? Eine neue Bibliothek bringt Lizenzbedingungen mit. Eine generierte Codepassage kann mit bestehendem öffentlichem Code übereinstimmen. Wenn wir diese Bestandteile nicht kennen, fehlt uns auch die Grundlage, ihren Einsatz zu beurteilen.
AI-generierter Code ist nicht automatisch frei von Rechten Dritter. Umgekehrt bedeutet eine Ähnlichkeit nicht automatisch eine Rechtsverletzung. Es kommt auf die konkrete Passage, mögliche Schutzrechte und die anwendbaren Bedingungen an. Bei eingebundenen Libraries müssen wir beispielsweise wissen, welche Hinweise erhalten bleiben müssen und welche Pflichten für unsere Nutzung entstehen.
Dass dies eine praktische Frage ist, zeigt etwa GitHubs Funktion für Code-Referenzen: Sie kann auf Übereinstimmungen mit öffentlichen Repositories und vorhandene Lizenzinformationen hinweisen. Solche Werkzeuge helfen beim Prüfen. Ein ausbleibender Hinweis belegt aber nicht, dass jede Herkunfts- und Lizenzfrage geklärt ist. Dafür braucht es eine eigene Prüfung; bei offenen Rechtsfragen auch juristische Unterstützung.
Das Modell steht im Streitfall nicht an unserer Stelle vor Gericht. Verantwortung und mögliche Haftung betreffen Menschen und Unternehmen; wer konkret einstehen muss, hängt vom Fall ab. Für unsere Arbeit bleibt die Konsequenz eindeutig: Wir müssen erklären können, was wir einsetzen. Der Verweis auf AI ersetzt das nicht. Die grundsätzlichen Fragen zu Urheberschaft und Nutzungsrechten haben wir im Insight über die Rechte an AI-generiertem Design ausführlicher eingeordnet.
Geschwindigkeit braucht eine ehrliche Rechnung
Wir haben Lust auf diese Möglichkeiten. In unserem Beitrag über die Arbeit mit AI beschreiben wir, wie viel sie bei Ideen, frühen Tests und anderen Perspektiven beitragen kann. Umso wichtiger ist uns, dass der Umgang damit auf Dauer funktioniert.
Dazu gehört, beim eigentlichen Ziel zu bleiben, parallel laufende Aufgaben zu begrenzen und die Prüfung fest einzuplanen. Ein Team muss auch sagen können: Das reicht für diese Frage. Die nächste Variante oder Zusatzfunktion kann warten. Gewonnene Zeit darf in bessere Ausarbeitung und konzentriertes Arbeiten fliessen, ohne sofort eine höhere Auslastung zu rechtfertigen.
Wer zehnmal mehr Output erwartet, muss erklären, wer ihn versteht und prüft. Diese Frage gehört auch an diejenigen, die Projekte planen und Teams führen. Verantwortung beim Menschen zu belassen und ihm gleichzeitig die Zeit dafür wegzurechnen, passt nicht zusammen.
Am Ende möchten wir eine Lösung übergeben, die wir erklären, weiterentwickeln und vertreten können. Wie schnell der erste Entwurf da war, ist dann nur ein Teil ihrer Geschichte.
