Tag 12: Prototyp ist kein Vorprodukt: PoC, MVP und Vibe Coding

Marc

Schau dir das mal an, Stefan. Das war diesen Montag um acht Uhr morgens. Ein Projektleiter kommt zu mir ans Pult, strahlt über beide Ohren und zeigt mir auf seinem Laptop ein richtig glänzendes Frontend. Chatbot, Dashboard, tolle Animationen, sogar ein blau schimmernder Button für den Login.

Stefan

Das, um, klingt doch fürs Erste gar nicht mal so übel? Was war das Problem?

Marc

Er stellt sich hin und sagt wörtlich, Marc, wir sind zu neunzig Prozent fertig. Ich musste nur kurz zwei Zeilen tiefer in den Quellcode schauen. Die Datenbank-Schlüssel standen im Klartext im Browser-Code. Der Button hat gar nichts verarbeitet, sondern einfach nur ein fest verdrahtetes JSON zurückgegeben. Und als ich ihn gefragt habe, was genau da im Hintergrund passiert, hat er mich angeschaut wie ein Bus. Er hatte keine Ahnung. Code ungelesen übernommen.

Stefan

Ah, die klassische Montag-Morgen-Falle. Schön polierte Fassade, aber dahinter brennt die Hütte. Aber hey, genau da sind wir doch mitten im Thema von Tag twelve. Genau das verwechseln nämlich unheimlich viele Fachkräfte da draussen.

Marc

Genau darum geht es. Und diesen einen Satz, den müssen wir heute wirklich wie ein Mantra wiederholen: Ein Prototyp ist ein Erkenntnisinstrument, kein Vorprodukt. Sein Wert bemisst sich überhaupt nicht daran, wie viel er kann oder wie schön er aussieht, sondern einzig und allein daran, wie viel er klärt.

Stefan

Ein Erkenntnisinstrument. Wenn man das historisch betrachtet, ist das ja eigentlich nicht mal ein neuer Gedanke. Barry Boehm hat das schon 1988 in seinem Spiralmodell aufgeschrieben. Prototyping wurde dort explizit als Werkzeug zur Risikosteuerung eingeführt. Nicht um Software zu produzieren, sondern um die eine Stelle mit der höchsten Unsicherheit zu testen. Die sogenannte Sollbruchstelle.

Marc

Ja! Der Satz hinter der Sollbruchstelle lautet ja immer: Dieser Ansatz fällt um, wenn... Und der Prototyp ist schlicht der Versuch, genau diesen Satz umzustossen oder zu bestätigen. Wenn du diese Unsicherheit geklärt hast, gehört der Code unter Umständen direkt in den Papierkorb. Boehm nennt das ganz bewusst den Wegwerf Prototyp. Das ist kein Verlust von Arbeitszeit, das ist saubere Risikominimierung.

Stefan

Wobei man da mit den Begriffen extrem aufpassen muss, oder? In den Firmen werfen die Leute PoC, Prototyp, MVP und Pilot ständig in denselben Topf. Wie grenzt du das am Tag twelve im AIBS ab?

Marc

Ganz sauber über vier Fragen. Erstens, der Proof of Concept, der PoC. Frage: Geht das technisch überhaupt? Das ist ein reines internes Instrument, das darf extrem hässlich sein und gehört danach oft weggeworfen. Zweitens, der Prototyp. Frage: Wie fühlt sich die Nutzung an? Das adressiert Fachleute und Nutzende, um Feedback zu holen. Drittens, das Minimum Viable Product, das MVP. Frage: Nutzen echte Kundinnen und Kunden das freiwillig und zahlen vielleicht sogar dafür? Das braucht bereits echte Pflichten bei Sicherheit und Datenschutz. Und viertens, der Pilot. Frage: Trägt die Lösung im realen Betrieb über Wochen?

Stefan

Und was entsteht jetzt konkret an Tag twelve im Launchspace?

Marc

Stufe eins! Ein Proof of Concept mit ganz leichten Anleihen bei Stufe zwei. Wer an diesem Bautag versucht, ein MVP hinzustellen, verfehlt den Tag und die Prüfungsanforderung gleichzeitig.

