KI macht Entwickler schneller. Aber nicht automatisch besser.

Worum es geht: KI-Tools wie Claude Code beschleunigen die Softwareentwicklung tatsächlich – das ist messbar und real. Aber Schnelligkeit allein macht keine bessere Software. In diesem Artikel zeige ich aus 15 Jahren Praxis, wann KI in der Softwareentwicklung wirklich hilft, wann sie gefährlich wird, und warum der sinnvolle Einsatz von KI selbst eine Fähigkeit ist, die man lernen muss.

Wie dieser Artikel entstanden ist

Vor einigen Wochen habe ich auf LinkedIn einen Gedanken zur KI-Debatte geteilt, der mir wichtig war: „KI macht Entwickler schneller. Aber nicht automatisch besser." Der Post hat überraschend viele Reaktionen ausgelöst – sowohl von erfahrenen Kolleginnen und Kollegen, die mir voll zugestimmt haben, als auch von Einsteigern, die ehrlich gefragt haben: „Was meinst du damit konkret?"

Genau diese Frage verdient eine längere Antwort. Denn der Unterschied zwischen „schneller" und „besser" entscheidet darüber, ob die KI-Revolution für die Softwarequalität insgesamt ein Segen oder ein langsam wirkendes Gift wird. Und im Mittelstand, wo Software oft fünf bis zehn Jahre laufen muss, ist das keine theoretische Frage – das ist die wichtigste praktische Frage überhaupt.

Dieser Artikel ist meine ausführliche Antwort. Mit Beispielen aus meinem Alltag, ehrlichen Gedanken über Berufseinsteiger und einer klaren Position dazu, was sinnvoller KI-Einsatz wirklich bedeutet.

Der Hype ist real – und die Sorge auch

Fangen wir mit dem Offensichtlichen an: Die Produktivitätsgewinne durch KI in der Softwareentwicklung sind real. Sie sind keine Marketing-Erfindung. Wer behauptet, KI würde nichts bringen, hat entweder nicht systematisch ausprobiert oder verkauft etwas Eigenes, das gegen KI konkurriert.

Konkret sehe ich diese Bereiche, in denen KI heute zuverlässig Zeit spart:

Weniger Boilerplate-Code. Wer schon einmal eine neue REST-API aufgesetzt hat, kennt das Ritual: Routes definieren, Controller schreiben, Models anlegen, Validation, Error-Handling, Tests. Diese mechanische Arbeit kostet bei mir früher zwei bis vier Stunden pro Modul. Heute oft 30 Minuten plus eine halbe Stunde Review.

Schnellere Iterationen. Wenn ich eine bestimmte Logik implementieren will und unsicher bin, welcher Ansatz am elegantesten ist, bekomme ich von der KI in wenigen Minuten drei Varianten – die ich vergleichen kann. Das ersetzt nicht die Entscheidung, aber es beschleunigt das Vorab-Denken.

Effizientere Code-Reviews. Bei umfangreichen Pull-Requests lasse ich oft eine erste KI-Runde drübergehen, bevor ich selbst draufschaue. Sie findet die offensichtlichen Sachen – vergessene Null-Checks, ungenutzte Imports, inkonsistente Naming-Konventionen – und ich kann meine Aufmerksamkeit auf die wirklich wichtigen Fragen lenken.

Das ist real. Das ist ein Unterschied. Wer das ignoriert, hängt in zwei Jahren hinterher.

Aber jetzt kommt das große Aber.

Schnelligkeit ist nicht das, wofür Kunden bezahlen

Wenn ich mit Geschäftsführerinnen und IT-Verantwortlichen aus dem Mittelstand spreche, frage ich oft, was ihnen bei einem Software-Projekt am wichtigsten ist. Die Antworten lauten praktisch nie „dass es schnell fertig wird". Sie lauten:

• „Dass es funktioniert."
• „Dass wir es in fünf Jahren noch warten können."
• „Dass meine Mitarbeiter es tatsächlich nutzen."
• „Dass es zu unseren Prozessen passt."
• „Dass ich nicht in eine Sackgasse renne, aus der ich nur teuer wieder rauskomme."

