Agentic Engineering, Folie für Folie · Artikel 1 · 2026
Coding ist gelöst. Der Betrieb nicht.
In vielen Unternehmen entstehen heute Software-Prototypen in einem Nachmittag. Ein Fachbereich beschreibt, was er braucht, ein KI-Werkzeug baut es, und am Abend läuft etwas, das fachlich überzeugt. Das ist der leichte Teil geworden. Der schwere Teil beginnt danach, und er hat zwei Gesichter: eine Rechnung, die niemand gesehen hat, und eine Liste von Fragen, die niemand beantworten kann. Beide haben dieselbe Ursache.
Wie Prototypen heute entstehen
Vor zwei Jahren brauchte ein Prototyp ein Entwicklerteam, ein Pflichtenheft und einige Wochen. Heute reicht ein Werkzeug, das aus einer Beschreibung in Alltagssprache Programmcode erzeugt. Andrej Karpathy, Mitgründer von OpenAI und früher Leiter der KI-Entwicklung bei Tesla, hat dafür im Februar 2025 den Begriff Vibe Coding geprägt: Man beschreibt, was man will, nimmt an, was die KI vorschlägt, und sieht sich den Code gar nicht mehr an. Karpathy meinte das ausdrücklich als Spielerei für Wegwerf-Projekte am Wochenende. Martin Fowler, einer der bekanntesten Autoren zu Softwareentwicklung, hält in seiner Definition fest, dass so entstandene Software meist Probleme bei Wartbarkeit, Korrektheit und Sicherheit zeigt und sich deshalb für Wegwerf-Software eignet.
Geblieben ist die Idee nicht bei Spielereien. Drei Beobachtungen aus dem Jahr 2026:
Die Werkzeuge sind Alltag. In der Stack-Overflow-Entwicklerumfrage 2026, der größten jährlichen Befragung von Softwareentwicklern mit rund 30.000 Antworten, geben 73 Prozent der Befragten an, Coding-Assistenten oder Coding-Agenten täglich zu nutzen. Knapp ein Drittel der täglichen Nutzer arbeitet mehr als vier Stunden am Tag damit. Claude Code (66 Prozent) und GitHub Copilot (59 Prozent) führen die Liste der Coding-Agenten an.
Ganze Produkte entstehen so. Y Combinator, der bekannteste Startup-Förderer der Welt, meldete im März 2025, dass ein Viertel der Startups des laufenden Jahrgangs Codebasen hat, die zu 95 Prozent von KI geschrieben sind. Lovable, ein Werkzeug, mit dem Nicht-Programmierer Anwendungen per Beschreibung bauen, kam im Februar 2026 auf 400 Millionen Dollar Jahresumsatz, acht Monate zuvor waren es 100 Millionen.
Auch im Mittelstand. Die Fälle, die wir in Gesprächen hören, folgen einem Muster: Ein Fachbereich hat eine Preisliste, eine Lieferantenübersicht oder einen Freigabeprozess, der seit Jahren in Tabellen lebt. Jemand baut an einem Nachmittag eine Anwendung dafür. Sie funktioniert, die Kollegen sind begeistert, und die Anwendung läuft auf dem Rechner, auf dem sie entstanden ist.
Dass die Beschleunigung real ist, bestreitet niemand mehr. Wie groß sie ist, hängt davon ab, wer misst. Die Forschungsgruppe METR hat im Juli 2025 ein kontrolliertes Experiment veröffentlicht: Sechzehn erfahrene Entwickler bearbeiteten 246 Aufgaben in großen, gewachsenen Codebasen. Mit KI-Werkzeugen brauchten sie 19 Prozent länger, erwartet hatten sie vorher 24 Prozent Zeitgewinn, und auch hinterher glaubten sie, 20 Prozent schneller gewesen zu sein. Das Ergebnis gilt für gewachsene Systeme mit vielen Abhängigkeiten, nicht für den Prototyp auf der grünen Wiese. Genau das ist der Punkt: Der Prototyp ist schnell, weil er nichts berücksichtigen muss. Alles, was später zählt, ist noch nicht da.
Was ein Prototyp beweist, und was nicht
Ein Prototyp beantwortet eine einzige Frage: Geht das? Für diese Frage ist er ein hervorragendes Werkzeug. Ein Fachbereich kann in Stunden ausprobieren, wofür früher ein Projektantrag nötig war. Was ein Prototyp nicht beantwortet, sind die Fragen, die der Betrieb stellt: Läuft es richtig, auch in den Fällen, an die niemand gedacht hat? Läuft es sicher, auch wenn jemand es absichtlich falsch bedient? Läuft es dauerhaft, auch wenn die Person, die es gebaut hat, das Unternehmen verlässt?
Der Unterschied wird in Studien sichtbar, die weniger freundlich sind als die Produktdemos. Veracode, ein Anbieter für Software-Sicherheitsprüfung, hat im Juli 2025 mehr als 100 Sprachmodelle mit 80 Programmieraufgaben getestet. In 45 Prozent der Testfälle entstand Code mit einer Schwachstelle aus den zehn häufigsten Sicherheitsrisikoklassen, und zwar überall dort, wo das Modell zwischen einer sicheren und einer unsicheren Lösung wählen konnte. Auf der Ebene der Vorhaben zeigt sich dasselbe Bild: Das MIT-Projekt NANDA fand 2025 in einer Auswertung von 300 öffentlichen KI-Einführungen, dass rund 95 Prozent der Pilotprojekte keinen messbaren Effekt auf Gewinn oder Kosten erreichen. Gartner hatte schon 2024 vorhergesagt, dass mindestens 30 Prozent der generativen KI-Projekte nach der Machbarkeitsphase abgebrochen werden.
Die Zahlen sagen nicht, dass die Werkzeuge schlecht sind. Sie sagen, dass zwischen „es geht“ und „es läuft“ Arbeit liegt, die kein Werkzeug übernimmt, weil niemand sie beschrieben hat.
Die Token-Rechnung: die Flatrate verdeckt den Preis
Das erste der beiden Gesichter ist eine Rechnung. Wer heute intensiv mit KI entwickelt, zahlt in der Regel eine Flatrate: 20, 100 oder 200 Dollar im Monat für einen Arbeitsplatz. Abgerechnet wird dahinter aber in Tokens, den Textbausteinen, die ein Sprachmodell liest und schreibt. Jede Frage, jeder Entwurf, jede Korrekturrunde kostet Tokens. Die Flatrate deckelt den Preis für den Einzelnen, und sie verdeckt, was dieselbe Arbeit zum Listenpreis kostet.
Das lässt sich messen, weil Entwickler ihre Nutzungsprotokolle veröffentlichen. Ein Entwickler hat seine Sitzungen von Juni 2025 bis Februar 2026 ausgewertet: rund zehn Milliarden Tokens, zu 95 Prozent mit dem teuersten Modell, Gegenwert zum Listenpreis über 15.000 Dollar, bezahlt über das Abo rund 800 Dollar. Das ist ein Faktor von rund 19. In seinem Spitzenmonat, Juli 2025, waren es 2,4 Milliarden Tokens, 5.623 Dollar Gegenwert gegen 100 Dollar Abo. Ein zweiter Entwickler kommt in normalen Monaten auf 900 bis 1.400 Dollar Gegenwert bei 100 Dollar Abo, also Faktor 6 bis 9. In beiden Rechnungen sind die Rabatte für wiederverwendeten Kontext bereits enthalten, die Zahlen sind also nicht zu Ungunsten der Anbieter geschönt.
Warum ist das für ein Unternehmen wichtig, wenn der Einzelne doch nur 200 Dollar zahlt? Aus drei Gründen.
Erstens ist die Flatrate für Einzelpersonen gedacht, und die Anbieter sorgen dafür, dass das so bleibt. Anthropic hat im Juli 2025 zusätzlich zum bestehenden Fünf-Stunden-Fenster Wochenlimits eingeführt, gültig seit dem 28. August 2025, mit der ausdrücklichen Begründung, dass einzelne Nutzer das Werkzeug nahezu durchgehend laufen ließen. Was über das Limit hinausgeht, wird zum Listenpreis abgerechnet. Cursor, das meistgenutzte KI-Programmierwerkzeug im Editor, hat im Juni 2025 seinen Tarif von 500 Anfragen auf ein Guthaben von 20 Dollar umgestellt, verbraucht zu Listenpreisen. Nutzer berichteten, dass es nach wenigen Anfragen aufgebraucht war, und der Geschäftsführer entschuldigte sich im Juli öffentlich für die Umstellung. Beide Vorgänge sagen dasselbe: Die Flatrate ist ein Einstiegspreis, kein Plan für ein Team, das jeden Tag baut.
Zweitens entsteht die Rechnung genau dort, wo der Prototyp seine Stärke hat. Ohne Vorgabe muss ein großes Modell raten, was gemeint war. Jede Runde Raten, Korrigieren und Nachbessern kostet Tokens des teuersten Modells. Ein Prototyp, der „fast richtig“ ist und in zwanzig Runden richtig wird, hat zwanzigmal die Rechnung erzeugt. Das fällt im Abo nicht auf. Es fällt auf, wenn zehn Leute so arbeiten und die Rechnung zum Listenpreis kommt.
Drittens zeigt die Preisliste den Ausweg. Zwischen dem größten Modell und dem kleinsten liegt beim selben Anbieter der Faktor 100 je Token. Das kleine Modell ist nicht dümmer in dem Sinn, dass es weniger kann, wenn die Aufgabe klar ist. Es ist schlechter im Raten. Wer die Vorgabe so schreibt, dass nichts mehr geraten werden muss, kann mit dem kleinen Modell arbeiten, oder mit einem Modell im eigenen Haus, das gar keine Tokenrechnung hat. Das ist der wirtschaftliche Kern der nächsten Artikel dieser Serie.
Eine Einschränkung, die wir bewusst machen: Ob auch der Listenpreis unter den tatsächlichen Kosten der Anbieter liegt, wissen wir nicht. Messbar ist der Abstand zwischen Flatrate und Listenpreis. Deshalb schreiben wir nicht von Subvention, sondern davon, dass die Flatrate den Preis verdeckt.
Acht Fragen, die ein Prototyp nicht beantwortet
Das zweite Gesicht ist eine Liste. Sie kommt in dem Moment, in dem ein Fachbereich den Prototyp dem Unternehmen anvertrauen will und die IT ihn ansieht. Die Fragen sind keine Schikane, es sind die Fragen, die für jede Anwendung im Unternehmen beantwortet sind, vom E-Mail-System bis zur Buchhaltung. Ein Prototyp hat auf keine davon eine Antwort, weil er nicht dafür gebaut wurde.
Was hinter den Fragen steckt, in der Sprache des Fachbereichs:
In welcher Netzzone läuft es? Unternehmen trennen ihre Netze: ein Bereich, der von außen erreichbar ist, ein internes Netz, manchmal ein abgeschotteter Bereich ohne jede Verbindung. Der Prototyp läuft auf einem Laptop. Niemand hat entschieden, wo er hingehört und wie er dorthin kommt.
Wer darf sich anmelden, und wozu? Im Unternehmen meldet man sich einmal an, und jedes System weiß, wer man ist und was man darf. Der Prototyp hat entweder gar keine Anmeldung oder eine eigene, die niemand pflegt. Wer die Firma verlässt, bleibt im Prototyp angemeldet.
Wer hat abgenommen, und wogegen? Für jede Anwendung im Betrieb gibt es jemanden, der gesagt hat: Das ist richtig so. Beim Prototyp gibt es die Begeisterung des Fachbereichs. Es gibt keine Beschreibung, gegen die jemand prüfen könnte, ob das Ergebnis stimmt, und deshalb auch keine Abnahme.
Was passiert, wenn es nachts ausfällt? Betriebssysteme werden überwacht, und jemand wird geweckt, wenn etwas stehen bleibt. Der Prototyp fällt aus, und am Morgen merkt es der Fachbereich.
Wo sind die Daten von gestern? Jede Anwendung im Betrieb wird gesichert, und man kann einen Stand von gestern wiederherstellen. Beim Prototyp liegen die Daten in einer Datei auf dem Laptop.
Wie kommt Version 2 hinein? Anwendungen ändern sich. Im Betrieb gibt es einen Weg, eine neue Version einzuspielen, ohne dass Daten verloren gehen und ohne dass die Nutzer mitten in der Arbeit unterbrochen werden. Beim Prototyp heißt Version 2: noch einmal bauen.
Wer ändert es in zwei Jahren? Die Person, die den Prototyp gebaut hat, wechselt die Abteilung. Es gibt keine Dokumentation, keine Beschreibung, was die Anwendung tun soll, und keine Tests, die zeigen, ob sie es nach einer Änderung noch tut.
Hat es jemand gehärtet? Härtung heißt, dass eine Anwendung gegen absichtlichen Missbrauch geprüft wurde: fremde Eingaben, falsche Rechte, unerwartete Daten. Veracodes Zahl von 45 Prozent unsicherer Lösungen in Testfällen beschreibt genau den Zustand eines Prototyps, den niemand geprüft hat.
Jede dieser Fragen ist beantwortbar. Für jede einzelne braucht es Arbeit, Entscheidungen und einen Ort, an dem die Antwort dauerhaft gilt. Das ist der Grund, warum Prototypen in Unternehmen seit Monaten in der Warteschleife stehen, obwohl sie fachlich fertig sind.
Die eine Ursache hinter beiden Symptomen
Die Token-Rechnung und die Fragen der IT sehen aus wie zwei Probleme. Es ist eines. In beiden Fällen fehlt dasselbe: eine Beschreibung, gegen die ein Agent arbeitet und ein Mensch abnimmt.
Die Rechnung entsteht, weil das Modell rät. Es rät, weil niemand aufgeschrieben hat, was richtig ist. Die Fragen der IT bleiben offen, weil niemand aufgeschrieben hat, was die Anwendung tun soll, wer sie nutzen darf und woran man erkennt, dass sie läuft. Ein Prototyp zeigt, dass etwas geht. Er sagt niemandem, woran man misst, ob es richtig läuft.
Daraus folgen die zwei Dinge, die den übrigen Artikeln dieser Serie ihre Struktur geben. Das erste ist ein Projekt: eine Form, in der das Zielbild, die Anforderungen und die Abnahmekriterien so stehen, dass ein Agent sie ausführen und ein Fachbereich sie ohne Entwickler lesen und abnehmen kann. Je genauer diese Beschreibung, desto weniger wird geraten, desto kleiner das Modell, desto kleiner die Rechnung. Das zweite ist eine Plattform: ein Ort, an dem die Anwendung läuft und an dem die acht Fragen der IT ein für alle Mal beantwortet sind, für jede Anwendung, die dort läuft. Die Anwendung selbst bleibt klein, die Plattform übernimmt den Rest.
Beides zusammen ist das, was der Begriff Agentic Engineering meint, wenn man ihn in einem Unternehmen anwendet. Der nächste Artikel erklärt den Begriff.
Was das für Sie heißt
Wenn in Ihrem Haus ein Prototyp in der Warteschleife steht, lohnt sich ein Blick auf zwei Dinge. Erstens: Gibt es eine Beschreibung dessen, was die Anwendung tun soll, die ein Fachbereich lesen und abnehmen könnte? Wenn nicht, ist das der erste Schritt, und er ist keine Entwicklerarbeit. Zweitens: Wo soll die Anwendung laufen, und wer beantwortet dort die acht Fragen? Wenn die Antwort „auf dem Laptop von Herrn Meier“ lautet, ist das der zweite Schritt.
Beide Schritte sind der Inhalt der nächsten Artikel. Der Prototyp selbst ist dabei kein Verlust, er ist das beste Lastenheft, das ein Fachbereich je geschrieben hat. Man muss es nur noch in eine Form bringen, in der Agenten es ausführen und Menschen es abnehmen können.
Quellen
Andrej Karpathy, Beitrag auf X zum Begriff Vibe Coding, Februar 2025; Einordnung bei Martin Fowler, Vibe Coding.
Stack Overflow, Developer Survey 2026, Abschnitt AI, veröffentlicht Oktober 2026: 73 Prozent tägliche Nutzung von Coding-Assistenten und Agenten, 31 Prozent der täglichen Nutzer über vier Stunden, Claude Code 66 Prozent, GitHub Copilot 59 Prozent.
MIT Project NANDA, The GenAI Divide: State of AI in Business 2025, Sommer 2025; Einordnung der 95-Prozent-Zahl bei Zirous.
Gartner, Pressemitteilung Juli 2024: mindestens 30 Prozent der generativen KI-Projekte werden bis Ende 2025 nach der Machbarkeitsphase abgebrochen; Zusammenfassung bei Feedbagel.
Token-Rechnung Entwickler A: ksred.com, Claude Code Pricing Guide, Sitzungsprotokolle Juni 2025 bis Februar 2026. Entwickler B: agentplix.com (aus der Herleitung vom 22.10.2026, Primärlink nachzutragen).
Steht bei Ihnen ein Prototyp in der Warteschleife?
Schreiben Sie uns, was er tut und wo er läuft. Wir sagen Ihnen in einer Antwort, welche der acht Fragen schon beantwortet sind und welche nicht.
contact@dewline.de
Agentic Engineering, slide by slide · Article 1 · 2026
Coding is solved. Operations are not.
In many companies, a software prototype now takes an afternoon. A business unit describes what it needs, an AI tool builds it, and by the evening something runs that convinces on the merits. That has become the easy part. The hard part starts afterwards, and it has two faces: a bill nobody has seen, and a list of questions nobody can answer. Both have the same cause.
How prototypes get built today
Two years ago a prototype needed a development team, a specification and a few weeks. Today a tool is enough that turns a description in plain language into program code. Andrej Karpathy, co-founder of OpenAI and formerly head of AI at Tesla, coined the term vibe coding for this in February 2025: you describe what you want, accept what the AI proposes, and stop looking at the code altogether. Karpathy meant it, explicitly, as play for throwaway weekend projects. Martin Fowler, one of the best-known authors on software development, notes in his definition that software built this way usually shows problems with maintainability, correctness and security, which makes it suitable for disposable software.
The idea did not stay with play. Three observations from 2026:
The tools are everyday equipment. In the 2026 Stack Overflow Developer Survey, the largest annual survey of software developers with around 30,000 responses, 73 percent say they use coding assistants or coding agents daily. Almost a third of daily users work with them for more than four hours a day. Claude Code (66 percent) and GitHub Copilot (59 percent) lead the list of coding agents.
Whole products are built this way. Y Combinator, the world's best-known startup accelerator, reported in March 2025 that a quarter of the startups in its current batch had codebases that were 95 percent written by AI. Lovable, a tool that lets non-programmers build applications by describing them, reached 400 million dollars in annual revenue in February 2026, up from 100 million eight months earlier.
In mid-sized companies too. The cases we hear about in conversations follow a pattern. A business unit has a price list, a supplier overview or an approval process that has lived in spreadsheets for years. Someone builds an application for it in an afternoon. It works, the colleagues are delighted, and the application runs on the computer it was built on.
Nobody disputes any more that the acceleration is real. How large it is depends on who measures. The research group METR published a controlled experiment in July 2025: sixteen experienced developers worked on 246 tasks in large, mature codebases. With AI tools they took 19 percent longer. Beforehand they had expected a 24 percent speedup, and afterwards they still believed they had been 20 percent faster. The result applies to mature systems with many dependencies, not to a prototype on a green field. That is exactly the point: the prototype is fast because it has nothing to take into account. Everything that matters later is not there yet.
What a prototype proves, and what it does not
A prototype answers a single question: can this be done? For that question it is an excellent tool. A business unit can try out in hours what used to need a project proposal. What a prototype does not answer are the questions operations ask. Does it run correctly, including the cases nobody thought of? Does it run safely, even when somebody uses it wrongly on purpose? Does it keep running when the person who built it leaves the company?
The difference shows up in studies that are less friendly than product demos. Veracode, a provider of software security testing, tested more than 100 language models with 80 programming tasks in July 2025. In 45 percent of the test cases the code contained a vulnerability from the ten most common security risk classes, wherever the model could choose between a secure and an insecure solution. At the level of initiatives the picture is the same: the MIT project NANDA found in a 2025 analysis of 300 public AI deployments that around 95 percent of pilots reach no measurable effect on profit or cost. Gartner had predicted as early as 2024 that at least 30 percent of generative AI projects would be abandoned after the proof-of-concept stage.
The numbers do not say the tools are bad. They say that between "it can be done" and "it runs" lies work that no tool takes over, because nobody has described it.
The token bill: the flat rate hides the price
The first of the two faces is a bill. Whoever develops intensively with AI today usually pays a flat rate: 20, 100 or 200 dollars a month for one seat. Behind it, however, billing runs in tokens, the text units a language model reads and writes. Every question, every draft, every round of corrections costs tokens. The flat rate caps the price for the individual, and it hides what the same work costs at list price.
This can be measured, because developers publish their usage logs. One developer analysed his sessions from June 2025 to February 2026: around ten billion tokens, 95 percent on the most expensive model, worth more than 15,000 dollars at list price, paid through the subscription around 800 dollars. That is a factor of about 19. In his peak month, July 2025, it was 2.4 billion tokens, 5,623 dollars at list price against 100 dollars of subscription. A second developer lands at 900 to 1,400 dollars of list-price value in normal months on a 100-dollar subscription, a factor of 6 to 9. Both calculations already include the discounts for reused context, so the figures are not skewed against the vendors.
Why does this matter to a company when the individual only pays 200 dollars? For three reasons.
First, the flat rate is meant for individuals, and the vendors make sure it stays that way. In July 2025 Anthropic introduced weekly limits on top of the existing five-hour window, effective 28 August 2025, with the explicit reason that some users were running the tool almost continuously. Whatever exceeds the limit is billed at list price. Cursor, the most widely used AI programming tool inside the editor, changed its plan in June 2025 from 500 requests to a credit of 20 dollars, consumed at list prices. Users reported that it was used up after a few requests, and the chief executive apologised publicly for the rollout in July. Both events say the same thing: the flat rate is an entry price, not a plan for a team that builds every day.
Second, the bill arises exactly where the prototype has its strength. Without a specification, a large model has to guess what was meant. Every round of guessing, correcting and patching costs tokens of the most expensive model. A prototype that is "almost right" and becomes right in twenty rounds has produced the bill twenty times. That goes unnoticed on a subscription. It gets noticed when ten people work this way and the bill arrives at list price.
Third, the price list shows the way out. Between the largest and the smallest model of the same vendor lies a factor of 100 per token. The small model is not dumber in the sense that it can do less when the task is clear. It is worse at guessing. Whoever writes the specification so that nothing has to be guessed any more can work with the small model, or with a model in their own house that has no token bill at all. That is the economic core of the next articles in this series.
One limitation we state deliberately: whether the list price itself lies below the vendors' actual cost, we do not know. What can be measured is the gap between flat rate and list price. That is why we do not write of subsidies, but of a flat rate that hides the price.
Eight questions a prototype does not answer
The second face is a list. It arrives the moment a business unit wants to entrust the prototype to the company and IT takes a look at it. The questions are not obstruction. They are the questions that are answered for every application in the company, from the e-mail system to accounting. A prototype has an answer to none of them, because it was not built for that.
What lies behind the questions, in the language of the business unit:
Which network zone does it run in? Companies separate their networks: an area reachable from outside, an internal network, sometimes an isolated area with no connection at all. The prototype runs on a laptop. Nobody has decided where it belongs and how it gets there.
Who may log in, and to what? In the company you log in once, and every system knows who you are and what you may do. The prototype has either no login at all or its own, which nobody maintains. Whoever leaves the company stays logged in to the prototype.
Who signed off, and against what? For every application in operation there is someone who said: this is right. For the prototype there is the enthusiasm of the business unit. There is no description against which anyone could check whether the result is correct, and therefore no sign-off either.
What happens when it fails at night? Production systems are monitored, and someone gets woken up when something stops. The prototype fails, and the business unit notices in the morning.
Where is yesterday's data? Every application in operation is backed up, and a state from yesterday can be restored. With the prototype, the data sits in a file on the laptop.
How does version 2 get in? Applications change. In operation there is a way to roll out a new version without losing data and without interrupting users in the middle of their work. For the prototype, version 2 means: build it again.
Who changes it in two years? The person who built the prototype moves to another department. There is no documentation, no description of what the application is supposed to do, and no tests that show whether it still does it after a change.
Has anyone hardened it? Hardening means that an application has been checked against deliberate misuse: foreign input, wrong permissions, unexpected data. Veracode's figure of 45 percent insecure solutions in test cases describes exactly the state of a prototype nobody has checked.
Each of these questions can be answered. Each one needs work, decisions and a place where the answer holds permanently. That is why prototypes have been sitting in the queue in companies for months, although they are functionally finished.
The one cause behind both symptoms
The token bill and the questions of IT look like two problems. It is one. In both cases the same thing is missing: a description against which an agent works and a person signs off.
The bill arises because the model guesses. It guesses because nobody wrote down what is right. The questions of IT stay open because nobody wrote down what the application is supposed to do, who may use it, and how one can tell that it runs. A prototype shows that something can be done. It tells nobody how to measure whether it runs correctly.
From this follow the two things that give the remaining articles of this series their structure. The first is a project: a form in which the target picture, the requirements and the acceptance criteria are written so that an agent can execute them and a business unit can read and sign them off without a developer. The more precise this description, the less guessing, the smaller the model, the smaller the bill. The second is a platform: a place where the application runs and where the eight questions of IT are answered once and for all, for every application that runs there. The application itself stays small, the platform takes care of the rest.
Both together is what the term Agentic Engineering means when it is applied inside a company. The next article explains the term.
What this means for you
If a prototype is sitting in the queue in your company, two things are worth a look. First: is there a description of what the application is supposed to do that a business unit could read and sign off? If not, that is the first step, and it is not developer work. Second: where is the application supposed to run, and who answers the eight questions there? If the answer is "on Mr Meier's laptop", that is the second step.
Both steps are the content of the next articles. The prototype itself is no loss. It is the best requirements document a business unit has ever written. It only has to be brought into a form in which agents can execute it and people can sign it off.
Sources
Andrej Karpathy, post on X coining the term vibe coding, February 2025; context at Martin Fowler, Vibe Coding.
Stack Overflow, Developer Survey 2026, AI section, published October 2026: 73 percent daily use of coding assistants and agents, 31 percent of daily users above four hours, Claude Code 66 percent, GitHub Copilot 59 percent.
MIT Project NANDA, The GenAI Divide: State of AI in Business 2025, summer 2025; reading of the 95 percent figure at Zirous.
Gartner, press release July 2024: at least 30 percent of generative AI projects abandoned after proof of concept by the end of 2025; summary at Feedbagel.
Token calculation, developer A: ksred.com, Claude Code Pricing Guide, session logs June 2025 to February 2026. Developer B: agentplix.com (from the derivation of 22.10.2026, primary link to be added).