Stefan

Aber Marc, jetzt mal ehrlich, du kennst doch die Schweizer Führungskräfte. Wenn der CEO nach acht Stunden Bauzeit eine funktionierende Oberfläche sieht, wo eine Eingabe reinfliegt und unten eine Antwort rauskommt, dann sagt der doch sofort: Super, das schalten wir morgen für alle zweitausend Mitarbeitenden frei!

Marc

Ja, der Schweizer Klassiker. Genau deshalb braucht es die eiserne Disziplin des Kernpfads. Der Kernpfad ist die eine durchgehende Kette von der Eingabe über die Verarbeitung bis zur Ausgabe, an der sich die Machbarkeit zeigt. Beim Mustercase ISA Desk zum Beispiel: Mitgliederfrage als Text rein, Wissenssuche im Reglement, Antwortentwurf raus. Punkt. Kein Login, kein Berechtigungskonzept, keine Mehrsprachigkeit. Alles, was nicht auf diesem Pfad liegt, wird bewusst weggelassen und kommt auf die Liste offener Punkte. Wenn du das dem Chef nicht erklärst, baut er dir aus einem Wegwerf PoC eine tickende Zeitbombe im Betrieb.

Stefan

Aber jetzt müssen wir über das Werkzeug reden, Marc. Wir schreiben das Jahr 2026. Niemand sitzt mehr da und tippt acht Stunden lang händisch Python Code für ein Backend. Seit Februar 2025, als Andrej Karpathy diesen Begriff Vibe Coding geprägt hat, hat sich das Entwickeln komplett gedreht. Du beschreibst dem AI App Builder wie Lovable, Bolt, v0 oder Replit in natürlicher Sprache, was du willst, lehnst dich zurück, genießt die Vibes und schaust zu, wie die App entsteht.

Marc

Und Gartner prognostiziert für 2026 ja auch einen Markt von vierundvierzig Komma fünf Milliarden US Dollar für Low Code und No Code. Und dass rund achtzig Prozent der Nutzenden ausserhalb der IT-Abteilungen sitzen. Citizen Development ist der Normalfall. Aber Stefan, hand aufs Herz: Was passiert bei diesem Vibe Coding im Kopf?

Stefan

Als Spielmodus für den Sprint eins am Morgen ist das phänomenal! Du kommst in zwanzig Minuten zu einem visuellen Prototyp. Aber Karpathy hat damals ausdrücklich von Wochenendprojekten gesprochen! Wenn du den generierten Code überhaupt nicht mehr liest und ihn einfach übernommst, weil er auf den ersten Blick zu funktionieren scheint, dann baut sich da eine gewaltige Lücke auf zwischen dem, was da läuft, und dem, was du verstehst.

Marc

Und die Zahlen zur tatsächlichen Produktivität sprechen eine Sprache, die viele AI-Enthusiasten gar nicht gerne hören. Nehmen wir dieMETR Studie aus dem Jahr 2025. Randomisierte kontrollierte Studie mit erfahrenen Open Source Entwickelnden an zweihundertsechsundvierzig realen Aufgaben.

Stefan

Das Ergebnis war wirklich verrückt. Die Entwickler dachten im Nachhinein, sie wären mit AI Werkzeugen etwa zwanzig Prozent schneller gewesen. Aber nachgemessen hat die Aufgabenbearbeitung tatsächlich neunzehn Prozent länger gedauert!

Marc

Eine Differenz von fast vierzig Prozentpunkten zwischen Gefühl und Messung! Und der Stack Overflow Developer Survey 2025 zeigt genau dieselbe Kluft: Vierundachtzig Prozent nutzen KI Werkzeuge, aber sechsundvierzig Prozent misstrauen der Korrektheit der Ausgaben vollkommen. Nur drei Prozent geben hohes Vertrauen an. Je erfahrener die Leute sind, desto skeptischer werden sie.

Stefan