Keine dieser Anforderungen lässt sich durch reine Schnelligkeit erfüllen. Sie alle hängen davon ab, ob die Software durchdacht ist – ob jemand mit Erfahrung die richtigen Entscheidungen über Architektur, Domänenmodellierung, langfristige Wartbarkeit und realistische Anforderungen getroffen hat.

Und genau da liegt die Tücke der KI: Sie löst nicht das Problem, das Kunden wirklich haben. Sie löst nur das Problem, das ich als Entwickler habe – nämlich schnell Code produzieren zu müssen. Wenn ich nicht aufpasse, baue ich mit KI viel schneller eine Lösung, die zu meinem Kunden nicht passt. Das ist keine Verbesserung. Das ist eine teurere Sackgasse.

KI als Sparringspartner, nicht als Generator

Für mich hat sich in den letzten Monaten eine ziemlich klare Arbeitsweise herauskristallisiert: Ich nutze KI nicht als Generator, sondern als Sparringspartner.

Was meine ich damit konkret? Hier ein typisches Beispiel.

Wenn ich vor einer Architektur-Entscheidung stehe – sagen wir, ich überlege, ob ich eine neue Domänen-Funktionalität als Service-Klasse oder als Domain-Event modelliere – dann frage ich die KI nicht: „Schreib mir die Service-Klasse." Sondern ich frage: „Hier ist das Problem und der Kontext. Welche Trade-offs sehe ich, wenn ich Variante A statt Variante B wähle? Was übersehe ich vielleicht?"

Was zurückkommt, ist nie eine fertige Antwort. Es ist eine strukturierte Analyse. Manchmal liefert sie mir einen Aspekt, an den ich nicht gedacht habe. Manchmal bestätigt sie meine Einschätzung und gibt mir mehr Sicherheit. Manchmal – und das ist auch okay – ist sie inhaltlich daneben, und dann lehne ich sie ab.

In all diesen Fällen ist die KI nicht der Entscheider. Ich bin der Entscheider. Sie ist der Sparringspartner, der mir hilft, schärfer zu denken.

Das ist eine völlig andere Nutzungsweise als „KI generiert den Code, ich übernehme ihn." Und es ist nach meiner Erfahrung die deutlich wertvollere.

Ein konkretes Beispiel aus meinem Alltag

Damit das nicht zu abstrakt bleibt – hier ein ganz normales Beispiel aus einer typischen Woche.

Ich arbeite an einer Webapp für einen mittelständischen Kunden. Es ist Mittwochvormittag, ich habe gestern Abend ein neues Feature implementiert. Bevor ich heute morgen das nächste Feature anfange, möchte ich, dass jemand über meinen gestrigen Code drüberschaut. Klassisch hieße das: Kollege fragen, der hat keine Zeit, später nochmal fragen, irgendwann am Nachmittag passiert ein hastiges Review.

Heute mache ich das so: Ich starte einen automatisierten KI-Review im Hintergrund. Die KI bekommt den Diff, einen kurzen Kontext-Hinweis („dies ist Teil einer Webapp für Lagerverwaltung, Datenmodell siehe X") und einen klaren Review-Auftrag („prüfe auf Sicherheits-Risiken, Performance-Engpässe, Lesbarkeit"). Während das läuft, hole ich mir einen Kaffee und plane das nächste Feature.

Wenn ich zurückkomme, liegen die Hinweise da. Drei Sicherheits-Vermutungen, eine Performance-Warnung, zwei Stilistik-Vorschläge. Ich gehe sie systematisch durch.

Zwei der Sicherheits-Vermutungen sind berechtigt – Stellen, die ich gestern Abend übersehen hatte. Eine ist daneben, weil sie den Kontext nicht erfasst hat (die fragliche Stelle wird nur in einem authentifizierten Bereich aufgerufen, der Hinweis ist also falsch). Die Performance-Warnung ist akademisch korrekt, in der Praxis aber irrelevant – bei unseren erwarteten Datenmengen kein Problem.

