Ich hatte letztes Jahr an dieser Stelle in „Verhindern wir lernen?“ folgenden Gedanken durchgearbeitet: Wenn wir durch KI etwas erstellen lassen, fokussieren wir nur mehr auf das Produkt – nicht mehr den Prozess des Entstehens. Und dadurch entgeht uns etwas: die Möglichkeit zu lernen.
Ich möchte diesen Gedanken heute sogar noch etwas weiter spinnen. Ich glaube nämlich, dass wir da noch etwas ganz anderes machen, und zwar bauen wir keine Beziehung zu dem Ergebnis auf. Das führt dazu, dass wir es weniger wertschätzen, schneller austauschen und keine große Bindung dazu aufbauen.
Zwei Beispiele: Jemand repariert einen alten Laserdrucker. Papierstau-Sensor gereinigt, Walze getauscht, Gehäuse wieder zu. Eine Stunde Arbeit, Schraubenzieher und ein YouTube-Video. Wer so ein Ding einmal aufgeschraubt hat, kennt es danach. Weiß, wo es klemmt, warum es manchmal komisch zieht, wo die schwache Stelle sitzt. Hat gerochen, wie Tonerstaub riecht. Hat verstanden, warum der Einzug manchmal versagt.
Ein nagelneuer Mixer, nach zwei Jahren mit kaputtgegangenem Motor weggeschmissen. „Kann man sowieso nicht reparieren lassen.“ Stimmt vielleicht. Vielleicht auch nicht. Aber interessanter ist das, was davor steht: Der Versuch wurde gar nicht erst gemacht. Zwei Jahre täglich in Betrieb. Jeden Morgen Smoothies. Und trotzdem völlig fremd. Eine Blackbox. Eingesteckt, genutzt, entsorgt.
Besitzen heißt verstehen
Ich bin die Tage auf folgenden Satz gestoßen: „If you can't fix it, you don't own it.“ (iFixIt Manifesto). Und da ist was dran, finde ich: Dinge, in die wir Zeit und Gedanken gesteckt haben, sind uns nah. Dinge, die wir nur konsumieren, bleiben auf Abstand.
Wir schmeißen heute massenhaft weg. Nicht weil uns Nachhaltigkeit egal wäre. Sondern weil uns die Dinge egal sind. Keine Beziehung. Kein Schmerz beim Wegwerfen.
Agentic Engineering
Und wir machen das gleiche jetzt mit Vibecoding und Agentic Engineering. Wir generieren Testfälle, Automatisierungen, Code, Datenbank-Schemata, Testdaten, Schnittstellen ... und wenn wir einen Fehler finden? Dann schnell mal Codex oder Claude Code dran gelassen. Und schwuppdiwupp ist der Fehler behoben. Wir wissen dann gar nicht, was die Ursache war, und selbst wenn wir sie da lesen, sind wir ja nicht davor gefeit, dass es erneut passiert.
Selbes Bild bei Tests. Testfälle aus Anforderungen generieren, jucheee. Schnell, sauber, viele. Nur: Wer hat dabei verstanden, warum dieser Grenzfall existiert? Welcher Stakeholder-Konflikt hinter dieser Anforderung steckt? Was im letzten Release schief gegangen ist, weshalb dieser Test überhaupt jetzt hier steht? Das Artefakt ist da. Die Geschichte dahinter nicht.
Ownership entsteht im Prozess
Ownership entsteht nicht, wenn ich etwas erhalte. Sie entsteht, wenn ich etwas durchdringe. Wenn ich debugge, refactore, kämpfe, mich damit reibe. Wenn ich einen Fehler gemacht und ihn behoben habe.
Diese Art von Ownership ist nicht romantisch gemeint. Wer seinen Code besitzt, kann ihn reparieren. Wer seine Architektur besitzt, kann sie verantworten. Wer seine Tests besitzt, weiß, was sie prüfen und was nicht.
Ich würde sogar sagen, je tiefer wir darin versinken und uns reinarbeiten, desto mehr Stolz, Beziehung und Verantwortung haben wir ... spüren wir.
Wer KI-Output nur übernimmt, hat das nicht. Das ist ein Unterschied.
Wir bauen gerade mit Hochdruck Software, die aus generierten Teilen zusammengesetzt ist, die niemand wirklich durchdrungen hat. Und wir nennen das Produktivität. Sie läuft, solange nichts passiert. Sobald etwas passiert, schauen alle sich ratlos an ... und fragen die KI.
Die Balance finden
Ihr wisst, ich mag KI. Ich nutze sie auch oft. Aber wie so oft mit Technologie, müssen wir erst lernen, damit in einem guten Maße umzugehen ... und das möglichst rasch. Aktuell sehe ich da eine sehr große Disbalance. Vielleicht ist ein guter Start, dass wir KI als Ausgangspunkt und nicht als Endpunkt verwenden. Und uns immer wieder fragen: Identifiziere ich mich eigentlich gerade mit dem, was ich hier tue, oder baue ich Wegwerfware?
Und ein Gedanke noch zum Schluss. Überlegt mal, warum ihr wirklich angefangen habt zu programmieren oder Testfälle zu entwickeln oder Architekturen zu entwerfen. Ich glaube, bei den meisten von uns war die Motivation: Ich kann hier etwas gestalten und es macht mir Spaß, etwas zu bauen. Sollten wir uns das wegnehmen?
Viele Grüße
Richard Seidl
