Warum KI keine Abkürzung für echte Expertise ist
In letzter Zeit frage ich mich, wie mein Berufsstart bei BCxP verlaufen wäre, hätte es damals schon KI-Assistenten gegeben.
Mein erstes größeres Feature sah harmlos aus, ein Ticket unter vielen. Tatsächlich hat es mich Tage gekostet, irgendwo zwischen Datenbank und Framework-Magie. Doku lesen, StackOverflow durchforsten, Kolleg:innen fragen, mühsam eine Lösung erarbeiten. Abends ging ich nach Hause, ohne „fertig“ zu sein, aber mit dem Gefühl: Jetzt verstehe ich endlich, warum das so funktioniert. Mit KI hätte ich den Code kopiert, das Problem grob beschrieben und in Minuten eine plausible Lösung bekommen. Ticket fertig, Output gestiegen. Aber ich hätte kein mentales Modell aufgebaut und nie verstanden, was hinter der Framework-Magie steckt.
Alle reden darüber, wie KI Entwickler:innen schneller macht. Seltener wird gefragt: Was kostet diese Geschwindigkeit? Lernen braucht Verzweiflung und Reibung. In der Lernforschung gibt es dafür den Begriff „desirable difficulties“: Anstrengung, die kurzfristig bremst, aber langfristig Verständnis stabilisiert. Genau diese produktive Reibung nimmt KI aber zuverlässig aus dem Prozess.
Erfahrung macht den Unterschied
Ob mir KI hilft oder schadet, hängt stark davon ab, wie viel Erfahrung ich mitbringe. Und zwar nicht nur in Berufsjahren, sondern in der konkreten Domäne und im Stack.
Als Junior hätte ich mir sicher oft gedacht: „Wenn die KI ein Problem, für das ich sonst Stunden bräuchte, in fünf Minuten löst – kann ich es mir überhaupt leisten, die Abkürzung nicht zu nehmen?“ Das Problem dabei: Mir fehlen die Referenzpunkte, um zu erkennen, wann KI schlecht abstrahiert, subtilen Unsinn baut oder zwar funktioniert, aber die Architektur unbemerkt verschlechtert. Ich kann schwer bewerten, was ich noch nie selbst gebaut, kaputtgemacht und wieder repariert habe. Gerade dadurch gehen wichtige Lernmomente verloren: Debugging, systematische Fehlersuche, Intuition. Der Druck, die Abkürzung trotzdem zu nehmen, ist groß, wenn Tempo erwartet wird.
Mit zehn Jahren Erfahrung kenne ich Muster und Stolperfallen und habe selbst genug schlechten Code produziert, um zu erkennen, warum er schlecht ist. Ich sehe KI als Helfer:in, der:die sehr eifrig, aber eben auch unzuverlässig ist. Ich formuliere daher zuerst meinen eigenen Lösungsansatz, lasse mir dann Varianten und Gegenargumente geben und delegiere Routinearbeit wie Boilerplate oder einfache Migrationsskripte. So wird KI zum Sparringspartner, nicht zum Autopiloten. Aber auch hier gilt: Wenn ich alles, was neu oder wirklich kompliziert ist, an KI weggebe, stagniere ich. Fähigkeiten, die ich nicht trainiere, verkümmern.
Heute schaue ich auch deshalb anders darauf, weil Code für unsere Kund:innen nicht nur fertig werden muss. Er muss verstanden, betrieben, verändert und langfristig verantwortet werden.
Wann hilft mir KI und wann nicht
Statt nur zu fragen „KI, ja oder nein?“, ist es für mich hilfreicher, zu überlegen, wie sich KI je nach Erfahrung und Aufgabe einsetzen lässt. Aus meiner Praxis und der Beobachtung im Team ist dafür eine einfache Heuristik entstanden:
Unabhängig davon, wo ich mich in dieser Matrix befinde, hat es sich für mich bewährt, die Zusammenarbeit mit der KI in drei klaren Modi zu denken.
Wie viel Verantwortung gebe ich der KI?
Bei BCxP diskutieren wir intern offen, wo KI uns wirklich besser macht und wo sie uns nur schneller wirken lässt. Für mich haben sich aus dieser Reflexion drei Modi herauskristallisiert.
Recherchemodus
Wenn ich merke, dass mir Grundlagen fehlen, gehe ich in den Recherchemodus. Ich lasse mir Dinge erklären, implementiere aber selbst. Ich tippe den Code, frage nach dem „Warum“, nach Alternativen und Risiken und lasse mir Begriffe, Paradigmen und Patterns erläutern. So kann ich gut in neue Technologien oder Domänen einsteigen. Die KI liefert dabei Wissen, nicht direkt die Lösung. Ich nutze sie eher wie eine interaktive Variante von StackOverflow. Optimal ist es, meine Schlussfolgerungen anschließend mit jemand Erfahrenerem abzugleichen.
Sparringmodus
Wenn ich bereits eine Idee habe, aber ihre Tragfähigkeit prüfen will, gehe ich in den Sparringsmodus. Ich skizziere meinen Ansatz, lasse mir Kritik, Alternativen und Randfälle aufzeigen und nutze die KI als Spiegel und Gegenstimme, nicht als Entscheider:in. Dieser Modus passt bei schwierigen Problemen oder bei Architekturentscheidungen, die bewusst getroffen werden sollen.
Delegationsmodus
Wenn es um Routine geht und ich das Ergebnis wirklich beurteilen kann, gehe ich in den Delegationsmodus. Dann schreibt die KI und ich reviewe. Das ist der Modus, in den viele reflexartig springen. Das ist aber gefährlich, wenn Erfahrung fehlt. Mein Grundsatz: Ich kann nur das zuverlässig reviewen, was ich im Prinzip auch selbst hätte schreiben können. Sonst ist es kein Review, sondern blindes Vertrauen.
Für Routineaufgaben ist dieser Modus in Ordnung, solange jemand aufmerksam prüft. Für komplexe Themen ist er nur dann sinnvoll, wenn die reviewende Person tief genug im Stoff steckt, um die KI-Ausgabe wirklich kritisch zu bewerten.
Die unbequeme Frage: Tempo oder Tiefe?
Damit lande ich wieder bei meiner Ausgangsfrage: Was wäre aus meinem damaligen Junior-Ich geworden, wenn ich KI zur Verfügung gehabt hätte?
Ich wäre vermutlich schneller gewesen und hätte früher „beeindruckenden“ Output geliefert. Aber vieles, was mich heute auszeichnet, wäre langsamer gewachsen oder an manchen Stellen gar nicht vorhanden: Intuition, strukturierte Fehlersuche, Bauchgefühl für Architektur.
Ich weiß, dass Tempo zählt. Für mich, für mein Team, für unsere Kund:innen. Die Frage ist nicht, ob ich KI nutze, sondern wie bewusst ich entscheide, wann ich die Abkürzung nehme und wann nicht. Das betrifft nicht nur mich: Juniors entscheiden, wie sie lernen. Seniors entscheiden, was sie noch selbst machen. Teams entscheiden, wie viel Raum sie für produktives Scheitern lassen.
Denn unser Anspruch bei BCxP ist es, nicht nur Code zu liefern, sondern Entscheidungen, die andere später verstehen und tragen können.
Was ich daraus für meine Arbeit ableite
Wenn ihr für euch reflektieren wollt, wie ihr KI sinnvoll einsetzt, sind das die fünf Leitplanken, an denen ich mich orientiere:
Nicht jede Beschleunigung ist ein Fortschritt. Wie viel Verantwortung ich an KI abgebe, ist die Entscheidung, die mir kein Modell abnehmen kann.
Fragen? Lust auf Austausch? Oder steht ihr gerade vor der Herausforderung, technische Entscheidungen zu treffen, die nicht nur heute funktionieren, sondern auch morgen noch tragfähig sind?
Stefan begleitet seit vielen Jahren komplexe Softwareprojekte – von der Architektur über die Implementierung bis hin zum Betrieb und zur kontinuierlichen Weiterentwicklung. Dabei beschäftigt ihn nicht nur die Frage, welche Technologien sinnvoll sind, sondern auch, wie Teams Wissen aufbauen, Verantwortung übernehmen und langfristig wartbare Systeme schaffen.
Wenn ihr darüber sprechen möchtet, wie KI sinnvoll in der Softwareentwicklung eingesetzt werden kann, welche Rolle Erfahrung dabei spielt oder wie technische Entscheidungen nachhaltig getroffen werden, dann ist Stefan der richtige Ansprechpartner.
Neugierig geworden? Stefan freut sich auf eure Nachricht!
Hinweis:
Das Header- und Zusatzbild dieses Artikels wurden mithilfe Künstlicher Intelligenz erstellt.
Und falls du dir diesen Artikel hast vorlesen lassen: Die Audioversion wurde mithilfe einer KI-generierten Stimme erstellt.
