Meine Petrischale: Warum ich ein Corporate LLM zuerst für mich selbst baue

Ich baue seit meinen ersten Gehversuchen in der erweiterten Applikationsentwicklung mittels Vibe-Coding an meinem eigenen System, unter anderem ein Corporate LLM, das über n8n, API-Schnittstellen mit proprietären und lokalen KI-Modellen und Datenbanken verdrahtet ist, und ich erkläre es nie für fertig, denn es wächst mit dem, was ich dabei lerne und wie ich es anwende.

Codex und Claude Code sei Dank – was als Experiment begann, ist zu etwas geworden, das ich am ehesten als Petrischale beschreiben würde. Ein System, an dem ich Ideen teste, Prozesse nachbaue und Grenzen auslote, bevor irgendjemand anderes damit in Berührung kommt.

Was darin steckt

Jede Funktionalität, die ich integriert habe, funktioniert autark und ist gleichzeitig mit den anderen Funktionen verknüpft: ein Newsroom, ein Webanalyse-Tool, ein Recherche Room, ein Blog Designer, eine automatisierte Buchhaltung mit Rechnungsablage, eine Wissensdatenbank – und die Liste wird länger, nicht kürzer. Jede realisierte Funktion wird durch Effizienzgewinn und Erfahrung belohnt, und beides zusammen ist der eigentliche Antrieb weiterzumachen.

Mit HTML und CSS kenne ich mich seit vielen Jahren aus, aber was Claude Code, Codex und Gemini an Möglichkeiten eröffnet haben, hat meine Fähigkeiten um ein Vielfaches erweitert, sodass ich oft selbst nicht aus dem Staunen herauskomme, was hier möglich ist. Tools, die vor zwei Jahren noch Entwicklerteams gebraucht hätten, baue ich heute in Stunden zusammen, teste sie an meinen eigenen Abläufen und weiss danach, ob sie tragen oder ob der Ansatz von vorne gedacht werden muss.

Das ist die Sonnenseite.

Wo Licht ist, ist auch Schatten

Das Workflow-Automatisierungstool n8n hat zum Beispiel eine neue Rolle bekommen. Bis Ende 2025 galt es noch als Agenten-Baukasten, als eines der Tools, um die sich in der KI-Szene vieles drehte. Mittlerweile wird es in der KI-Bubble als abgehängt und austauschbar gehandelt. Ob das stimmt, ist fast nebensächlich, denn wichtiger ist, wie sichtbar dadurch die Rasanz in der KI-Weiterentwicklung wird. Die Halbwertzeiten von Tools und SaaS-Lösungen waren wahrscheinlich noch nie so überschaubar und flüchtig wie in diesen stürmischen Zeiten.

Und mit einem gewissen Schmunzeln – nehmt es mir bitte nicht übel – durfte ich beobachten, wie viele ihre mühsam gebauten GPTs aus OpenAI zu Claude umgezogen haben. Die Frage auch hier: Welches Ökosystem wird sich langfristig etablieren?

Der Kampf der Giganten ist in vollem Gange. Drei der grössten Börsengänge, die die Welt je gesehen hat, finden in diesem Jahr statt: SpaceX, Anthropic und OpenAI. Diese Unternehmen haben bereits verändert, wie wir arbeiten und wie wir die Welt aus neuen Perspektiven betrachten. Und wie immer bei solchen Umbrüchen – es ist erst der Anfang.

Die eigentliche Frage

Aber vielleicht ist die Frage nach dem richtigen Ökosystem ohnehin die falsche. Vielleicht sollte sie lauten: Wie schaffen wir es, in dieser Dynamik die Eigenständigkeit unserer Abläufe zu halten, sie sinnvoll mitwachsen zu lassen, ohne in der Vielfalt durchzudrehen?

Die wachsende Herausforderung ist nicht, das richtige Tool zu finden. Die Herausforderung ist, flexibel genug zu bleiben, um das nächste Tool integrieren zu können, ohne bei jedem Plattformwechsel von vorne anzufangen. Wer sich zu tief in ein einziges Ökosystem eingräbt, hat irgendwann ein System, das glänzt, aber nicht mehr umziehen kann. Wer alles offen hält, hat am Ende gar nichts, das richtig funktioniert. Irgendwo dazwischen liegt der Weg, und er ist schmaler, als die meisten denken.