Ja, weil die technischen Schulden im Hintergrund explodieren. Die Daten von GitClear zeigen zum Beispiel, dass der Code Churn, also Zeilen, die kurz nach der Entstehung direkt wieder umgeschrieben werden müssen, von drei Komma drei Prozent vor den KI Assistenten auf sieben Komma eins Prozent gestiegen ist. Und der Open Source Bericht von Black Duck für 2026 weist in achtundsechzig Prozent der geprüften Codebasen echte Lizenzkonflikte aus! Im Vorjahr waren das erst sechsundfünfzig Prozent. Stichwort License Laundering, wenn das Modell stur Copyleft Code generiert, ohne die Lizenz mitzuliefern.

Marc

Und von der Sicherheit haben wir noch gar nicht gesprochen. Denk an den Fall Lovable im Jahr 2025. BOLA Schwachstelle, Broken Object Level Authorization, geführt als CVE zwanzigfünfundzwanzig achtundvierzig siebenfünfsieben. Über ein kostenloses Konto konnte man fremden Quellcode, Datenbank-Zugangsdaten und Kundendaten aus über einhundertsiebenzig Projekten abgreifen. Das blieb achtundvierzig Tage lang offen!

Stefan

Oder der Vorfall bei Replit, wo ein autonomer KI Agent während eines verhängten Änderungsstopps eigenmächtig eine produktive Datenbank gelöscht hat. Über zwölfhundert Führungspersonen und elfhundertneunzig Firmenprofile waren einfach weg. Für den Bautag an Tag twelve gilt deshalb: Vibe Coding ist am Morgen als Spielmodus erlaubt. Aber ab dem ersten Peer Review am Nachmittag hört der Vibe auf und das Lesen fängt an. Was du nicht erklären kannst, kannst du nicht verteidigen.

Marc

Gut, kommen wir zum Nachmittag von Tag twelve. Wie testen wir den Prototyp? Der häufigste Fehler, den ich in Unternehmen sehe: Die Teams führen sich ihre Software gegenseitig vor und bewerten das Werk am eigenen Geschmack. Marc, sieht das nicht toll aus? Ja, fantastisch. Und schwupps, sind alle Anforderungen vergessen.

Stefan

An Tag twelve gilt die Regel: Gemessen wird streng gegen das Anforderungsdokument von Tag nine! Man wählt genau drei funktionale oder nicht funktionale Anforderungen aus, die der Kernpfad berührt, und definiert vor dem Testen einen numerischen Prüfschritt. Zum Beispiel: Von fünfzig synthetischen Testfragen müssen mindestens vierzig eine korrekte Fundstelle aus den Reglementen aufweisen.

Marc

Und wie setzt man das im Raum durch? Durch das Prüfverfahren von Peer Review zwei: den stummen Bedienversuch. Das ist eine der besten Methoden überhaupt.

Stefan

Oh ja! Die Person, die den Prototyp gebaut hat, übergibt die Tastatur an eine Kollegin oder einen Kollegen aus einem ganz anderen Team. Und dann gilt für die Erbauerin oder den Erbauer zwanzig Minuten lang: absolutes Sprechverbot! Kein Wort, kein Fingerzeig, kein Ja aber da musst du dort klicken. Sie sitzt daneben und schreibt stumm mit.

Marc

Jedes Mal, wenn die testende Person zögert, den falschen Button anklickt oder verwirrt schaut, hast du keine Fehlbedienung der Person entdeckt, sondern eine fehlende Anforderung oder eine unbewusste Annahme, die nur in deinem eigenen Kopf existierte. Das ist pures Gold für die Dokumentation.

Stefan

Und was passiert bei der Auswertung? Da gibt es ja im Abnahmeraster genau drei Möglichkeiten: Erfüllt, nicht erfüllt und der berühmte dritte Ausgang: Heute nicht prüfbar.

Marc

Der dritte Ausgang ist oft das ehrlichste und stärkste Ergebnis des ganzen Tages! Viele Teilnehmende haben Panik, wenn sie heute nicht prüfbar ankreuzen müssen. Sie denken, das sei ein Versagen. In Wahrheit beweist du damit extreme fachliche Reife. Wenn du aufschreibst: Die Antwortzeit unter Last war heute nicht prüfbar, weil wir im Prototyp nur Einzelanfragen verarbeitet haben, dann zeigst du genau das kritische Denken, das ein AI Business Specialist braucht.

Stefan

Genau. Genauso wie die gefallene Annahme. Wenn du im Prototyping feststellst, dass die Anbindung an das Altsystem über die API entgegen deiner Annahme aus Tag eleven nicht funktioniert, weil die Datenstrukturen zu unsauber sind, dann ist das keine Niederlage. Es ist das wertvollste Material für Prüfungsteil eins! Wer im Fachgespräch sagen kann: Wir haben am Bautag bewiesen, dass Annahme X falsch war, und mussten deshalb auf Lösungsweg Y umschwenken, der bekommt von den Experten die volle Punktzahl.

Stefan

Wenn wir von Erkenntnis sprechen, müssen wir auch ehrlich über die Leichen im Keller sprechen, die jeder Prototyp zwangsläufig hinterlässt. Die technischen Schulden. In der Fachliteratur unterscheiden wir da ja sehr sauber drei Arten, oder Marc?

Marc

Richtig. Erste Art: Die fehlende Funktion. Das ist harmlos und gewollt. Der Export als PDF fehlt noch, steht auf der Liste offener Punkte. Zweite Art: Die fehlende Absicherung. Keine Rechteverwaltung, keine Fehlerbehandlung für Spezialfälle. Im PoC vertretbar, muss aber namentlich benannt werden. Und jetzt kommt die dritte Art, Stefan, die gefährlichste von allen.

Stefan

Die unverstandene Stelle! Codeabschnitte oder Prompts, die der AI App Builder generiert hat, die wunderbar funktionieren, aber deren innere Logik niemand im Raum erklären kann. Wenn so eine unverstandene Stelle im Kernpfad liegt, ist das eine tickende Zeitbombe. Die gehört ganz oben auf die Schuldenliste.

Marc

Und wie sieht es mit der Datensicherheit am Bautag aus? Da erleben wir ja auch immer wieder wilde Sachen im Launchspace.

Stefan

Ja, leider. Grundregel Nummer eins: Es werden niemals echte Personendaten oder echte Kundendaten in ein Dritte-Anbieter-Tool hochgeladen! Wir nutzen synthetische Testdaten, die die Statistik und Struktur der echten Daten nachbilden, aber keinen Personenbezug haben. Und Grundregel Nummer zwei: Keine API Schlüssel im Browser Code verstecken und keine Umgebungen unbeabsichtigt öffentlich stehen lassen.

Marc

Und rechtlich? Wie ist das eigentlich mit dem EU AI Act, solange wir an Tag twelve nur im Prototypen-Modus bauen?

Stefan

Da schützt uns die Forschungsausnahme! Artikel zwei Absatz acht des EU AI Act, präzisiert im Erwägungsgrund 25. Die Verordnung gilt ausdrücklich nicht für KI Systeme oder Modelle, die ausschließlich zu Forschungs-, Test- und Entwicklungszwecken entwickelt werden, bevor sie in Verkehr gebracht oder in Betrieb genommen werden. Das ist ein richtiger Safe Harbor für den Bautag.

Marc

Aber Vorsicht! Die Ausnahme gilt genau bis zu dem Moment, wo der erste echte Nutzer im Betrieb auf den Button drückt. Inverkehrbringen oder Inbetriebnahme ist die harte Grenze. Und das Datenschutzrecht oder das Urheberrecht bei Lizenzkonflikten kennen übrigens keine Forschungsausnahme. Die gelten ab der ersten Sekunde.

Stefan

Absolut. Und diese ganze Liste aus Schulden, nicht prüfbaren Anforderungen und Datenschutz-Notizen ist nicht etwa Abfall, sondern die direkte Eingabe für Tag thirteen! Am Dienstag laufen nämlich die TWRO Methodik, die FMEA Light und das Bias Audit genau an dem Objekt, das an Tag twelve entstanden ist. Nichts geht verloren.

Marc

