Ein Gespräch zwischen Ari Byland und Christian Hofstetter
Über den Sommer habe ich eine kleine Web-App gebaut, ohne eine Zeile Code selbst zu schreiben. Seither begleitet mich eine Frage: Ab wann ist so etwas ein Produkt und nicht nur ein Anschauungsobjekt?
Verfügbar auf Apple Podcasts und Spotify
Das Problem war klein. Wir spielen regelmässig Padel, und irgendjemand muss jedes Mal den Spielplan und die Rangliste erstellen. Diese Aufgabe hat mich genervt, also ist matchmates.ch entstanden. Geschrieben habe ich dabei praktisch keinen Code selbst.
Im Hinterkopf hatte ich dabei durchgehend die Gespräche mit Benjamin Huser-Berta, der mir bei meinen technischen Experimenten den Rückhalt gibt. Bin ich einfach jemand, der etwas zusammensetzt und im Grunde keine Ahnung hat, was er tut? Oder ist das etwas, das man produktiv schalten und tatsächlich brauchen kann?
Genau diese Frage habe ich Benjamin und Manuel Müller in der aktuellen Folge gestellt. Ihre Antwort hat die Frage verschoben, statt sie zu beantworten. Eine saubere Grenze zwischen Prototyp und Produkt gibt es nicht. Es gibt nur unterschiedliche Qualitätsansprüche für unterschiedliche Kontexte.
Die Grenze verläuft nicht zwischen Profis und Laien
Benjamin würde bei einer Anwendung im Bankenumfeld andere Standards ansetzen als bei einer öffentlich zugänglichen App ohne heikle Daten. Manuel formuliert den Massstab noch schlichter:
«Ist es brauchbar? Löst das Produkt das Problem vernünftig?»
– Manuel Müller
Im Unternehmensumfeld kommen Sicherheitsanforderungen, die Integration in bestehende Infrastruktur und der Betrieb dazu. Der Massstab bleibt derselbe, die Anforderungen werden mehr. Interessant wird es bei der Umkehrung:
«Nur weil jemand Softwareentwickler ist oder eine IT-Abteilung hat, ist nicht alles perfekt.»
– Benjamin Huser-Berta
Praktiken wie Test-driven Development oder durchgängige Pipelines gibt es seit zwanzig Jahren, etabliert sind sie längst nicht überall. Die Trennlinie verläuft also nicht zwischen den offiziellen Entwicklerinnen und Entwicklern und allen anderen. Sie verläuft entlang der Praktiken, die eine Organisation tatsächlich lebt.
Das ist eine unangenehme Erkenntnis, weil sie eine bequeme Zuständigkeitslogik aushebelt. Man kann Qualität nicht dadurch sicherstellen, dass man Software nur an einer bestimmten Stelle im Organigramm zulässt.
Was die Shadow-IT der Nullerjahre gelehrt hat
Als ich in den Nullerjahren als Softwareentwickler angefangen habe, gab es links und rechts von uns die Fachabteilungen. Finanzen und Marketing bauten ihre Excel- und Access-Anwendungen mit Visual Basic und hielten sie so lange am Leben, wie es irgendwie ging. Früher oder später kam fast immer der Punkt, an dem es zu komplex wurde. Dann kam das Ganze zu uns über den Zaun.
Vibe-Coding ist dieselbe Bewegung. Das Werkzeug ist besser geworden, die Reichweite grösser, die Einstiegshürde praktisch verschwunden. Wer Zugriff auf diese Tools hat, wird sie brauchen, unabhängig davon, ob das dem Corporate-Standard entspricht. Benjamin sieht das nüchtern: Es passiert einfach, es ist etwas unregulierter, und früher oder später muss eine Organisation entscheiden, wie sie damit umgeht.
Das Muster ist nicht neu. Neu ist nur, wie viele Menschen es jetzt anwenden können und wie schnell.
Wo beginnst du mit der Entwicklung deiner Organisation? Mach in 30 Minuten die Selbsteinschätzung, wo ihr aktuell steht.
Das daraus entstehende Profil besprechen wir in einem persönlichen Gespräch. Beides ist kostenlos und gibt dir einen ersten Eindruck, wo du am Besten startest.
Chance und Risiko liegen dicht beieinander
Der Prototyp als präzisere Anforderung
Manuel sieht darin vor allem eine Chance, und zwar an einer Stelle, die in klassischen Vorgehen chronisch schwach ist. Wenn das Business seine Idee nicht mehr nur beschreiben, sondern als klickbaren Prototyp zeigen kann, wird die Problemdefinition präziser. Aus einem Anforderungsdokument, über dessen Interpretation man drei Workshops streiten kann, wird ein Artefakt, das man anfassen kann. Von dort aus ist der Weg zu einer tragfähigen Lösung im Unternehmenssystem kürzer, nicht länger.
Das ist wirksame Partizipation in einer sehr konkreten Form. Die Fachseite bringt nicht mehr nur Wünsche ein, sondern einen ersten Entwurf.
Der Code, den niemand mehr versteht
Das Risiko liegt gleich daneben. Sobald jemand merkt, dass es auch allein geht, wird das Team umgangen, und es entsteht Wildwuchs. Manuel beschreibt die Sorge deutlicher als jede Risikoanalyse: «Wer hat das noch im Griff, wenn lauter Vibe-Code herumsteht und niemand mehr weiss, wie die Systeme eigentlich funktionieren?» Manuel Müller.
Dazu kommt seine Frage nach dem Nachwuchs. Wenn das Handwerk nicht mehr gelernt wird, fehlt später die Fähigkeit, das Entstandene zu beurteilen und zu unterhalten. Benjamin verweist auf den Punkt, an dem sich das entscheidet: Irgendjemand muss Verantwortung übernehmen, wenn etwas schiefgeht. Die Frage ist, ob jemand mit dem eigenen Namen oder dem Firmennamen dahinterstehen kann.
Manuel hat dafür ein Bild, das sein Sohn ihm geliefert hat. Der lernt Zimmermann und behaut die Balken nicht mehr aus dem rohen Baumstamm, dafür gibt es Maschinen. Das Handwerk ist damit nicht verschwunden, es hat sich verlagert.
Was du in deiner Organisation klären kannst
Der Umgang mit dieser Bewegung ist keine Technologiefrage, sondern eine Frage der Entscheidungsarchitektur. Wer verbietet, verliert die Lernbewegung und bekommt die Systeme trotzdem, nur unsichtbar. Wer nichts klärt, sammelt Anwendungen ohne Verantwortliche an.
Drei Punkte lohnen sich zum Nachdenken. Wo entsteht in deiner Organisation gerade Software ausserhalb der dafür vorgesehenen Stellen, und weisst du davon? Welche Qualitätsansprüche gelten wofür, und ist das explizit oder nur gefühlt? Und vor allem: Gibt es einen Weg, auf dem ein Prototyp aus einer Fachabteilung in eine verantwortete Umsetzung kommt, oder gibt es dort nur eine Mauer?
Die dritte Frage ist die entscheidende. Sie beschreibt eine Spannung, die sich nicht auflösen lässt, sondern gestaltet werden muss.
Solche Fragen zu klären heisst, an Rollen, Verantwortlichkeiten und Entscheidungswegen zu arbeiten, nicht an Werkzeugen. Genau dort setzt unser Angebot Entwicklung an: Strukturen und Entscheidungsprozesse so gestalten, dass sie zur Art der Wertschöpfung passen, die eine Organisation tatsächlich betreibt.
Falls dich interessiert, wie diese Entwicklungsarbeit in deinem Kontext aussehen könnte, lass uns darüber sprechen.
Mich interessiert, wo bei euch gerade Software ausserhalb der IT entsteht und wie ihr damit umgeht. Duldet ihr es, kanalisiert ihr es, oder wisst ihr schlicht nicht, was läuft?
Buchtipps
📘 Value Talks – Wirksame Muster für lernende Organisationen Ari Byland (erscheint April 2026) Das Buch, das den Anstoss für diese Episode gab. Ari widmet darin ein Kapitel dem Konzept Organisational Debt und bietet wirksame Muster für lernende Organisationen. 👉 Mehr erfahren
📘 Creating Space for Teams – A Team Coach’s Guide Christian Hofstetter Christians Playbook mit konkreten Workshop-Formaten, unter anderem zu Dynamic Facilitation und dem Aufbau von Psychological Safety in Teams. 👉 Mehr erfahren
Hinweis
📅 Bevorstehende Events von Value Talks:
- 25. September: Alle reden über Coding Agents. Du baust.
- 29./30. Oktober: Professional Scrum Master Advanced (garantiert)
Mehr Veranstaltungen und Trainings: events.valuetalks.ch
Lass uns sprechen
Wenn du klären willst, ob Sparring, Facilitation oder langfristige Begleitung zu deiner Situation passt – lass uns darüber sprechen.
Kostenlos & unverbindlich – kein Verkaufsgespräch.
Was dich erwartet: Kurzes Kennenlernen, konkrete erste Schritte für deine Organisation.