Was nehme ich mit? Drei konkrete Fixes, die ich sonst eventuell übersehen hätte. Zwei Vorschläge, die ich begründet ablehne – aber besser dafür, weil ich sie geprüft habe. Zeit: 25 Minuten, statt eines halbtägigen Codereview-Meetings.

Das ist KI als Sparringspartner. Nicht „mach meine Arbeit für mich", sondern „hilf mir, besser über meine Arbeit nachzudenken."

Wo KI auch heute noch versagt

Ehrlichkeit ist wichtig, gerade beim Thema KI. Hier die Stellen, an denen die heutigen Tools – Claude Code, ChatGPT, Cursor, GitHub Copilot – regelmäßig danebenliegen.

Komplexe Geschäftslogik

Wenn ein Kunde sagt: „Wir verrechnen Boni für Außendienstler nach folgender Logik – aber wenn der Kunde Konzernkunde ist, dann gilt etwas anderes, außer beim Sondersortiment, da haben wir eine alte Vereinbarung von 2019, die noch nachläuft", dann ist das genau die Art Komplexität, die in keiner KI-Trainingsdaten vorkommt. Sie ist firmenspezifisch, historisch gewachsen und voller stiller Annahmen, die niemand expliziert hat.

KI kann diese Komplexität nicht aus dem Nichts erfinden. Sie kann sie auch nicht durch Nachfragen klären – sie weiß nicht, was sie nicht weiß. Wenn ich solche Logik implementiere, brauche ich Stunden mit dem Kunden, einen Stift, ein Whiteboard und Erfahrung darin, die richtigen Fragen zu stellen. Da hilft mir KI nicht. Da macht sie mich nur schneller, falsche Annahmen zu treffen – wenn ich nicht aufpasse.

Saubere Architektur über die ganze Codebasis

Architektur-Entscheidungen sind nie lokal. Wenn ich heute entscheide, eine bestimmte Funktion in einem Service statt im Controller zu implementieren, hat das Konsequenzen für Module, die ich vielleicht in einem Jahr noch baue. Die KI sieht aber immer nur einen begrenzten Kontext – die Datei, das Modul, vielleicht eine Handvoll umliegende Dateien. Sie hat keine Vorstellung davon, wie sich das Gesamtsystem in 18 Monaten entwickeln soll.

Das ist okay, solange ich das weiß. Wenn ich vergesse, dass die KI nicht „die Übersicht hat", übernehme ich Vorschläge, die lokal smart sind aber systemisch toxisch. Das ist eine der häufigsten Quellen für technische Schulden in KI-unterstützten Codebases – Architekturen, die aus tausend lokal sinnvollen Entscheidungen bestehen, aber als Ganzes nicht zusammenpassen.

Nachhaltige Entscheidungen

„Wir müssten eigentlich auf PostgreSQL 16 upgraden, aber unser Hoster unterstützt das erst Q3, und unser Backup-Tool ist auf Version 14 limitiert." Solche Entscheidungen kann KI nicht treffen. Sie kennt nicht die Hoster-Politik, nicht das Budget-Verhalten des Kunden, nicht die internen Prioritäten der IT-Abteilung. Sie kann technische Vorschläge machen – die in der konkreten Situation oft impraktikabel sind.

Hier braucht es Menschen mit Kontext. Idealerweise Entwickler, die seit Jahren beim Kunden sind und wissen, welche Kämpfe schon gefochten wurden.

Was mich am meisten beschäftigt: Berufseinsteiger

Wenn ich heute mit Studierenden der Hochschule Fulda oder jungen Berufseinsteigern spreche, erlebe ich eine Spaltung. Es gibt diejenigen, die KI als Werkzeug nutzen – sie probieren Vorschläge aus, lehnen sie ab, hinterfragen sie, lernen daraus. Und es gibt diejenigen, die KI als Krücke nutzen – sie generieren, übernehmen, ohne wirklich zu verstehen, was passiert.

Die zweite Gruppe macht mir Sorgen.

