Bei Anthropic, dem Unternehmen hinter dem KI-Assistenten Claude, hat ein Manager eine Einschätzung formuliert, die in der Branche für Diskussion sorgt: Das klassische Coding-Interview sei tot. Die Begründung von Felix Rieseberg ist unbequem schlicht. Kleine, abgegrenzte Programmieraufgaben löse das eigene Modell inzwischen besser als die meisten Bewerberinnen und Bewerber. Wer genau diese Fähigkeit im Bewerbungsgespräch abfragt, misst also etwas, das ohnehin automatisiert ist.

An die Stelle der Whiteboard-Aufgabe sollen nach dieser Lesart Prototypen treten: tatsächlich gebaute, lauffähige Dinge, an denen sich ablesen lässt, wie jemand denkt. Rieseberg nennt als Kriterien Geschmack, Empathie und prinzipiengeleitetes Denken – also die Fähigkeit, gute Entscheidungen zu treffen, Nutzerperspektiven einzunehmen und nach nachvollziehbaren Grundsätzen zu arbeiten. Dazu kommt die Formel "Hunger beats tenure": Eigenantrieb zählt mehr als Dienstjahre.

Eine Verschiebung, kein Freifahrtschein

Für Einsteiger klingt das zunächst nach Ermächtigung. Wer ohne lange Berufsbiografie etwas Überzeugendes baut, kann sich qualifizieren. Zugleich verschiebt sich die Messlatte aber deutlich: Statt einer klar umrissenen technischen Prüfung wird unternehmerisches Denken erwartet. Diese Anforderung ist schwerer zu greifen, schlechter zu trainieren und setzt eine Art Dauerengagement voraus, das nicht jede Lebenssituation hergibt.

Es lohnt sich, diese Einordnung nüchtern zu lesen. Die Aussage stammt aus einem Unternehmen, das KI-Assistenten herstellt – ein gewisses Eigeninteresse an der These, dass Modelle das Programmieren übernehmen, liegt nahe. Dass abgegrenzte Aufgaben heute zuverlässig von Assistenzsystemen erledigt werden, ist in der Praxis trotzdem gut beobachtbar.

Was in Projekten tatsächlich knapp ist

Der eigentlich interessante Punkt für Auftraggeber liegt woanders. Wenn das Schreiben einzelner Funktionen günstiger und schneller wird, verlagert sich der Engpass in Softwareprojekten nach oben – auf die Ebenen, die eine KI nicht aus sich heraus klärt:

  • Architektur: Wie werden Systeme geschnitten, damit sie in drei Jahren noch wartbar sind? Welche Abhängigkeiten geht man bewusst ein, welche nicht?
  • Anforderungsklärung: Was soll die Software eigentlich leisten – und was davon ist nur ein Wunsch aus einem einzelnen Meeting?
  • Qualitätssicherung: Generierter Code sieht häufig plausibel aus. Ob er korrekt, sicher und performant ist, zeigt sich erst durch Tests, Reviews und Betrieb.
  • Verantwortung: Wer haftet dafür, dass eine Lösung Datenschutzanforderungen erfüllt und auch unter Last funktioniert?

Diese Aufgaben waren immer schon anspruchsvoll. Neu ist, dass sie den überwiegenden Teil der Wertschöpfung ausmachen, wenn die Implementierung selbst an Gewicht verliert.

Prototypen als Kommunikationsmittel

Dass Prototypen im Bewerbungsprozess an Bedeutung gewinnen, hat eine Entsprechung in der Projektarbeit. Ein lauffähiger Entwurf beantwortet Fragen, über die man in Konzeptpapieren wochenlang diskutieren kann. Wie fühlt sich die Bedienung an? Trägt der gewählte Ansatz für den realen Datenbestand? Verstehen Fachabteilungen den Ablauf ohne Erklärung?

Mit KI-Unterstützung sind solche Entwürfe schneller verfügbar als früher. Das verändert die Projektlogik: Statt lange zu spezifizieren und dann einmal zu bauen, lässt sich früher etwas zeigen und auf Basis realer Rückmeldungen korrigieren. Wichtig bleibt die Trennung zwischen Prototyp und Produkt. Ein Entwurf darf Abkürzungen nehmen; ein System im Produktivbetrieb darf das nicht.

Konsequenzen für die Zusammenarbeit mit Dienstleistern

Wer Webprojekte vergibt, sollte die Bewertungsmaßstäbe entsprechend anpassen. Die Frage "Wie viele Entwicklerstunden stecken darin?" wird als Qualitätsindikator schwächer. Aussagekräftiger sind andere Punkte:

  1. Wie begründet ein Anbieter seine Architekturentscheidungen – und benennt er auch deren Nachteile?
  2. Welche Qualitätssicherung ist eingeplant: automatisierte Tests, Code-Reviews, Sicherheitsprüfungen?
  3. Wie wird mit KI-Assistenten gearbeitet, und wer prüft deren Ergebnisse?
  4. Was passiert nach dem Launch? Wartung, Updates und Weiterentwicklung sind der längere Teil des Lebenszyklus.
  5. Lässt sich der entstandene Code später von anderen übernehmen, oder entsteht eine Abhängigkeit?

Ein Hinweis zur Vorsicht: Schnelligkeit allein ist kein Qualitätsmerkmal. Eine Anwendung, die in wenigen Tagen steht, kann dennoch über Jahre teuer werden, wenn Datenmodell und Schnittstellen nicht durchdacht sind. Gerade bei Systemen wie TYPO3, die über lange Zeiträume betrieben und erweitert werden, zahlt sich konzeptionelle Sorgfalt stärker aus als Tempo in der ersten Woche.

Was das für Teams heißt

Für Entwicklerteams folgt daraus weniger eine Bedrohung als eine Verschiebung des Schwerpunkts. Gefragt sind Menschen, die Vorschläge eines Assistenten beurteilen können, statt sie nur zu übernehmen – und die verstehen, welches Geschäftsproblem hinter einer Anforderung steht. Das setzt Erfahrung voraus, die sich nicht allein durch schnelles Prototyping ersetzen lässt. Beides gehört zusammen: die Bereitschaft, Dinge auszuprobieren, und die Urteilsfähigkeit, das Ergebnis einzuschätzen.

Offen bleibt dabei, wie Nachwuchskräfte diese Urteilsfähigkeit künftig aufbauen, wenn die klassischen Einstiegsaufgaben zunehmend von Modellen erledigt werden. Eine überzeugende Antwort darauf hat die Branche derzeit nicht.

Für Web- und Softwareprojekte heißt das konkret: Der Wert einer Agentur liegt immer weniger im reinen Schreiben von Code und immer mehr in Architektur, Qualitätssicherung und dem gezielten Einsatz von KI-Assistenten. Wer Angebote vergleicht, sollte daher nach Entscheidungslogik, Testabdeckung und Wartbarkeit fragen statt nach Aufwandspositionen allein. Und wer intern Teams aufbaut, sollte Raum für Prototypen schaffen – aber ebenso für die erfahrenen Blicke, die aus einem Prototyp ein belastbares System machen.

Quellen