Die Welt, wie sie mir gefällt: Tools verbinden statt neu bauen

Dank Vibe-Coding bin ich ein bisschen Pippi Langstrumpf: Ich mach mir die Welt, wie sie mir gefällt.

Mit KI kann ich heute in kurzer Zeit Software bauen, für die ich früher Wochen gebraucht hätte. Die naheliegende Idee wäre, mir alles selbst zu bauen: ein eigenes CRM, ein eigenes To-do-Tool, ein eigenes Monitoring. Genau das mache ich nicht.

Was ich nicht baue

Ich komme nicht auf die Idee, ein CRM von Grund auf neu zu schreiben oder ein To-do-Tool. Das gibt es alles schon, und zwar in gut. Für die Buchhaltung nutze ich Lexware, für Aufgaben Vikunja, für die Erreichbarkeit meiner Dienste Uptime Kuma, für Zeiterfassung Toggl, für Code und Pipelines GitLab.

Diese Programme sind über Jahre Stück für Stück entwickelt worden, und andere Leute nehmen sich die Zeit, sie zu pflegen.

Sicherheitsupdates, Randfälle, Datenmigrationen: Das alles müsste ich bei einem Eigenbau selbst stemmen. Dauerhaft.

Was ich stattdessen baue

Was ich immer öfter baue, sind Hilfen: Programme, die mir helfen, den Überblick zu behalten. Mein zentrales Werkzeug dafür heißt FleetDeck. Es ist eine Symfony-Anwendung, die ich seit April 2025 für mich betreibe und die per API auf die einzelnen Dienste zugreift und deren Informationen an einer Stelle sammelt.

Auf einen Blick sehe ich dort:

• was meine Server gerade machen, also Auslastung, Speicher, Platte,
• wie die Pipelines in GitLab stehen,
• welche Projekte gerade wo hängen,
• was Uptime Kuma meldet,
• welche Zeiten in Toggl gebucht sind.

Technisch ist das oft unspektakulär. Der Pipeline-Status zum Beispiel ist ein Symfony-Command, der regelmäßig läuft:

#[AsCommand(
    name: 'fleetdeck:pipelines:check',
    description: 'Prüft den Pipeline-Status aller GitLab-Projekte (leichtgewichtig, für häufiges Polling)'
)]

Ähnlich sieht es für Uptime Kuma (fleetdeck:kuma:sync) und Toggl (app:toggl:sync-range) aus. Jeder Dienst bleibt, was er ist. FleetDeck fragt nur ab, was ich sehen will, und zeigt es so an, wie ich es sehen will.

Das ist der Teil, bei dem die KI glänzt. So eine Anbindung ist schnell zusammengesteckt: API-Dokumentation rein, Command und Ansicht raus, Tests drüber. Das Risiko ist klein, denn wenn meine Übersicht einmal einen Fehler hat, sind die Daten in den Originalsystemen trotzdem sicher.

Und für Kunden?

Für Kunden mache ich das im Prinzip genauso, nur mit höheren Ansprüchen an die Qualität. Dabei hilft die KI auch, zusammen mit einer vernünftigen Planung (wie ich plane, habe ich in Ich schreibe keinen Code mehr. Bin ich jetzt Vibe-Coder? beschrieben).

Wenn ein Kunde sagt: „Ich hätte gern ein To-do-Tool“ oder „ein Tool für den Support, in dem ich Tickets verwalte und auch Kunden pflegen kann“, dann schlage ich meistens nicht vor, das neu zu programmieren. Ich schlage vor, etablierte Systeme im Hintergrund zu nutzen und sie per API anzusprechen. Oben drauf kommt die Oberfläche, die genau zu seinen Abläufen passt.

Damit hat er die Vorteile aus beiden Welten. Die Anwendung ist so gebaut, wie er sie gern hätte, mit seinen Begriffen und seinen Arbeitsschritten, und darunter liegen getestete, lange etablierte Systeme, die jemand anderes pflegt. Er bezahlt nicht dafür, dass ich eine Ticketverwaltung zum hundertsten Mal neu erfinde.

Was ich daraus mitnehme

• KI macht Eigenbau billig, aber nicht den Betrieb. Schreiben ist schnell, pflegen bleibt teuer. Deshalb baue ich Oberflächen und Verbindungen, keine Kernsysteme.
• Die API ist die wichtigste Frage bei jeder Softwareauswahl. Ein Werkzeug ohne vernünftige Schnittstelle kann ich nicht in meine Welt holen.
• Für den Kunden ist das oft die bessere Lösung: weniger eigener Code, weniger Angriffsfläche, trotzdem genau sein Ablauf.
• Jede Anbindung ist eine Abhängigkeit. Ändert ein Anbieter seine API oder seine Preise, muss ich nachziehen. Das nehme ich in Kauf, aber es gehört in jede Planung.