Zurück zur Petrischale

Mein persönliches Langzeitprojekt auf dem Weg zur Autarkie. Mittlerweile konnte ich auch meine lokalen KI-Modelle anschliessen, und die Frage, ob das der Weg in die Unabhängigkeit ist, beantworte ich mir selbst mit: teils, teils. Unabhängigkeit von einem einzelnen Anbieter – ja, ein Stück weit. Unabhängigkeit von der Entwicklung insgesamt – nein, die gibt es nicht, und wer das behauptet, verkauft etwas.

Mein Ansatz ist konservativ, und er hat sich auch im prähistorischen KI-Zeitalter schon ausgezahlt: Bevor etwas an einen Kunden geht, muss es in meinen eigenen Abläufen funktioniert haben, nicht als Versprechen, sondern als Erfahrung. Erst dann gehe ich an den Kunden. Was ich weitergebe, habe ich vorher selbst durchlebt, mit allen Umwegen und Hürden, die dazugehören.

Wenn ich in einem Gespräch aufschnappe, dass irgendein Prozess nervt oder zu lange dauert, baue ich es nach – an meinem System und nicht am laufenden Betrieb von jemand anderem. Manchmal funktioniert es auf Anhieb. Manchmal merke ich erst nach ein paar Tagen, dass das eigentliche Problem ganz woanders lag. Und manchmal stelle ich fest, dass die Lösung, die auf dem Papier elegant aussah, in der Praxis an einer Stelle scheitert, die vorher niemand auf dem Schirm hatte, auch ich nicht.

Effizient ist das nicht, jedenfalls nicht am Anfang. Aber es ist der einzige Weg, auf dem ich einem Kunden nicht nur sagen kann, dass etwas funktioniert, sondern es wissen kann, weil ich die Umwege und die Grenzen selbst durchlaufen habe.

Die Rollen, die niemand auf der Rechnung hat

Denn KI nimmt vieles ab, aber Denken nimmt sie einem nicht ab. Denken wie ein Entwickler, ein System-Architekt, ein Compliance- und Security-Manager, ein UX-Designer, ein Business-Stratege. Das sind verdammt viele Rollen, die man auf dem Schirm haben sollte, wenn man mit Vibe-Coding und KI-Unterstützung nicht nur beeindruckende Demos baut, sondern tragfähige Projekte, die ein Kunde im Alltag nutzen soll.

Die Sonnenseite des Vibe-Codings – diese fast berauschende Erweiterung der eigenen Fähigkeiten – hat eine Kehrseite, die selten benannt wird: Die Werkzeuge machen es leichter, etwas zu bauen. Sie machen es nicht leichter, das Richtige zu bauen. Dafür braucht es Erfahrung, und Erfahrung entsteht nicht durch Geschwindigkeit, sondern durch Umwege, durch Scheitern und durch die Bereitschaft, einen Ansatz nach drei Tagen wieder einzureissen, weil er zwar funktioniert, aber das falsche Problem löst.

Was am Ende steht

Vielleicht ist das überhaupt der Punkt, der über die technischen Details hinausgeht: Was man weitergeben will, sollte man selbst einmal durchlebt haben. Nicht als Konzept, nicht als Theorie, sondern als gelebte Erfahrung mit allen Dellen und Überraschungen, die dazugehören. Ein Lehrer war auch einmal Schüler, und die Erfahrung aus dem, was gelungen ist, und aus dem, was gescheitert ist, hilft enorm dabei, einen echten Erkenntnisgewinn weiterzugeben. Denn dieser beruht nicht mehr auf der ursprünglichen Begeisterung, einen bestimmten Weg einzuschlagen, sondern auf der intensiven Auseinandersetzung damit.

Was am Ende steht, ist selten das, was am Anfang gesucht wurde. Meistens ist es sogar noch besser.