Start with Why, auch bei AI
TL;DR: Erst wissen, was man lösen will. Dann bauen. Nicht umgekehrt.
Ich erlebe es inzwischen in fast jeder technischen Diskussion. AI hier, AI dort. Und in fast jedem Kundengespräch fällt irgendwann der Satz: „Wir brauchen AI.”
Was deutlich seltener gefragt wird: Wofür eigentlich?
Genau das beschäftigt mich. AI ist vielerorts zur Voraussetzung geworden und nicht mehr das Ergebnis einer Überlegung.
Früher stand ein Problem im Raum. Man hat verschiedene Möglichkeiten betrachtet und das passende Werkzeug gewählt. Heute wird oft zuerst beschlossen, dass AI eingesetzt werden soll, und danach sucht man nach einer Stelle, an der sie irgendwie hineinpasst.
Damit das nicht falsch verstanden wird: Ich nutze agentic Coding Tools täglich. Ich baue selbst agentische Systeme. Genau deshalb sage ich in manchen Diskussionen auch: „Dafür braucht ihr keine AI.”
Nicht weil ich etwas dagegen hätte. Sondern weil ich finde, dass man zuerst verstehen sollte, welches Problem man lösen möchte und erst danach entscheidet, welches Werkzeug dafür sinnvoll ist.
Vibe Coding ist großartig, bis es das nicht mehr ist
Der aktuelle Hype heißt „Vibe Coding”. Nicht lange planen, sondern loslegen. Prompt eingeben, Ergebnis anschauen, weitermachen.
Für Prototypen ist das fantastisch. Man kann Ideen in Stunden statt in Wochen testen. Man lernt schneller. Man bekommt früh Feedback. Für Experimente oder Wegwerf-Prototypen ist das ein enormer Fortschritt.
Schwierig wird es, wenn aus dieser Geschwindigkeit eine Gewohnheit wird.
Code lässt sich heute in Minuten erzeugen. Die Fragen, die danach kommen, bleiben aber dieselben wie früher: Ist die Lösung sicher? Ist sie wartbar? Passt sie in die bestehende Landschaft? Wer übernimmt die Verantwortung, wenn daraus ein produktives System wird?
Diese Fragen verschwinden nicht, nur weil der erste Prototyp schnell entstanden ist.
Vor einiger Zeit habe ich genau das erlebt. Ein Fachbereich wollte „schnell mal” ein Auftragserfassungssystem bauen. Technisch war das heute keine große Sache: etwas Frontend, ein Cloud-Backend, Supabase für Authentifizierung und Datenhaltung. Innerhalb kurzer Zeit lief ein funktionierender Prototyp.
Dann passierte etwas, das häufig passiert.
Menschen begannen damit zu arbeiten. Daten wurden erfasst. Prozesse entstanden rund um das System. Aus dem Prototyp wurde schleichend ein produktives Werkzeug.
Irgendwann sollte die IT übernehmen.
Dann kamen die üblichen Fragen: Code Review. Security Checks. Integration in bestehende Benutzerverwaltung und Berechtigungskonzepte. Betrieb. Monitoring.
Und plötzlich zeigte sich, dass die ursprünglichen Entscheidungen genau für das getroffen worden waren, was man damals bauen wollte: einen schnellen Prototypen. Nicht für ein System, das langfristig Teil der Unternehmenslandschaft sein sollte.
Der Prototyp war nicht das Problem.
Das Problem war, dass niemand definiert hatte, ab welchem Punkt er keiner mehr ist.
Wenn Bauen billiger wird
Noch spannender wird es auf Organisationsebene.
Lange Zeit war Softwareentwicklung teuer genug, um eine gewisse Disziplin zu erzwingen. Bevor ein Team etwas neu gebaut hat, wurde geprüft, ob es dafür bereits eine Lösung gibt. Nicht unbedingt aus architektonischer Überzeugung, sondern weil ein Neubau Zeit, Geld und Ressourcen gekostet hat.
Heute ist diese Hürde deutlich kleiner geworden.
Mit modernen Frameworks, Cloud-Plattformen und AI-gestützter Entwicklung lassen sich funktionierende Lösungen in erstaunlich kurzer Zeit erstellen. Das ist grundsätzlich etwas Positives.
Die Kehrseite ist allerdings, dass die natürliche Bremse wegfällt.
Wenn Bauen sehr günstig wird, entsteht schnell die Versuchung, Probleme lokal zu lösen. Jedes Team optimiert für seine eigene Situation. Jeder Bereich baut sich die Lösung, die gerade am besten passt.
Das Ergebnis sieht dann oft so aus:
Fünf Teams bauen fünf Varianten derselben Anwendung. Alle funktionieren. Alle erfüllen ihren Zweck. Alle wurden mit guten Absichten entwickelt.
Und trotzdem entsteht ein Problem.
Denn die Kosten sind nicht verschwunden. Sie haben lediglich den Ort gewechselt.
Statt einmal zu entwickeln, betreibt man plötzlich fünf Lösungen. Fünf Deployments. Fünf Sicherheitskonzepte. Fünf Integrationen. Fünf Systeme, die gepflegt, aktualisiert und dokumentiert werden müssen.
Der eigentliche Denkfehler liegt darin, „einfach zu bauen” mit „billig” gleichzusetzen.
Der erste Build ist billig geworden.
Betrieb, Wartung, Governance und Standardisierung sind es nicht.
Agentic AI verstärkt diesen Effekt
Agentische Systeme werden diese Entwicklung eher beschleunigen als bremsen.
Wenn mehrere Teams ihre eigenen AI-Assistenten nutzen, um Data-Pipelines, APIs oder interne Anwendungen zu erstellen, entstehen sehr schnell funktionierende Lösungen. Jede einzelne kann für ihren jeweiligen Anwendungsfall absolut sinnvoll sein.
Aus Sicht der zentralen IT ergibt sich aber ein anderes Bild.
Plötzlich existieren drei unterschiedliche Architekturen für dasselbe Problem. Drei verschiedene Wege, Daten zu verarbeiten. Drei verschiedene Integrationsansätze. Drei verschiedene Betriebsmodelle.
Niemand hat dabei zwingend etwas falsch gemacht.
Die Teams haben lediglich die Möglichkeiten genutzt, die ihnen zur Verfügung standen.
Genau deshalb glaube ich, dass die Antwort nicht darin liegt, langsamer zu werden oder Innovation zu bremsen.
Die Antwort liegt in einer stärkeren Plattform-Orientierung.
Je einfacher Bauen wird, desto wichtiger werden gemeinsame Standards, Golden Paths, Templates und wiederverwendbare Bausteine. Der einfachste Weg sollte gleichzeitig der Weg sein, der sich gut in die Gesamtlandschaft einfügt.
Wenn Entwicklungskosten sinken, steigt der Wert guter Architektur.
Nicht jede AI ist ein Gewinn
Ein weiterer Punkt geht in der aktuellen Begeisterung oft unter.
Jedes zusätzliche AI-System bringt Verantwortung mit sich.
Es muss betrieben werden. Es muss abgesichert werden. Es muss überwacht werden. Es muss erklärt werden können. In vielen Branchen muss es irgendwann auch regulatorisch bewertet und dokumentiert werden.
Wenn ein AI-System einen klaren Mehrwert liefert, ist dieser Aufwand oft gerechtfertigt.
Wenn es lediglich eingebaut wurde, weil AI gerade auf der Roadmap stehen sollte, sieht die Rechnung anders aus.
Dann erzeugt man zusätzliche Komplexität, ohne ein entsprechendes Problem zu lösen.
Und Komplexität hat die unangenehme Eigenschaft, dass sie selten sofort sichtbar wird. Die Rechnung kommt meist später.
Die Fragen, die ich häufiger hören würde
Bevor gebaut wird, helfen aus meiner Sicht ein paar überraschend einfache Fragen:
Manchmal lautet die Antwort ja.
Manchmal reicht ein Skript.
Manchmal eine Regel.
Manchmal ein besser definierter Prozess.
Und manchmal stellt sich heraus, dass das eigentliche Problem an einer ganz anderen Stelle liegt.
Das ist kein Rückschritt. Das ist solide Ingenieursarbeit.
Wo AI für mich tatsächlich einen Unterschied macht
Trotz aller Kritik nutze ich AI jeden Tag.
Für schnelle HTML-Dashboards und Reports, bei denen Funktion wichtiger ist als Perfektion.
Für Recherchen und Formatierungsaufgaben, die zwar Zeit kosten, aber wenig kreativen Mehrwert erzeugen.
Vor allem aber als Lernwerkzeug.
Wenn ich mich in ein neues Framework, eine Bibliothek oder ein technisches Konzept einarbeiten muss, ist AI oft ein hervorragender Sparringspartner. Sie ersetzt keine Dokumentation und kein eigenes Denken. Aber sie verkürzt den Weg zu einem brauchbaren Verständnis erheblich.
Genau dort spielt sie ihre Stärken aus: Sie beschleunigt Arbeit, die ohnehin erledigt werden muss.
Am Ende ist die Frage erstaunlich einfach
Für mich geht es nicht darum, ob AI eingesetzt wird oder nicht.
Die eigentliche Frage lautet:
Lösen wir ein Problem und wählen danach das passende Werkzeug? Oder haben wir uns bereits auf das Werkzeug festgelegt und suchen jetzt nach einem Problem dazu?
Das ist kein Plädoyer gegen AI.
Es ist ein Plädoyer fürs Nachdenken vor dem Bauen.
Erst verstehen.
Dann entscheiden.
Dann bauen.
Transparenz: Dieser Beitrag entstand mit KI-Unterstützung. Ich habe ihn geprüft und verantworte den Inhalt. Mehr dazu unter KI-Transparenz.