KI-Coding-Tools verändern die Landschaft der Softwareentwicklung grundlegend. Entwickler:innen verlassen sich heute auf Tools wie GitHub Copilot, Amazon CodeWhisperer und ChatGPT, um Code zu generieren, Bugs zu beheben, Tests zu erstellen und Routineaufgaben zu beschleunigen. Code, der früher Stunden dauerte, kann heute in Minuten erstellt werden; manchmal in Sekunden. Prompting wird rasch zu einer zentralen Fähigkeit für Entwickler:innen.
KI ist gekommen, um zu bleiben. Das Versprechen ist unbestreitbar: höherer Output, schnellere Lieferung und weniger repetitive Aufgaben. Doch mit diesem Geschwindigkeitssprung stellt sich eine tiefere Frage:
Bauen wir gut — oder nur schnell?
Dieser Artikel untersucht diese Frage aus der Perspektive von Software Craftsmanship und bietet eine pragmatische Sicht darauf, wie wir KI nutzen können, ohne die Prinzipien zu opfern, die großartige Software möglich machen.
Echte Produktivität in der Softwareentwicklung bedeutet nicht, wie viele Codezeilen produziert werden oder wie schnell sie getippt werden. Es geht darum, wie wirksam Entwickler:innen sinnvolle Probleme lösen, sicherstellen, dass ihre Lösungen korrekt sind, und die Codebasis in einem besseren Zustand hinterlassen, als sie sie vorgefunden haben.
Produktivität ist die Fähigkeit, kontinuierlich wertvolle, wartbare Software mit minimaler Reibung, Nacharbeit oder Risiko zu liefern. Das erfordert weit mehr als schnellen Output. Es verlangt Klarheit, Korrektheit und Änderbarkeit.
KI gibt uns einen leistungsstarken neuen Motor. Aber Produktivität braucht weiterhin ein Lenkrad. Wenn Geschwindigkeit mit Fortschritt verwechselt wird, liefern Teams am Ende mehr minderwertigen Code aus, erzeugen mehr Nacharbeit und verstärken langfristige Risiken.
Tatsächlich erleben viele Teams inzwischen ein Paradox:
Features werden schneller geliefert …
… aber Bugs, Regressionen und Entropie nehmen zu.
Das liegt nicht daran, dass KI schlecht im Coden ist. Es liegt daran, dass Codequalität, Modularität, Testbarkeit und Teamwissen systemische Faktoren sind, die KI nicht automatisch berücksichtigt.
Und genau darum geht es:
Softwareproduktivität ist eine Eigenschaft des Systems, nicht der Geschwindigkeit einzelner Entwickler:innen.
Code schneller zu generieren reduziert nicht zwangsläufig Lieferzeit, Wartungsaufwand oder Nacharbeit. Wenn der generierte Code nicht auf die fachliche Absicht ausgerichtet oder schlecht designt ist, kann er nachgelagerte Kosten erhöhen. Geschwindigkeit ist nur dann produktiv, wenn sie Klarheit, Korrektheit und Anpassungsfähigkeit unterstützt.
In Verbindung mit starken Engineering-Prinzipien kann KI nicht nur Geschwindigkeit, sondern auch Wirksamkeit verstärken und Teams dabei helfen, bessere Software schneller zu liefern.
Wenn Menschen über Produktivität in der Softwareentwicklung sprechen, denken sie oft daran, wie schnell Entwickler:innen Code schreiben können. Forschung und Praxiserfahrung zeichnen jedoch ein ganz anderes Bild.
Laut einer Studie von Microsoft Research aus dem Jahr 2019 mit dem Titel „Today was a Good Day: The Daily Life of Software Developers“ und auf Basis von Analysen anderer zitierter Studien ist es plausibel zu schätzen, dass weniger als 25 % der Zeit von Entwickler:innen mit dem Editieren von Quellcode verbracht wird. Der Großteil entfällt auf Aktivitäten wie Code lesen, durch die Codebasis navigieren, Systemverhalten verstehen, Meetings, Anforderungen verfeinern usw. Zwar kann KI auch bei diesen Aufgaben helfen, aber sie ersetzt nicht das tiefe Verständnis der internen Struktur, das notwendig ist, um Design, Absicht und Komplexität der Codebasis wirklich zu verstehen.
Das erzählt eine klare Geschichte: Der Engpass in der Softwareentwicklung ist nicht, wie schnell Code getippt werden kann, sondern wie schnell Entwickler:innen verstehen können, was geändert werden muss und wo.
Und genau hier wird es kompliziert.
Selbst wenn KI die Codegenerierung beschleunigt, müssen Entwickler:innen weiterhin durch das bestehende System navigieren und darüber nachdenken. Ist dieses System jedoch unübersichtlich, mit schlechten modularen Grenzen, inkonsistenter Benennung, duplizierter Logik oder fehlenden Tests, steigen die Kosten des Verstehens erheblich.
KI beseitigt diese Kosten nicht. In vielen Fällen verstärkt sie sie.
Das Problem ist nicht, wie schnell wir neuen Code schreiben können, sondern wie schnell wir den Code, den wir bereits haben, sicher ändern und verstehen können.
Was macht dieses Verständnis schwierig?
Schlechte Modularisierung: Wenn Code über schlecht definierte oder überlappende Domänen verstreut ist, müssen Entwickler:innen Logik über mehrere Dateien oder Services hinweg verfolgen, um Verhalten zu verstehen.
Inkonsistente oder vage Benennung: Schlechte Namen auf jeder Ebene — Packages, Klassen, Funktionen, Variablen — erhöhen die mentale Belastung, die nötig ist, um zu entschlüsseln, was Code tut.
Hohe Komplexität: Tief verschachtelte Logik, lange Methoden oder verworrene Bedingungen erhöhen sowohl zyklomatische als auch kognitive Komplexität und machen Code schwieriger lesbar und weniger sicher änderbar.
Mangelnde Testabdeckung: Ohne aussagekräftige, aktuelle Tests ist es schwierig, das beabsichtigte Verhalten zu verstehen oder zu wissen, ob eine Änderung etwas kaputt macht.
Ausführliche oder qualitativ schlechte Tests: Ironischerweise können schlechte Tests schlimmer sein als keine Tests; sie erzeugen Rauschen und falsches Vertrauen statt Klarheit und Sicherheit.
Duplizierung: Copy-paste-Logik, die über die Codebasis verteilt ist, erfordert mehrere Änderungen, um ein einziges Problem zu beheben, und erhöht dadurch das Risiko von Regressionen und verschwendetem Aufwand.
Diese Probleme verstärken sich, wenn mehrere Entwickler:innen, möglicherweise mit KI-Tools, Code mit hoher Geschwindigkeit generieren, ohne die zugrunde liegende Struktur zu verbessern. Mehr Code bedeutet nicht mehr Wert, wenn das umgebende System schwieriger zu verstehen und weiterzuentwickeln wird. Das sind nicht nur Fragen der Codehygiene. Sie sind systemische Produktivitätsblocker. Und wenn sie nicht adressiert werden, hilft keine noch so große KI-Beschleunigung. Im Gegenteil: Sie wird Teams wahrscheinlich nur unter noch mehr Code begraben, den sie nicht vollständig verstehen.
In diesem Kontext sind Software-Craftsmanship-Praktiken wie modulares Design, Disziplin bei der Benennung und Clean-Code-Prinzipien keine Luxusgüter, sondern Mechanismen zur Zeitersparnis. Sie reduzieren die kognitive Reibung, die Entwickler:innen täglich erleben, und erhöhen den ROI jeder Minute, die mit dem Navigieren oder Ändern einer Codebasis verbracht wird.
Tippen ist nicht der Ort, an dem Entwickler:innen die meiste Zeit verbringen. Stattdessen verbringen sie diese Zeit mit Lesen, Verstehen, Beheben, Klären und Anpassen von Code. Je schwieriger Code zu lesen und zu durchdenken ist, desto länger dauert es, etwas Neues zu bauen. Die Generierung zu beschleunigen, ohne die Struktur zu verbessern, macht zukünftige Arbeit nur langsamer und riskanter.
KI kann Aufwand drastisch reduzieren, aber nur dann, wenn sie hilft zu klären und zu vereinfachen, nicht zu verschleiern. Craftsmanship stellt sicher, dass Beschleunigung nicht auf Kosten des Verständnisses geht.
Programmieren ist eine der präzisesten Kommunikationsformen, an denen Menschen beteiligt sind. Anders als natürliche Sprache, in der Mehrdeutigkeit, Metaphern und Nuancen erwartet werden, muss Quellcode explizit, eindeutig und logisch konsistent sein. Jedes Zeichen zählt. Deshalb war der Übergang von menschlicher Absicht zu funktionierender Software schon immer herausfordernd — und genau dort stößt generative KI auf ihre größte Reibung.
Large Language Models, kurz LLMs, wie Copilot und ChatGPT sind darauf ausgelegt, plausible Textsequenzen vorherzusagen und zu generieren, einschließlich Code. Die Eingaben, die sie erhalten — unsere Prompts — sind jedoch in derselben unpräzisen, unvollständigen natürlichen Sprache geschrieben, die wir im Gespräch verwenden. Selbst wenn Entwickler:innen ein klares Ziel haben, fehlt dem Prompt, den sie schreiben, oft Kontext, Klarheit oder Präzision. Und schlimmer noch: Die KI greift möglicherweise auf eine Codebasis zurück, die bereits schlecht strukturiert ist.
Dadurch entsteht nun eine Situation, in der:
Entwickler:innen vage Prompts auf Basis eines unvollständigen Verständnisses von Code oder System schreiben.
KI-generierter Code durch minderwertige Muster in der umgebenden Codebasis oder in öffentlichen Trainingsdaten beeinflusst werden kann.
Der generierte Code akzeptiert und gemergt wird, manchmal ohne klares Verständnis davon, was er tut oder ob er Inkonsistenzen, technische Schulden oder subtile Bugs einführt.
Diese Feedbackschleife kann die Systemqualität schnell verschlechtern, insbesondere wenn Codebasen keine starke semantische Struktur haben, wie eine Studie der Stanford University zeigt. Ein schlecht modularisiertes System mit schwachen Domänengrenzen, unklarer Benennung und inkonsistenten Architekturmustern bietet einem LLM wenig Orientierung. Die KI hat keinen Geschäftskontext, und ihre einzige Referenz ist der vorhandene Code, der selbst ein Flickenteppich inkonsistenter Praktiken sein kann.
Ohne solide Grundlagen in Softwaredesign und Modularisierung neigen KI-Tools dazu, bestehende Schwächen in der Codebasis zu verstärken. Zum Beispiel:
Eine aufgeblähte Klasse wird noch größer.
Eine schlecht benannte Methode wird an anderer Stelle kopiert und angepasst.
Eine fehlende Abstraktion bleibt fehlend und wird wiederholt über verschiedene Dateien hinweg dupliziert.
In diesem Szenario wird Software Craftsmanship noch wichtiger, nicht weniger. Gut modularisierter, gut benannter und gut getesteter Code hilft nicht nur Menschen, sich im System zurechtzufinden, sondern gibt auch KI-Tools bessere Muster, mit denen sie arbeiten können, wie dieselbe Studie der Stanford University zeigt. Eine Änderung innerhalb eines klar definierten Moduls mit guter Testabdeckung zu prompten, führt deutlich wahrscheinlicher zu korrektem, wartbarem Code.
LLMs bewegen sich in einer Grauzone zwischen unscharfer Sprache und deterministischem Code. Wenn der bestehende Code schlecht und die Prompts vage sind, werden selbst die leistungsstärksten Modelle minderwertige Lösungen generieren. Schlechter Code führt tendenziell zu noch mehr schlechtem Code.
Craftsmanship bringt die Präzision, die KI braucht. Wenn KI das Elektrowerkzeug ist, dann ist Software Craftsmanship der Bauplan. Ohne Letzteres generieren wir Code nur schneller, nicht besser.
Eine oft übersehene Folge generativer KI in der Softwareentwicklung ist die Beschleunigung von Wissensverlust.
Traditionell haben Entwickler:innen beim Schreiben eines Stücks Code Zeit damit verbracht, die Logik zu durchdenken, Designentscheidungen zu treffen, Dinge zu benennen und zu verstehen, wie alles ins System passt. Dieser Prozess war manchmal langsam, half Entwickler:innen aber dabei, die Geschäftsregeln, technischen Einschränkungen und Trade-offs hinter dem Code, den sie schrieben, zu verinnerlichen.
Wenn KI diesen Code jedoch in Sekunden generiert, werden Entwickler:innen zu passiven Editor:innen statt zu aktiven Autor:innen. Das mentale Modell und das tiefe Verständnis, das aus dem Ringen mit einem Problem entsteht, fehlen oft.
In einem unserer jüngsten Coaching-Engagements reichte ein Entwickler einen großen Pull Request mit Änderungen an Dutzenden Dateien ein. Als er gebeten wurde, die Geschäftslogik hinter der Änderung zu erklären oder wie bestimmte Edge Cases behandelt wurden, war die Antwort verblüffend: „Ich bin mir nicht sicher. Ich müsste noch einmal in den Code schauen.“ Dabei hatte er ihn gerade „geschrieben“. In Wirklichkeit hatte die KI den Großteil der Änderungen generiert, und der Entwickler hatte lediglich gepromptet, kopiert, eingefügt und leicht editiert.
Das ist kein Einzelfall. Wir sehen ein wachsendes Muster:
Entwickler:innen können ihren eigenen Code nicht mehr erklären.
Codebasen wachsen schneller, als Teams sie verstehen können.
Wissen wird nicht übertragen, sondern an das Tool ausgelagert.
Noch schlimmer: Das geschieht nicht nur auf individueller Ebene. In modernen Organisationen sind Systeme oft groß und verteilt, gebaut von mehreren Entwickler:innen, die parallel arbeiten, häufig über mehrere Microservices hinweg. Jede:r Entwickler:in bringt ein anderes Verständnis des Systems, der Domäne und guter Designpraktiken mit. Ihre Prompts variieren. Ihr Kontext unterscheidet sich. Und das Einzige, woran sich die KI orientieren kann, ist die Codebasis, die möglicherweise bereits inkonsistent oder schlecht strukturiert ist.
Das Ergebnis? Ein Durcheinander aus überlappender Logik, dupliziertem Aufwand, divergierenden Implementierungen und semantischer Drift über Services hinweg. Eine einzelne KI-generierte Änderung kann, wenn sie nicht sorgfältig überprüft und verstanden wird, subtile Inkonsistenzen einführen, die sich durch das System fortpflanzen. Wenn sich diese ansammeln, verbringen Teams mehr Zeit damit, die Absicht hinter Code rückzuentwickeln, den sie nie vollständig verstanden haben.
Software Craftsmanship bietet ein Gegengewicht. Es schätzt gemeinsames Verständnis, semantische Klarheit und bewusstes Design. In einer immer schnelllebigeren Welt schützen diese Prinzipien langfristige Wartbarkeit und die Wirksamkeit von Entwickler:innen. Ohne sie bauen wir Systeme, die wir nicht vollständig verstehen, mit einer Geschwindigkeit, mit der wir nicht mithalten können.
Wenn Entwickler:innen große Mengen Code generieren, ohne ihn zu verstehen, oder ohne die Designabsicht zu besprechen, erodiert teamweites Wissen. Code wird zu einer Black Box, sogar für diejenigen, die ihn „geschrieben“ haben. Mit der Zeit entwickeln sich Systeme auf unvorhersehbare und riskante Weise weiter.
Craftsmanship hilft Teams, nah am Code zu bleiben, und stellt sicher, dass KI die Lieferung beschleunigt, ohne Entwickler:innen von dem zu entkoppeln, was gebaut wird.
„Übermäßige Abhängigkeit von KI-Unterstützung könnte zentrale Engineering-Kompetenzen untergraben.“
Code Review war schon immer eines der wichtigsten Quality Gates und eine der wichtigsten Aktivitäten zum Wissensaustausch in einem professionellen Softwareentwicklungsprozess. Ein gutes Review entdeckt Designfehler, Bugs und Missverständnisse, bevor sie die Produktion erreichen. Damit Reviews jedoch wirksam sind, müssen die zu überprüfenden Änderungen verständlich, kontextualisiert und — entscheidend — klein genug sein, um darüber nachdenken zu können.
KI-generierter Code bringt dieses Gleichgewicht durcheinander.
Entwickler:innen, ausgestattet mit schnellen, leistungsstarken Assistenten, können heute in Minuten umfassende Änderungen über Dutzende Dateien hinweg vornehmen. Was früher Tage sorgfältigen Nachdenkens, Designs und Iterierens gebraucht hätte, kann heute mit wenigen Prompts generiert und in die Codebasis eingefügt werden. Die Geschwindigkeit ist berauschend, bringt aber ernsthafte Nachteile mit sich:
Die Größe von Pull Requests wächst drastisch.
Die Komplexität von Änderungen nimmt zu, oft mit inkonsistenten Designentscheidungen über die geänderten Dateien hinweg.
Reviewer: innen sind überfordert und können nicht sinnvoll beurteilen, was geändert wurde und warum.
Die natürliche Reaktion auf einen riesigen Pull Request? Überfliegen — oder schlimmer noch: Abnicken.
Und wenn Reviews oberflächlich werden, sinkt die Qualität. Bugs rutschen durch. Inkonsistenzen wachsen. Design-Schulden häufen sich an. Schlimmer noch: Die Chance auf gemeinsames Lernen verschwindet. Code Review geht nicht nur um Freigabe; es geht darum, gemeinsames Verständnis im Team aufzubauen.
Das ist nicht nur ein KI-Problem; große, nicht sinnvoll überprüfbare Pull Requests waren schon immer ein Anti-Pattern. Aber die schnelle Codegenerierung moderner Tools hat das Problem verschärft. Es ist heute einfacher denn je, gesunde Entwicklungsdisziplin im Namen der Geschwindigkeit zu umgehen.
Software Craftsmanship fordert einen anderen Ansatz:
Häufige, kleine, klar abgegrenzte Commits.
Bewusste Designentscheidungen, nicht nur funktionale Outputs.
Sinnvolle Reviews, bei denen Autor:in und Reviewer:in gemeinsam lernen und besser werden.
Pair Programming, bei dem Wissensaustausch sowie bessere Benennungs- und Designentscheidungen ein direktes Nebenprodukt sind, minimiert den Bedarf an formalen Code Reviews.
KI kann diesen Prozess unterstützen, indem sie Boilerplate generiert, Verbesserungen vorschlägt und einfache Aufgaben beschleunigt, aber nur, wenn wir Kontrolle über Tempo und Umfang der Änderungen behalten. Andernfalls riskieren wir, Entwicklung in ein schnell laufendes Förderband ungeprüften Codes zu verwandeln, bei dem die Kosten jedes Fehlers erst Monate später sichtbar werden.
KI macht große, weitreichende Änderungen einfach. Doch diese Änderungen zu prüfen und zu validieren, besonders wenn sie mehrere Dateien oder Services betreffen, wird schwieriger. Wenn Reviews oberflächlich sind oder ganz übersprungen werden, leidet die Codequalität, und Bugs rutschen durch.
Bewusst eingesetzt kann KI dennoch kleine, sinnvolle Änderungen unterstützen. Entwickler:innen können in kleinen Schritten prompten und dabei Reviewbarkeit und Modularität bewahren.
Hinweis: Wir evaluieren derzeit KI-Code-Review-Tools, um PRs anhand unserer eigenen Qualitätsrichtlinien für Code und Design zu überprüfen. Erste Tests sind sehr vielversprechend. Mehr dazu in einem zukünftigen Beitrag.
In der Softwareentwicklung ist Struktur Bedeutung.
Wir verlassen uns auf semantische Modularisierung — klare Architekturgrenzen, aussagekräftige Benennung und klar definierte Verantwortlichkeiten — um Systeme verständlich und wartbar zu machen. Wenn eine Codebasis semantisch strukturiert ist, können Entwickler:innen schnell kritische Fragen beantworten:
Was macht dieses Modul? Welche Geschäftsdomäne repräsentiert es? Wohin gehört diese Änderung?
Leider sind die meisten Codebasen bereits weit vom Ideal entfernt. Semantische Grenzen — oder Bounded Contexts, wenn man die Terminologie von Domain-Driven Design, kurz DDD, bevorzugt — sind unscharf oder nicht vorhanden. Geschäftslogik ist über Schichten und Services verstreut. Benennung ist inkonsistent oder generisch. Modularisierungsentscheidungen, falls es sie überhaupt gab, sind unter Jahren technischer Schulden begraben.
Und nun lernen und bauen KI-Tools auf diesem Durcheinander auf.
Ohne eine solide semantische Grundlage hat selbst der leistungsstärkste KI-Assistent Schwierigkeiten, hochwertige Lösungen zu generieren. Stattdessen verstärkt er bestehende Inkonsistenzen, führt zusätzliche Duplizierung ein und vergrößert bereits überdimensionierte Klassen und Methoden. Jede neue Änderung nagt an der Klarheit.
Semantische Verschlechterung beschleunigt sich mit der Zeit:
KI-generierte Änderungen basieren auf dem verfügbaren Kontext, oft einer schlecht strukturierten Codebasis.
Unterschiedliche Entwickler:innen liefern unterschiedliche Prompts, basierend auf ihren eigenen mentalen Modellen.
KI-generierter Code über Services oder Repositories hinweg führt zu Namenskollisionen, duplizierter Logik und divergierenden Implementierungen — einer Form semantischer Drift, die große Systeme schwerer kohärent weiterentwickelbar macht.
Was entsteht, ist ein System, das technisch funktioniert, aber konzeptionell inkohärent ist; ein Flickenteppich aus Ideen, Stilen und Annahmen. Es zu verstehen wird mit jeder neuen Zeile schwieriger.
Craftsmanship hingegen stellt Semantik ins Zentrum:
Code sollte Absicht ausdrücken.
Module sollten Geschäftsfähigkeiten und Änderungsgrenzen widerspiegeln.
Namen sollten Zweck offenlegen, nicht nur Implementierung.
Wenn wir Semantik verlieren, verlieren wir genau die Dinge, die Veränderung sicher, schnell und kosteneffizient machen. KI kann hier helfen, aber nur, wenn sie von Entwickler:innen angeleitet wird, die semantische Grenzen verstehen und mit Absicht prompten können. Die Kombination aus KI-Geschwindigkeit und dem Designbewusstsein von Software Craftsmanship kann Teams helfen, Bedeutung und Struktur in großem Maßstab zu bewahren.
Eine der wirkungsvollsten Praktiken im Software Craftsmanship ist Test-Driven Development, kurz TDD — nicht nur, um Korrektheit sicherzustellen, sondern auch, um Design zu leiten. Mit einem Test zu beginnen hilft Entwickler:innen, Erwartungen zu klären, komplexes Verhalten herunterzubrechen und saubereren, modulareren Code zu produzieren. Gute Tests dienen sowohl als Dokumentation als auch als Design-Feedback.
TDD geht nicht nur um Korrektheit, sondern darum, besseren Code zu schreiben.
KI verändert, wie wir Code schreiben, und damit auch, wie wir Tests schreiben. Viele Entwickler:innen generieren heute zuerst Produktionscode und bitten KI anschließend, Tests dafür zu erstellen. Das ist bequem, kehrt aber den Fluss der Absicht um. Statt dass Tests Verhalten definieren, werden sie zum Gummistempel für das, was der Code aktuell tut — selbst wenn es falsch, ineffizient oder nicht auf Geschäftsziele ausgerichtet ist.
Das stellt Testing auf den Kopf:
Tests passen sich dem Code an, statt dass sich der Code den Tests anpasst.
Bugs und Designfehler werden zementiert, wobei Tests das Problem verstärken, statt es zu verhindern.
Testabdeckung kann beeindruckend aussehen, aber der Wert dieser Tests ist oft gering.
Wenn Tests brechen, bitten Entwickler:innen die KI, sie zu reparieren, oft ohne das zugrunde liegende Problem zu verstehen.
Wir sehen zunehmend Test-Suites voller:
Schwacher oder redundanter Assertions
Mengen an dupliziertem Test-Setup und duplizierten Assertions für kleine Verhaltensvariationen
Tests, die Absicht oder Edge Cases nicht klären
Ausführlichem Code, der schwer zu lesen oder zu warten ist
Gleichzeitig kann KI beim Testing ein starker Verbündeter sein, wenn sie richtig angeleitet wird. Entwickler:innen können eine TDD-Denkweise nutzen, um KI strukturierter zu prompten. Statt nach „Code, der X tut“ zu fragen, können sie der KI den Gesamtkontext geben und dann in kleinen Schritten arbeiten, wobei sie für jeden Schritt beschreiben, welches Verhalten ein bestimmtes Modul zeigen soll, welche Einschränkungen gelten und welche Designrichtlinien relevant sind. Entwickler:innen können sogar sehr präzise bei den erwarteten Namen von Klassen, Methoden, Parametern und Rückgabetypen sein. Anschließend können sie die verschiedenen Szenarien — Testvariationen — beschreiben, die sie für dieses Verhalten wollen, von einem Sunny-Day-Szenario bis zu einer Liste von Edge Cases. Sie können KI auch bitten zu prüfen, ob Testszenarien fehlen oder ob es Schwachstellen in ihrem Design gibt. Selbst wenn die KI zuerst Code generiert, hilft die Denkweise hinter TDD weiterhin dabei, bessere Prompts, bessere Designs und nützlichere Tests zu formulieren.
Einige Teams bitten KI sogar, zuerst den Test zu schreiben oder einen bestehenden Test zu verfeinern, bevor mit dem Coding begonnen wird. Dieser Ansatz entwickelt sich noch, weist aber auf eine wertvolle Zukunft hin: KI als Designpartner, nicht nur als Codegenerator.
Am Ende geht es beim Testing nicht nur darum, Korrektheit zu validieren, sondern darum, Qualität zu schützen. Je stärker wir KI als Werkzeug verstehen, das menschliches Urteilsvermögen erweitert, desto besser können wir den Kern von Craftsmanship bewahren, selbst wenn wir schneller und in größerem Maßstab bauen als je zuvor.
KI revolutioniert, wie wir Code schreiben, aber ohne Orientierung kann sie genau die Eigenschaften untergraben, die Software wertvoll machen.
Hier kommt Software Craftsmanship ins Spiel.
Craftsmanship bedeutet nicht, sich Veränderung zu widersetzen oder die Vergangenheit zu romantisieren. Es geht darum, zeitlose Prinzipien hochzuhalten, die sicherstellen, dass Software ein Vermögenswert bleibt und keine Belastung wird — unabhängig davon, wie sie gebaut wird.
Im Kern ist Craftsmanship ein Commitment zu:
Gut gemachter Software — Code, der klar, testbar, wartbar und auf Geschäftsanforderungen ausgerichtet ist.
Professionalität — Praktiken, die langfristige Nachhaltigkeit, Teamwachstum und geschäftliche Agilität sicherstellen.
Produktive Partnerschaften — zwischen Entwickler:innen und Stakeholdern, getragen von Vertrauen und gemeinsamem Verständnis.
Diese Prinzipien sind im KI-Zeitalter wichtiger denn je.
Large Language Models verstehen dein Geschäft nicht. Sie interessieren sich nicht für deine Architektur. Sie erkennen die Trade-offs nicht, die du eingehst. Ohne durchdachte Prompts und hochwertigen Kontext generieren sie schnell plausiblen Code, der ebenso gut langfristige Reibung erzeugen kann wie kurzfristigen Fortschritt.
Software Craftsmanship hilft, indem es:
Die Rolle von KI einordnet: nicht als autonome Coderin, sondern als leistungsstarke Assistentin, die geführt werden muss.
Absicht betont: und sicherstellt, dass jede Änderung Modularität, Klarheit und geschäftliche Bedeutung stärkt.
Korrektheit absichert: indem Tests, Design Thinking und Review in den Workflow eingebettet werden.
Entropie verlangsamt: durch konsistente Praktiken, Benennungskonventionen und architektonische Disziplin.
Am wichtigsten ist: Craftsmanship nimmt KI an und hält gleichzeitig Standards hoch. Es erkennt an, dass Tippen nie der Engpass war; Verständnis, Entscheidungsfindung und Qualität waren es. KI kann helfen, Lieferung zu beschleunigen, aber nur, wenn das Fundament solide ist.
Das ist die Herausforderung und die Chance für heutige Softwareteams:
Nutzt KI, um schneller zu werden — aber stellt sicher, dass ihr in die richtige Richtung geht.
Software Craftsmanship stellt sicher, dass euer Code nicht nur schnell geliefert wird, sondern über die Zeit wertvoll bleibt.
KI transformiert die Landschaft der Softwareentwicklung. Sie hilft uns, schneller zu coden, das Alltägliche zu automatisieren und Lösungen zu erkunden, die wir allein vielleicht nicht in Betracht gezogen hätten.
Aber Geschwindigkeit ist nicht dasselbe wie Produktivität. Und Volumen ist nicht dasselbe wie Wert.
Wenn wir KI blind annehmen, riskieren wir, unsere Systeme mit schwer wartbarem, entkoppeltem Code zu fluten — schnell generiert, schlecht verstanden und halbherzig reviewed.
Was wir jetzt brauchen, ist Intentionalität. Eine Denkweise, die Klarheit, Struktur und kontinuierliche Verbesserung schätzt. Ein Commitment zu Praktiken, die geschäftliche Agilität bewahren und nicht nur kurzfristige Lieferung beschleunigen.
Das ist die Rolle von Software Craftsmanship im KI-Zeitalter. Nicht Veränderung zu verhindern, sondern sie zu leiten. Bessere Fragen zu stellen. Bessere Grenzen zu setzen. Sicherzustellen, dass die Software, die wir bauen, robust, verständlich und anpassungsfähig bleibt, selbst wenn sich die Werkzeuge, die wir verwenden, weiterentwickeln.
Craftsmanship macht KI zu einem mächtigen Verbündeten. Nicht indem wir Kontrolle abgeben, sondern indem wir den Standard dafür erhöhen, was „gut“ bedeutet, und sicherstellen, dass jede Codezeile — ob von KI oder Menschen geschrieben — zum langfristigen Erfolg beiträgt.
Die Zukunft der Software wird nicht von KI allein geschrieben, sondern von denen, die wissen, wie man sie mit Craft einsetzt.
KI ist der Motor. Craftsmanship ist der Kompass.
Möchtest du wissen, ob deine Organisation KI-ready ist? Entdecke unser Data & AI Readiness Assessment, das eine klare, tiefgehende und unabhängige Expertenanalyse sowie Empfehlungen bietet, um deine Datenstrategie weiterzuentwickeln und die Einführung von KI-Technologien zu beschleunigen.