Jetzt müssen wir zum Schluss noch mit einem ganz hartnäckigen Mythos aufräumen, der in der Kohorte immer wieder für schweißnasse Hände sorgt. Manche Teilnehmende sitzen am Samstag um vierzehn Uhr da, das Tool streikt, der Firmenlaptop ist vom IT Admin komplett gesperrt, und sie verfallen in Panik, weil sie glauben: Ohne lauffähige Software fall ich durch die eidgenössische Prüfung!

Stefan

Und genau das haben wir in den offiziellen Dokumenten von ICT Berufsbildung Schweiz akribisch nachgeprüft. Der formale Prüfungsabgleich zur Orientierungstafel A3 und zum Modul 618 zeigt ein glasklares Bild.

Marc

Glasklar! Ein lauffähiger Prototyp ist eine Kursvorgabe der Graduate School, weil er didaktisch extrem wertvoll ist. Er ist aber KEINE Prüfungsvorgabe der eidgenössischen Berufsprüfung! Modul 618 sagt wörtlich: Die Konzeption kann bis zu einem Prototypen oder einem ersten Machbarkeitsnachweis führen. Kann, nicht muss!

Stefan

Das ist so eine wichtige Entlastung für alle, die technische Hürden haben. Wer am Samstag kein Werkzeug zum Laufen bringt, wählt einfach den gleichwertigen Fünf-Punkte-Pfad ohne Software.

Marc

Ganz genau. Erstens: Eine detaillierte Lösungsbeschreibung mit Datenquellen, Schnittstellen und Rollen. Zweitens: Ein sauberer Erprobungsplan mit drei Anforderungen aus Tag nine. Drittens: Ein fundierter Technologievergleich mit Begründung der Wahl. Viertens: Das dokumentierte Feedback aus dem Peer Review. Und fünftens: Die Liste der offenen Punkte mit ihren Konsequenzen. Damit erfüllst du in Prüfungsteil eins zu hundert Prozent die Anforderungen an die Handlungskompetenz C3!

Stefan

Denn was prüft das Fachgespräch in Prüfungsteil eins eigentlich wirklich? Teil eins dauert fünfundvierzig Minuten und zählt ganze fünfzig Prozent der Gesamtnote. Geprüft werden mindestens sechs Kompetenzen aus B und C, und C3 ist dabei zwingend vorgegeben. Die Experten wollen deine gedankliche Durchdringung sehen, deine Begründung für den Lösungsweg und dein Urteilsvermögen bei den Abwägungen.

Marc

Und vor allem wollen sie sehen, dass du nicht in die ultimative Prüfungsfalle tappst! Weißt du, was die tödlichste Frage der Experten bei C3 ist?

Stefan

Lass mich raten: Was hat Ihnen der Prototyp gezeigt, was Ihre Skizze aus Tag eleven noch nicht zeigen konnte?

Marc

Exakt! Und wenn der Kandidat dann antwortet: Nun ja, die AI hat mir da diesen Code generiert, wie das genau funktioniert weiß ich auch nicht, aber in der Demo sah es super aus... Bumm! Das ist das sofortige Nichtbestehen.

Stefan

Wer dagegen sagt: Unser Prototyp hat gezeigt, dass die Wissenssuche am Kernpfad bei unstrukturierten PDFs einbrechen würde. Wir haben zwei technische Schulden identifiziert, die Antwortzeit ist heute nicht prüfbar, und wir haben daraus drei klare Auflagen für den Betrieb abgeleitet. Wer so antwortet, der hat C3 nicht nur bestanden, sondern meisterhaft verteidigt.

Marc

Genauso ist es. Ein Prototyp ist ein Erkenntnisinstrument, kein Vorprodukt. Er beantwortet nicht, wie schön deine App ist, sondern ob deine Architekturentscheidung in der Realität trägt.

Stefan

Damit sind wir durch für heute. Nächste Folge: Tag thirteen, Machbarkeitsprüfung, TWRO, FMEA Light und wie man Fehlermodi findet, bevor sie einen im Betrieb einholen. Danke fürs Zuhören und bis zum nächsten Mal!