Nicht weil ich elitär gegen Berufseinsteiger bin. Im Gegenteil – ich war selbst einer, und ich war damals froh über jeden, der mir geholfen hat. Sondern weil das, was diese jungen Entwickler heute schreiben, lokal funktioniert, aber strukturell hohl ist. Sie bauen Systeme, die laufen – bis sie es nicht mehr tun. Und dann ist niemand da, der versteht, warum.

Stellt euch vor, ein junger Entwickler übernimmt einen KI-Vorschlag, der für seine konkrete Aufgabe perfekt aussieht. Er testet es, es funktioniert, er committet. Eine Woche später meldet ein Nutzer ein seltsames Verhalten. Der Entwickler schaut nach – und versteht den Code nicht mehr, den er selbst eingecheckt hat. Weil er ihn nie selbst gedacht hat.

Das ist nicht hypothetisch. Das passiert jetzt schon. Und es wird schlimmer werden, je „kompetenter" die KI-Vorschläge oberflächlich aussehen.

Mein Rat an Berufseinsteiger: Nutzt KI als Lehrer, nicht als Ersatz. Wenn ihr einen Vorschlag bekommt, fragt nach: „Warum ist das die richtige Lösung? Was wären Alternativen? Welche Trade-offs gibt es?" Übernehmt nichts, was ihr nicht erklären könnt. Und freut euch, wenn ihr von der KI lernt – das ist die eigentliche Chance dieser Technologie.

Sinnvoller KI-Einsatz ist selbst eine Fähigkeit

Hier kommt der Kern meiner These: Der sinnvolle Einsatz von KI in der Softwareentwicklung ist selbst eine Fähigkeit, die man lernen muss. Es ist nicht trivial. Es ist nicht selbstverständlich. Und es ist nicht jedem gegeben.

Was macht diese Fähigkeit aus?

Erstens: Wissen, was die KI gut kann und was nicht. Wer noch nicht erkennt, wann die KI gerade halluziniert, übernimmt halluzinierten Code. Das lernt man nur durch hunderte Stunden bewussten Vergleichens von KI-Vorschlägen mit der Realität.

Zweitens: Die richtigen Fragen stellen. Wer „schreib mir eine Login-Funktion" eingibt, bekommt etwas Generisches. Wer „in unserem Projekt nutzen wir Laravel 12, Datenbank ist PostgreSQL, Auth via JWT in httpOnly Cookies, hier ist das User-Model – schreib mir den Login-Endpoint passend dazu" eingibt, bekommt etwas Brauchbares. Der Unterschied ist Erfahrung im Beschreiben von Kontext.

Drittens: Bewusst entscheiden, wann man KI eben NICHT nutzt. Bei komplexer Geschäftslogik, bei Architektur-Entscheidungen, bei Kunden-Workshops, bei Code-Reviews die auch über Refactoring entscheiden – da arbeite ich bewusst ohne KI. Nicht aus Prinzip, sondern weil sie dort meinen Denkprozess stört statt fördert.

Viertens: Kritisch bleiben, auch wenn etwas gut aussieht. Der gefährlichste KI-Output ist nicht der offensichtlich falsche, sondern der oberflächlich plausible aber strukturell unpassende. Wer hier nicht kritisch ist, baut Code, der heute läuft und in einem Jahr unwartbar ist.

Diese vier Punkte zu beherrschen ist keine Frage von Talent. Es ist eine Frage von bewusstem Üben, von Reflexion, von Erfahrung. Und es ist das, was im Mittelstand-Kontext den Unterschied macht zwischen einem Anbieter, dem man vertrauen kann, und einem, der schnell scheinbare Wunder produziert.

Was das für Mittelstandsprojekte bedeutet

Wenn Sie als Geschäftsführerin oder IT-Verantwortliche eines mittelständischen Unternehmens überlegen, in Software zu investieren, ist die wichtige Frage nicht: „Setzt der Anbieter KI ein?" Die Antwort ist heute fast immer ja, und in zwei Jahren wird sie immer ja sein.

