Die besten AI-Tools werden Menschen bauen, die nicht programmieren können

Corinna hat mir ihr Dashboard beiläufig gezeigt, als es schon fertig war. Sales-Zahlen, punktgenau ausgewertet, gebaut aus den Excel-Listen, mit denen wir ohnehin arbeiten. Corinna verantwortet bei Philipp Maderthaner die Kundenbeziehungen und unsere Produkte. Sie hat keine technische Ausbildung und noch nie eine Zeile Code geschrieben. Gebraucht hat sie ein paar Stunden.

Mein erster Gedanke: Wow. Nicht wegen des Dashboards - so etwas hätte jeder Entwickler bauen können. Sondern weil sie keinen davon gebraucht hat. Sie hatte eine klare Vorstellung und konnte sie direkt selbst umsetzen. Kein Briefing, kein Warten, bis die Entwicklung Zeit hat.

Und das passiert nicht nur bei uns. Im Februar hat Anthropic einen Hackathon veranstaltet, einen einwöchigen Programmier-Wettbewerb: 13.000 Bewerber, 500 durften eine Woche lang mit Claude Code etwas bauen. Den dritten Platz holte ein Kardiologe aus Brüssel, der noch nie programmiert hatte. Er baute sein Tool in sieben Tagen, zwischen seinen Schichten im Krankenhaus. Der erste Platz ging an einen Anwalt, der ein Tool für Baugenehmigungen in Kalifornien baute - weil er jahrelang selbst in diesem Prozess ertrunken war. Von den fünf Gewinnern war genau einer Software-Engineer.

→ Die Gewinner des Anthropic-Hackathons im Überblick - Thread von @0xkyle__ auf X

Meine These: Die produktivsten AI-Nutzer sind nicht die, die verstehen, wie es funktioniert. Es sind die, die genau wissen, was sie wollen. Und altes Expertenwissen ist dabei öfter Bremse als Vorteil.

Das WIE ist egal, solange das WAS stimmt

Warum gehen Entwickler mit AI vorsichtiger um als Corinna oder Philipp? Es liegt an ihrer Prägung: Wer programmieren gelernt hat, hat gelernt, dass er das gesamte System verstehen muss. Jede Zeile Code, die du nicht verstehst, fällt dir irgendwann auf den Kopf - so wurde es uns beigebracht, und meistens stimmte es auch.

Corinna und Philipp haben diese Prägung nicht. Ihnen ist egal, WIE etwas funktioniert, solange das WAS stimmt - das Resultat. Corinna prüft ihr Dashboard nicht auf saubere Architektur. Sie prüft, ob die Zahlen stimmen. Genau das macht sie schneller.

Ich sehe dasselbe Muster in meinem Bekanntenkreis. Ich bin gelernter Programmierer, und der Großteil meiner Programmierer-Freunde lehnt AI ab. Ob aus Angst oder aus Unwillen zur Veränderung, weiß ich nicht. Ich muss dabei an Steve Ballmer denken, der 2007 in einem Interview lauthals über das iPhone gelacht hat: das teuerste Telefon der Welt, keine Tastatur, für Geschäftskunden uninteressant. „There's no chance that the iPhone is going to get any significant market share. No chance." Ballmer war der beste Experte für das alte Spiel. Vielleicht hat er genau deshalb das neue nicht erkannt.

Der Entwickler baut nicht mehr - er räumt Hürden weg

Philipp hat sich seine Website selbst gebaut. An einem Wochenende, mit Claude Cowork - dem Desktop-Modus von Claude, in dem man in normaler Sprache beschreibt, was man will, und Claude arbeitet direkt mit den eigenen Dateien. Kein Pflichtenheft, keine Agentur.

Erst fürs Live-Stellen der Website brauchte es mich als Entwickler. Und ehrlich: eher, weil ich gerade verfügbar war, als weil es ohne mich nicht gegangen wäre. Interessant ist, was danach passierte. Statt diesen Handgriff beim nächsten Mal wieder selbst zu machen, habe ich einen Skill gebaut - eine gespeicherte Anleitung, die Claude beibringt, genau diesen Schritt künftig selbst zu erledigen. Beim nächsten Mal braucht es mich auch dafür nicht mehr.

Das ist, glaube ich, die neue Rolle von uns Entwicklern: Wir bauen nicht mehr jede Anwendung selbst. Wir räumen die Hürden weg, damit die Leute mit dem Domänenwissen selbst bauen können.

Wo die Grenze verläuft - Stand heute

Damit das nicht wie ein Werbeprospekt klingt: Es gibt eine Grenze, und wir sind gerade selbst dagegen gelaufen.

Wir bauen intern ein CRM, ein System für alle unsere Kundenbeziehungen. Philipp hat mit seinem Domänenwissen in kurzer Zeit einen Prototypen gebaut, der zeigt, wie das Produkt aussehen soll. Stark. Aber beim Ausprogrammieren, mit allen Sonderfällen und Ausnahmen, wurde es für ihn und Claude zu kompliziert. Die AI nimmt Anweisungen dann oft zu wörtlich: Sie baut genau das, was du sagst - auch dann, wenn du einen Sonderfall vergessen hast, den ein erfahrener Entwickler automatisch mitgedacht hätte.

Für ein System, das dauerhaft laufen und wachsen soll, braucht es jemanden, der die Architektur und das Datenmodell strukturiert - also festlegt, wie die Daten zusammenhängen, damit auch die Spezialfälle abgedeckt sind. Ein Prototyp ist noch kein Produkt.

Aber die Reihenfolge hat sich umgedreht. Früher stand der Entwickler am Anfang jeder Idee - ohne ihn ging nichts los. Heute steht er am Ende, wenn aus dem Prototypen ein Produkt werden soll.

Eine zweite Grenze ist rechtlicher Natur, und sie überrascht die meisten: Wer sich selbst etwas baut und es dann einsetzt, ist im Sinne des AI Act Anbieter und Betreiber in einer Person. Was daraus praktisch folgt, wenn dein Prototyp irgendwann mit Menschen redet, habe ich hier aufgeschrieben - es ist deutlich weniger, als es klingt.

Der Raum voller Experten

Ein Kardiologe hat den dritten Platz bei einem Programmier-Wettbewerb geholt. In sieben Tagen, neben seinen Krankenhaus-Schichten. Wenn du also das nächste Mal denkst „dafür müsste ich erst jemanden finden, der mir das umsetzt" - halt den Gedanken kurz an und dreh ihn um.

Stell dir vor, du gehst in einen Raum voller Experten. Entwickler, Designer, Analysten. Alle sitzen da, sehen dich an und warten auf eine einzige Sache: dass du ihnen sagst, was sie für dich bauen sollen. Was würdest du sagen?

In genau diesem Raum stehst du, jedes Mal, wenn du Claude öffnest. Die Experten sind schon da. Offen ist nur noch eine Frage: Weißt du, was du willst?

Wenn dir etwas einfällt - und dir fällt etwas ein - fang mit dem kleinsten Ärgernis an. Nimm die Excel-Liste, die dich jede Woche nervt, und gib deinem Agent diesen Auftrag: