Programmieren ist nicht billig, aber POCs sind es

Ich höre immer wieder den Satz „Programmieren ist billig“.

Ich weiß nicht, wer sich das ausgedacht hat. Wer auch immer es war, hat offensichtlich noch nie eine Rechnung von Anthropic gesehen.

Ich verstehe schon, was damit gemeint ist. Die Kosten für das Programmieren einer Codezeile sind ins Bodenlose gesunken, KI übernimmt den Großteil der Eingabe – den Rest kennst du ja. Na gut. Aber der Satz ist so provokativ, dass er niemandem hilft, vor allem nicht den Ingenieuren im Raum. „Code ist zugänglich“ kommt besser an. Weniger Prahlerei, mehr Ehrlichkeit.

Wie auch immer, hier ist der Satz, den mir mein Freund Guillaume gesagt hat und der mir endlich die Augen geöffnet hat: „Meine kleine Tochter kann programmieren. Das macht sie noch lange nicht zur Ingenieurin.“

Stimmt. Denn was billig geworden ist, ist nicht das Ingenieurwesen. Es ist nicht einmal wirklich das Programmieren. Was billig geworden ist, ist der Proof of Concept. Das provisorische, aber funktionierende Ding, das eine Idee demonstriert. Das Artefakt, für dessen Erstellung ein Produktmarketer wie ich früher einen erfahrenen Entwickler brauchte.

Der bessere Satz: POCs sind mittlerweile billig.

Ich weiß, wovon ich rede. Das ist mein Job.

Was „POCs sind billig“ eigentlich bedeutet

Vor ein paar Monaten hatte ich drei Möglichkeiten, wenn ich eine Feature-Idee demonstrieren wollte.

Ein langes, sorgfältig ausgearbeitetes Spezifikationsdokument schreiben und hoffen, dass es gelesen wird. Ein Figma-Mockup erstellen, das fertig aussieht, aber nicht angeklickt werden kann. Oder einen Entwickler um eine Stunde seiner Zeit bitten, um etwas zu entwerfen.

Jetzt habe ich eine vierte. Ich programmiere selbst eine funktionierende Version (diesen Begriff verwende ich genau einmal aus SEO-Gründen; danach heißt es „KI-gestützte Entwicklung“, was dasselbe ist, aber schicker klingt und in einer Vorstandssitzung schwerer abzutun ist).

Der Trick ist nicht, dass ich programmieren gelernt habe. Das habe ich nicht. Der Trick ist, dass das Modell die technische Last trägt und ich die produktbezogene Entscheidung treffe. Ich beschreibe die Idee so, wie ich einen leitenden Entwickler einweisen würde. Ich lese, was zurückkommt. Ich feile so lange daran herum, bis das, was vor mir liegt, mit dem übereinstimmt, was ich im Kopf habe. Zwei Stunden, vielleicht drei. Dann teile ich es.

Andrej Karpathy prägte den Begriff im Februar 2025. Im Internet gab es Meinungen darüber, ob man dabei „wirklich“ programmiert. Das Internet stellte die falsche Frage. Die richtige Frage ist, ob das Ergebnis die Diskussion voranbringt. Das tut es. Zuverlässig. Jedes Mal.

Guillaumes Tochter ist keine Ingenieurin. Aber sie könnte jetzt einen Prototyp einer Idee erstellen. Genauso wie ihr Lehrer. Genauso wie dein PMM.

Das Muster in umgekehrter Richtung

Hier kommt der Teil, den ich nicht erwartet hatte.

Meine Ingenieurfreunde leisten bei der Produktpositionierung bessere Arbeit als ich es früher bei manchen meiner Produkte getan habe.

Nicht alles. Sie werden mir meinen Job nicht wegnehmen. Aber bei bestimmten Teilen der Arbeit – den Stellen, an denen man nach dem richtigen Ansatz für ein feature sucht, nach der richtigen Art, die Sache einem Kunden zu beschreiben, oder nach dem schlagkräftigen Argument, das die Demo zum Erfolg macht – liefern meine Ingenieurfreunde überzeugende Entwürfe ab.

Das Muster ist dasselbe wie bei mir, nur gespiegelt.

Wir geben ihnen die Grundlage: ICP, Personas, Kaufgewohnheiten, Wettbewerber und die Art, wie unsere Kunden tatsächlich über das Problem sprechen. Sie speisen all das zusammen mit den Features, die sie gerade entwickelt haben, in eine KI ein – und kommen mit Positionierungsansätzen zurück, für deren Erarbeitung ich in einem Marketing-Team-Workshop eine Woche gebraucht hätte.

Die KI hat das nicht alleine geschafft. Sie brauchte den Kontext. Dieser Kontext ist der Teil, für den das Marketing tatsächlich zuständig ist. Aber die Synthese – der Moment, in dem man auf das Briefing starrt und versucht, den Satz zu finden, der alles zusammenbringt –, darin ist die KI gut, wenn man ihr die richtigen Eingaben gibt.

Die gleiche Dynamik wie bei meinen POCs. Die KI übernimmt die Hauptlast. Der Mensch trifft die Entscheidung darüber, was tatsächlich richtig ist. Unterschiedliche Rollen auf beiden Seiten des Teams.

Was das für die Arbeitsweise von Teams bedeutet

Das hier ist kein Artikel nach dem Motto „Marketing sollte programmieren lernen“. Oder „Ingenieure sollten Marketing lernen“. Diese Sichtweisen gehen am Kern vorbei.

Was tatsächlich passiert: Das kollektive Gehirn eines kleinen Teams ist viel größer geworden. KI-gestützte Entwicklung verschafft Nicht-Ingenieuren Zugang zu funktionierenden Prototypen. KI-gestützte Positionierung verschafft Nicht-Marketingfachleuten Zugang zu scharfsinnigen Ansätzen. Die Fachgebiete haben sich nicht verschoben. Der Zaun zwischen den Bereichen hat viele neue Türen bekommen.

Die Teams, die das schnell begreifen, profitieren am Ende von kürzeren Feedbackschleifen. Der PMM kommt mit einem funktionierenden Prototyp zum Roadmap-Meeting. Der Entwickler kommt mit drei Positionierungsentwürfen zum Launch-Meeting. Niemand fängt bei Null an. Die Diskussion überspringt die ersten 60 % und geht direkt zu dem Teil über, in dem das Team tatsächlich etwas entscheidet.

Die Teams, die das nicht kapieren, behandeln das weiterhin wie Einbahnstraßen. Der PMM schreibt das Briefing, der Entwickler programmiert den Code, keiner von beiden rührt die Arbeit des anderen an. Gleiche Geschwindigkeit wie vor fünf Jahren. Sogar noch schlimmer, weil alle anderen schneller vorankommen.

Der Kompromiss, den ich dir schulde

Dass POCs günstig sind, heißt nicht, dass sie risikofrei sind.

Das größte Risiko ist nicht das Programmieren. Es ist das Meeting danach. Ein funktionierender POC erzeugt die Illusion von Vollständigkeit, und die naheliegende nächste Frage lautet: „Lasst es uns ausliefern.“ Genau da geraten Teams in Schwierigkeiten. Das Programm, das ich an einem Nachmittag programmiere, ist nicht das Programm, das irgendjemand vor Kunden ausführen sollte. Gartner warnte, dass „Prompt-to-App-Ansätze, die von Citizen-Entwicklern angewendet werden, Softwarefehler bis 2028 um 2500 % erhöhen werden“. Sie haben Recht damit, was passiert, wenn niemand die Grenze zwischen POC und der Produktivumgebung zieht.

Zieh die Grenze laut und deutlich. Der POC ist das Gespräch. Das Produkt ist das, was danach von Ingenieuren mit Sorgfalt entwickelt wird. Der Positionierungsentwurf des Ingenieurs ist der Funke. Der Launch-Text ist das, was das Marketing danach mit handwerklichem Geschick erstellt. Schick keines von beiden direkt von der KI zum Kunden.

Zurück zur Rechnung von Anthropic

Ich möchte noch in einer Sache ehrlich sein. Programmieren ist nicht billig. Tokens kosten echtes Geld, und ich habe beobachtet, wie die Rechnung meines Teams jeden Monat gestiegen ist, je mehr wir uns auf diesen Workflow konzentrieren. Die Kosten haben sich einfach verlagert. Früher waren es Entwicklerstunden. Jetzt ist es Rechenleistung. Die Rechnung geht immer noch auf, und zwar bei weitem, aber wenn man so tut, als wären die Kosten verschwunden, erleben Teams am Ende vierteljährliche Überraschungen.

Guillaumes Tochter ist immer noch keine Ingenieurin. Aber sie kann jetzt einen Prototyp einer Idee erstellen. Genauso wie mein PMM-Team. Und genauso wie mein Ingenieur, der sich um die Positionierung kümmert. Die Berufsbezeichnungen ändern sich nicht. Das Werkzeugset schon.

Genau das sollten wir laut aussprechen – in den Meetings, in denen das Organigramm immer noch so tut, als säßen diese drei Jobs in drei verschiedenen Räumen.

Programmieren ist zugänglich. POCs sind günstig. Das Team ist größer als die reine Mitarbeiterzahl.

Im nächsten Beitrag werde ich genau erklären, wie ich diese Prototypen erstelle: Claude Code, Upsun und die spezifischen Fähigkeiten, Plugins und MCPs, die es einem Produktmarketer ermöglichen, an einem Nachmittag etwas zu veröffentlichen, auf das ein echter Entwickler reagieren kann.