6. Mai 2025
Zwei Jahre ist in der KI-Entwicklung eine lange Zeit. GPT-4 war gerade herausgekommen als wir anfingen. Claude 3, Gemini, lokale Modelle, Agent-Frameworks: das meiste davon gab es noch nicht oder war noch nicht produktionsreif. Wir haben in einer Zeit gebaut in der sich die Grundlagen unter uns verändert haben während wir bauten.
Das ist der Kontext für diese Rückschau.
Früh anfangen, klein anfangen. Unser erster produktiver Use Case war kein Großprojekt. Es war ein Python-Skript, das SEO-Crawl-Daten aufbereitete. Kein elegantes System, kein skalierbares Design. Aber es lief, wurde täglich genutzt und hat uns das wichtigste gelehrt: wie man einen Prozess so strukturiert, dass ein Modell ihn versteht.
Diese Lernkurve ist nicht durch Theorie ersetzbar. Man lernt Prozessmodellierung für KI indem man Prozesse modelliert und scheitert und neu ansetzt.
Das Eigentümer-Prinzip. Jedes System hat eine namentliche Verantwortung. Der Unterschied zu "irgendwie betreuen" ist messbar: Systeme mit klaren Eigentümern werden schneller repariert wenn sie driften, werden häufiger hinterfragt wenn sich der Kontext ändert, und werden ehrlicher abgeschaltet wenn sie keinen Nutzen mehr bringen.
Dokumentation der Entscheidungen, nicht der Features. Wir dokumentieren nicht was ein System tut, das steht im Code. Wir dokumentieren warum es so gebaut wurde wie es gebaut wurde. Welche Alternativen wurden verworfen? Welche Einschränkungen galten? Was hat sich seit dem Build geändert?
Dieses Wissen ist das erste das verloren geht wenn Projekte wachsen oder Mitarbeiter wechseln.
Früher strukturieren. Ich habe zu lange im "Experimentier-Modus" gearbeitet und zu spät strukturelle Entscheidungen getroffen: zentrales API-Management, einheitliche Deployment-Muster, monatliche Betriebsprüfung. Das alles kam erst als der Wildwuchs schon da war. Es wäre effizienter gewesen, diese Strukturen von Anfang an einzuführen.
Schneller abschalten. Systeme die nicht genutzt werden, kosten trotzdem: Wartungsaufmerksamkeit, mentale Kapazität, die Illusion von Komplexität. Ich hätte früher den Maßstab "wird das aktiv genutzt?" rigoros angewandt.
Mehr in Qualitätssicherung investieren. Der schwierigste Teil von KI-Betrieb ist nicht der Build, sondern die Frage: Wie weiß ich, dass das System heute noch das tut was es soll? Modelle ändern sich. Kontexte ändern sich. Prompts die 2023 funktioniert haben, produzieren 2025 manchmal andere Ergebnisse. Systematische Qualitätschecks wären mehr wert gewesen als viele der Features die wir gebaut haben.
Die Modelle sind deutlich besser geworden. Was 2023 nur mit aufwändigen Prompting-Strategien funktionierte, funktioniert heute zuverlässiger mit einfacheren Ansätzen. Das hat Teile unserer Architektur obsolet gemacht, nicht weil sie falsch war, sondern weil die Annahmen unter ihr sich geändert haben.
Das ist normal. Aber es erfordert eine Bereitschaft zur Erneuerung die nicht selbstverständlich ist. Systeme die einmal laufen, haben Beharrungsvermögen, auch wenn es Sinn ergeben würde, sie neu zu bauen.
Wer jetzt anfängt, hat einen Vorteil: Die Modelle sind besser, die Patterns bekannter, die Fehler die andere gemacht haben, sind dokumentiert. Nutzen Sie diesen Vorteil. Aber machen Sie trotzdem Ihre eigenen Fehler. Es gibt keinen Weg um die Lernkurve herum, nur durch sie hindurch.