Ein vollständiger Monitoring-Stack ist nicht Grafana mit einem hübschen Dashboard. Ein Dashboard hilft dabei, das System zu betrachten, beantwortet für sich genommen aber nicht die zentrale Betriebsfrage: Was ist kaputt, wo genau, wie schwerwiegend ist es und wen muss man wecken?
Die Diskussion über kleine Sprachmodelle beginnt oft mit einer falschen Erwartung: Man nimmt ein 3B- oder 8B-Modell, startet es lokal und bekommt fast dasselbe wie `ChatGPT`, nur günstiger und auf dem eigenen Rechner. Das ist eine bequeme Fantasie, aber ein schlechter technischer Rahmen.
Eine günstige Cloud für ein Startup ist nicht einfach die kleinste Instanz in der Preisliste. Wenn die Anwendung beim ersten Traffic-Peak ausfällt, wenn Backups manuell zusammengesucht werden müssen oder wenn ausgehender Traffic plötzlich mehr kostet als der Server, wird die Ersparnis schnell zur Schuld.
Noch vor Kurzem wurde AI in der Softwareentwicklung vor allem als intelligenteres Autocomplete wahrgenommen. `Copilot` schlug die nächste Zeile vor, `ChatGPT` half beim Erklären einer Fehlermeldung, und der Entwickler blieb die einzige Person im Prozess, die die Aufgabe wirklich als Ganzes sehen konnte.
Wenn es um CI/CD geht, landen Jenkins, GitHub Actions, GitLab CI, Argo CD und Tekton oft in derselben Vergleichstabelle. Für eine erste Orientierung ist das praktisch, aber 2026 kann so eine Tabelle leicht in die Irre führen. Manche Werkzeuge lösen Builds und Tests nah am Repository. Andere steuern Deployments nach Kubernetes. Wieder andere sind Bausteine für eine interne Delivery-Plattform.
Noch vor kurzem bedeutete Automatisierung fast immer dasselbe: Ein Unternehmen kaufte ein `SaaS`-Produkt, Mitarbeitende lernten die Oberfläche, verschoben Daten manuell zwischen Systemen, klickten die richtigen Buttons, schickten E-Mails, schlossen Tickets und bauten Reports zusammen. In diesem Modell steckte der größte Teil des Produktwerts in Screens, Rollen und Schritt-für-Schritt-Abläufen, durch die sich Menschen selbst bewegen mussten.
Wenn Teams zum ersten Mal ein `LLM` an ein Produkt anschließen, wirkt es oft so, als sei der schwierigste Teil schon geschafft. Das Modell beantwortet Fragen, formuliert Texte um, schreibt Entwürfe und führt Dialoge. Aber sobald das Produkt auf echte Geschäftsprozesse trifft, zeigt sich eine unangenehme Tatsache: Für sich genommen weiß das Modell fast nichts über eure Verträge, internen Richtlinien, Wissensdatenbanken, Tickets, euren Code, Produktkataloge oder neue Dokumente.
Noch vor einem Jahr drehte sich die Diskussion über lokale LLMs oft um Demos, Heim-GPUs und die Begeisterung darüber, dass ein Modell überhaupt ohne Cloud läuft. Im Jahr 2026 ist das Thema deutlich erwachsener geworden. Unternehmen haben inzwischen API-Rechnungen gesammelt, Compliance-Fragen auf dem Tisch und genug Erfahrung mit der Abhängigkeit von externen Anbietern. Deshalb lautet die eigentliche Frage heute nicht mehr: „Kann man ein Modell selbst betreiben?“, sondern: In welchen Szenarien ist das tatsächlich wirtschaftlicher und sicherer, als sich nur auf OpenAI, Google oder Anthropic zu verlassen?
Es gibt ein hartnäckiges Muster, an dem technische Startups sterben. Nicht an einer schlechten Idee und nicht an Geldmangel im ersten Monat. Sondern daran, dass drei Ingenieure ein halbes Jahr lang Infrastruktur für eine Million Nutzer bauen, die sie nicht haben und vielleicht nie haben werden.
Im Jahr 2026 wirkt die Debatte "Cloud gegen eigene Server" nicht mehr wie ein Kampf zwischen Vergangenheit und Zukunft. Sie ist deutlich nüchterner geworden: Unternehmen zählen wieder Geld, schauen auf reale Rechnungen und kommen immer häufiger zu dem Schluss, dass es keine universelle Antwort gibt. Mehr noch: Der Trend selbst hat sich von cloud-first zu cloud-appropriate verschoben - nicht mehr "wir ziehen alles in die Cloud", sondern "wir legen jede Last dorthin, wo sie wirtschaftlich und technisch sinnvoll ist". Dazu beigetragen haben sowohl steigende Rechnungen bei Public Clouds als auch Anforderungen an Data Sovereignty und der Wunsch nach besser planbarer Infrastruktur.
Noch vor ein paar Jahren klang die Formulierung "ein KI-Startup allein aufbauen" wie eine schöne Fantasie. Heute ist das keine Fantasie mehr, sondern ein durchaus praktikables Format für die erste Phase. Nicht weil es leicht geworden wäre, allein ein Unternehmen aufzubauen. Sondern weil KI die Kosten von Experimenten drastisch gesenkt hat: Was früher einen Designer, einen Frontend-Entwickler, einen Backend-Entwickler, DevOps und etwas Glück brauchte, kann heute oft von einer Person auf fertiger Infrastruktur und mit API-Modellen zusammengesetzt werden.
In den letzten Jahren sind KI-Tools zu einem festen Bestandteil der Softwareentwicklung geworden. Es ist jedoch wichtig zu verstehen, dass KI kein „Programmierer ist, der alles für uns schreibt“, sondern ein Beschleuniger der Entwicklung, der nur innerhalb des Kontexts funktioniert und eine Validierung der Ergebnisse erfordert.