Die wichtige Frage ist: „Wie setzt der Anbieter KI ein, und was versteht er davon?"

Konkrete Indikatoren, an denen Sie das erkennen können:

Der Anbieter spricht offen über Grenzen. Wer behauptet, KI würde „alles" können oder „nichts" könne, sollten Sie skeptisch sehen. Realistische Anbieter haben eine differenzierte Sicht – sie können Ihnen Beispiele geben, wo KI ihnen geholfen hat, und Beispiele, wo sie ihnen NICHT geholfen hat.

Der Anbieter spricht über Code-Qualität, nicht nur Geschwindigkeit. Wenn die einzige KI-Verkaufspitch lautet „wir sind schneller", ist das ein Warnsignal. Fragen Sie konkret nach: „Wie stellen Sie sicher, dass KI-generierter Code Ihren Qualitätsstandards entspricht?" Eine ehrliche Antwort beinhaltet Code-Review-Prozesse, automatisierte Tests, manuelle Architektur-Kontrolle.

Der Anbieter hat eine Position zur Lehre. Wer KI als Werkzeug zur Lernbeschleunigung einsetzt – sowohl für sich selbst als auch für Junior-Entwickler – zeigt, dass er nachgedacht hat. Wer KI als „Magie" verkauft, hat es nicht.

Der Anbieter spricht über langfristige Wartbarkeit. Im Mittelstand laufen Systeme oft fünf bis zehn Jahre. Wenn der Anbieter nur darüber redet, wie schnell er JETZT fertig wird, aber nicht, wie wartbar das System in fünf Jahren ist, fehlt eine wichtige Dimension.

Bei Aburok versuchen wir, all diese Punkte in jedem Erstgespräch transparent zu machen. Wir nutzen KI bewusst, wir kennen ihre Grenzen, wir bauen weiterhin Software, die in fünf Jahren noch wartbar ist – auch wenn die einzelnen Code-Zeilen heute zum Teil mit KI-Unterstützung entstanden sind.

Mein persönliches Fazit nach mehreren Monaten

Wenn ich nach mehreren Monaten täglichen KI-Einsatzes eine Sache sagen müsste, dann diese: KI macht erfahrene Entwickler deutlich produktiver. Sie macht Berufseinsteiger gefährlich überheblich. Und sie verändert die Anforderungen an Softwarequalität auf eine Weise, die wir gerade erst zu verstehen beginnen.

Die Zukunft gehört nicht denen, die am meisten generieren – sondern denen, die am sorgfältigsten denken. Es gehört nicht denen, die KI-Workflows am elegantesten aufsetzen – sondern denen, die wissen, wann sie die Tools weglegen müssen. Und es gehört nicht denen, die ihre Stundenzahl maximieren – sondern denen, die ihre Aufmerksamkeit auf das richtige lenken können.

Wie sich unser Arbeitstag durch Claude Code verändert hat und warum wir die KI-Ersparnis an unsere Kunden weitergeben, lesen Sie in Claude Code im Alltag. Dieser Artikel hier ist die andere Hälfte des Bildes: Geschwindigkeit allein reicht nicht. Es braucht Urteilsvermögen, Erfahrung und die Bereitschaft, sich aktiv mit der Technologie auseinanderzusetzen.

Wenn Sie konkret über Ihr Projekt sprechen wollen

Wir bauen bei Aburok Softwareentwicklung individuelle Software für mittelständische Unternehmen – mit KI-Unterstützung dort, wo sie hilft, ohne KI dort, wo sie hindern würde, und immer mit menschlichem Lektorat und einer klaren Verantwortung für langfristige Qualität.

Wenn Sie ein konkretes Projekt im Kopf haben – eine eigene Webapp, eine Modernisierung, eine Schnittstelle oder eine Prozessautomatisierung – sprechen wir gerne darüber. Das Erstgespräch ist kostenfrei und unverbindlich. Wir hören zu, denken mit und sagen ehrlich, ob und wie wir helfen können.

→ Beratungsgespräch vereinbaren