Vor einigen Wochen habe ich mir eine kleine App gebaut. Nicht, weil ich den Job unserer Entwickler:innen übernehmen möchte oder plötzlich wieder ins Tagesgeschäft des Codens einsteigen will. Sondern aus Neugier – und aus einem ganz praktischen Anlass. Unsere Budgets wurden bisher in einem alten internen System verwaltet, das zunehmend unflexibel war. Änderungen ließen sich nur schwer abbilden, die Bedienung war sperrig, und am Ende war klar: Wir brauchen etwas Neues. Also habe ich mich gefragt: Wie weit komme ich heute selbst, wenn ich mit modernen Werkzeugen wie Cursor arbeite, die mir KI-gestützt beim Programmieren helfen?
Das Ergebnis war eine Budgetübersichts-App, die für mich erstaunlich nützlich geworden ist. Noch spannender waren aber die Erfahrungen auf dem Weg dorthin. Ich war nie selbst Entwickler, habe aber in Schule und Ausbildung mit verschiedenen Programmiersprachen gearbeitet und bringe seit vielen Jahren technisches Verständnis als Product Owner mit. Programmieren konnte ich immer nur in sehr rudimentärer Form – und genau deshalb war es spannend, nach langer Zeit wieder selbst Hand anzulegen und zu sehen, wie sich die Möglichkeiten verändert haben.
Sobald man beginnt, ein Problem in Code zu übersetzen – auch mit wenig eigenem Code – stolpert man über all die Fragen, die sonst die Entwickler:innen stellen. Plötzlich sind da diese kleinen Sonderfälle, die man vorher im Kopf gar nicht auf dem Schirm hatte. Plötzlich merkt man, dass ein Begriff wie „verbraucht“ gar nicht eindeutig ist – bedeutet das jetzt beauftragt, abgerechnet oder schon gezahlt? Und plötzlich wird einem klar, dass eine scheinbar einfache Entscheidung in Wahrheit ein halbes Dutzend Abhängigkeiten nach sich zieht.
Dieser erneute Perspektivwechsel hat mich nachhaltig beeindruckt. Ich habe in diesen Tagen besser verstanden, warum Entwickler manchmal so insistieren, wenn es um genaue Definitionen geht, und warum eine kleine Änderung oft eben nicht klein ist. Es ist ein bisschen wie auf die andere Seite des Schreibtisches zu wechseln: Man spürt den Reibungsverlust, die Detailarbeit, das Abwägen – und bekommt dadurch einen viel klareren Blick auf das, was im Alltag passiert.
Natürlich war Cursor dabei eine große Hilfe. Ich habe in diesem Projekt tatsächlich keine einzige Zeile Code selbst geschrieben, sondern ausschließlich mit Cursor „diskutiert“. Der Editor hat meine Beschreibungen in natürlicher Sprache aufgenommen, Vorschläge gemacht, Code erzeugt und angepasst. So entstand Schritt für Schritt die App – ohne dass ich selbst tippen musste. Das war spannend, weil ich mich dadurch viel stärker auf die Logik und die Anforderungen konzentrieren konnte, anstatt auf Syntax oder Details der Programmiersprache.
Es gibt aber auch Grenzen des “Bastelns”, z.B. im Bereich Authentifizierung. Für uns war von Anfang an klar, dass wir den internen Keycloak-Service nutzen. Dort gibt es keine Experimente, keine Abkürzungen, keine Bastellösungen. Authentifizierung ist ein Kernsystem, das stabil, sicher und überprüfbar sein muss. Das war für mich ein wertvoller Kontrast: Auf der einen Seite der spielerische, schnelle Umgang mit Low-Code-Ansätzen, auf der anderen Seite die Notwendigkeit klarer, fester Services. Genau in dieser Balance liegt für mich die Chance: Unternehmen können eine stabile Basis schaffen – Identität, Logging, Datenplattformen – und darauf eine flexible Schicht von Experimenten zulassen.
Und genau hier liegt für mich ein entscheidender Punkt: Damit solche Experimente überhaupt entstehen können, braucht es ein bewusstes Enablement im eigenen Unternehmen. Wer seinen Mitarbeiter:innen die Möglichkeit gibt, innerhalb klarer Leitplanken Dinge auszuprobieren, öffnet einen riesigen Raum für Kreativität und Lernprozesse. Wenn die Grundarchitektur stabil ist und die Spielwiese klar abgesteckt, entstehen plötzlich Ideen, die man in klassischen Projektsettings nie gesehen hätte. Wir unterstützen Unternehmen genau dabei: diese stabile Basis so aufzubauen, dass sie Sicherheit gibt – und gleichzeitig Freiraum lässt, Neues zu wagen.
Was bleibt nach diesem Experiment? Vor allem ein verändertes Verständnis für Rollen und Prozesse. Ich kann Anforderungen präziser formulieren, weil ich selbst gespürt habe, wo die Stolperfallen liegen. Ich habe erlebt, dass Prototypen Diskussionen konkret machen und Missverständnisse vermeiden. Und ich habe gelernt, wie viel Respekt das eigentliche Handwerk verdient: Sauberer Code, durchdachte Architektur, geduldige Detailarbeit.
Solche kleinen Apps können in ganz unterschiedlichen Bereichen nützlich sein. Sie helfen, eigene Arbeitsabläufe zu verbessern, Analysen zu vereinfachen oder in kleinem Rahmen Geschäftsprozesse zu optimieren. Aber wie bei jeder Software fängt die eigentliche Arbeit erst mit dem Einsatz an: Wie oft muss die App Sicherheitsupdates bekommen? Was passiert mit Feedback von Nutzer:innen? Wer springt ein, wenn die App plötzlich nicht mehr funktioniert? Eine App, die einmal auf dem Server läuft, ist noch lange nicht wirklich „produktiv“. Deshalb haben wir uns auch hier interne Richtlinien gegeben – und es gilt wie immer: You build it, you run it. Das bedeutet aber auch, dass solche kleinen Helferlein genauso schnell wieder verschwinden können, wie sie entstanden sind. Und das ist völlig in Ordnung – solange sie in der Zwischenzeit echten Mehrwert stiften.
Es gibt aber auch Risiken. Wer als Führungskraft selbst baut, läuft Gefahr, sich zu verzetteln. Man kann schnell glauben, eine App sei „fast fertig“, weil die Oberfläche hübsch aussieht – und übersieht, dass darunter noch ganze Schichten fehlen. Ohne Leitplanken entsteht außerdem schnell Schatten-IT, die niemand warten will. Und nicht zuletzt ist es wichtig, die Rollen klar zu lassen: Ein Geschäftsführer bleibt Geschäftsführer, auch wenn er mal ein paar Zeilen Code schreibt.
Trotzdem: Für mich hat sich das Experiment gelohnt. Es hat meine Gespräche mit dem Team verändert, meinen Blick auf Architektur geschärft und mir gezeigt, wie wichtig es ist, Räume für Experimente zu öffnen, ohne die Basis zu gefährden. Ich werde nicht plötzlich wieder Entwickler – aber ich habe etwas mitgenommen, das meinen Job als Geschäftsführer besser macht.
Und vielleicht ist genau das die wichtigste Erkenntnis: Es geht nicht darum, selbst alles zu können. Es geht darum, zu verstehen, was passiert, wenn andere es tun – und die richtigen Strukturen zu schaffen, damit auch das eigene Team ausprobieren, lernen und wachsen kann.
