Claude Code: Hilfreich, aber kein Freifahrtschein

Ich nutze Claude Code täglich. Beim Aufsetzen meiner selbst gehosteten Infrastruktur, beim Schreiben von Gitea Actions Pipelines, beim Debuggen von Nginx-Konfigurationen um Mitternacht. Es ist ein mächtiges Werkzeug — und genau deshalb schreibe ich diesen Artikel.

Denn mächtige Werkzeuge erfordern Urteilsvermögen. Das war schon immer so. Und ich beobachte es in meinem Umfeld — in Gesprächen mit Freunden und Bekannten aus der Branche, in Community-Diskussionen, und wenn ich ehrlich bin: Ich bin selbst in diese Falle getappt. Der Hype um KI-Coding-Tools verdrängt genau diesen Gedanken. Schnell, unkritisch, begeistert — und dann irgendwann überrascht.

Dieser Artikel ist kein Anti-KI-Plädoyer. Es ist das Gegenteil: Ein Plädoyer dafür, diese Werkzeuge so zu nutzen, dass man langfristig von ihnen profitiert — ohne die Fehler zu machen, die teuer, peinlich, oder beides werden können.

💡 Die Frage ist nicht, ob KI-Tools nützlich sind. Die Frage ist: mit welchem Anspruch wir sie einsetzen.

Ein Blick zurück: Die Evolution der Qualitätssicherung

Softwareentwicklung war nie einfach. Aber sie ist mit jeder Generation mächtiger und komplexer geworden — und mit jeder Komplexitätsstufe hat die Branche gelernt, neue Sicherheitsnetze zu spannen. Nicht aus Bürokratie, sondern aus bitterer Erfahrung.

timeline
    title Evolution der Qualitätssicherung in der Softwareentwicklung
    1960s - 1970s : Code als Einzelarbeit
                  : Manuelle Tests
    1980s         : Code Reviews
                  : Erste formale QA-Prozesse
    1990s         : Unit Tests
                  : Integrationstests
                  : Peer Reviews
    2000s         : Architektur Reviews
                  : Penetration Tests
                  : Security by Design
    2010s         : CI/CD Pipelines
                  : Automatisierte Tests
                  : Quality Gates
                  : DevSecOps
    2020s         : KI-generierter Code
                  : → Neue Ebene der Absicherung nötig

Jede neue Mächtigkeit hat neue Qualitätssicherungsebenen hervorgebracht. Die Liste ist nicht vollständig — sie zeigt eine Auswahl der wichtigsten Meilensteine. KI ist Schritt N+1, nicht die Ausnahme.

Die frühen Jahre: Code als Einzelarbeit

In den Anfangsjahren der Programmierung war Code oft das Werk einzelner Personen. Ein Entwickler, ein Programm, ein Rechner. Fehler hatten überschaubare Konsequenzen — der Rechner war teuer, aber die Software war es nicht.

Das änderte sich, als Systeme in kritische Bereiche vordrangen.

Der Therac-25 ist eines der bekanntesten und tragischsten Mahnmale der Softwaregeschichte: ein computergesteuertes Strahlentherapiegerät, das zwischen 1985 und 1987 mindestens drei Patienten das Leben kostete und drei weitere schwer verletzte — tragischerweise nicht durch einen komplexen Algorithmus, sondern durch einen Race Condition Bug in der Steuersoftware, kombiniert mit dem bedauerlicherweise ersatzlosen Wegfall der Hardware-Sicherheitssperren der Vorgängermodelle. Die Entwickler hatten die Sicherheitsprüfung der Software übertragen, ohne die Software entsprechend rigoros zu testen.

Die Lektion: Mehr Mächtigkeit ohne mehr Qualitätssicherung ist ein Risiko, das sich irgendwann realisiert.

Die Antwort der Branche: Schicht für Schicht

Die Reaktion auf wachsende Komplexität war nie "weniger Kontrolle", sondern immer "bessere Kontrolle":

Code Reviews entstanden, weil vier Augen mehr sehen als zwei — und weil Code, den niemand außer dem Autor versteht, ein Wartungsproblem ist. Mit dem Aufkommen größerer Teams und verteilter Entwicklung wurden sie zum Standard.

Architektur Reviews kamen, als lokale Entscheidungen globale Konsequenzen bekamen. Eine Datenbankentscheidung in Modul A kann Modul B unbrauchbar machen — aber nur wenn niemand das Gesamtbild im Blick hat.

Unit Tests und Integrationstests entstanden, weil kein Mensch mehr den gesamten Codepfad eines modernen Systems im Kopf behalten kann. Sie sind kein Misstrauen gegenüber dem Entwickler — sie sind ein Netz unter dem Hochseilakt.

CI/CD-Pipelines schließlich automatisierten das, was zuvor manuelle Disziplin erforderte: jeden Commit bauen, testen, prüfen, bevor er in Produktion geht. Und mit Manual Approval Gates — wie ich sie in meiner eigenen Gitea Actions Pipeline einsetze — bleibt der Mensch der letzte Kontrollpunkt vor dem Deployment.

Jede dieser Entwicklungen war eine Antwort auf gestiegene Komplexität und Mächtigkeit. Mehr Möglichkeiten bedeuteten mehr Angriffsfläche für Fehler — also mehr Absicherung. Das ist keine Schwäche der Softwareentwicklung. Das ist ihre Reife.

graph TD
    A[Einzelentwickler\nEinfache Systeme] -->|wächst| B[Teams\nVerteilte Systeme]
    B -->|wächst| C[Kritische Infrastruktur\nKomplexe Architekturen]
    C -->|wächst| D[KI-generierter Code\nAutomatisierte Systeme]

    A -.->|erfordert| E[Manuelle Tests\nCode-Disziplin]
    B -.->|erfordert| F[Code Reviews\nArchitektur Reviews]
    C -.->|erfordert| G[Unit Tests\nCI/CD\nPenetration Tests]
    D -.->|erfordert| H[???\nNeue QS-Ebene]

Warum sollte KI plötzlich die Ausnahme sein?

Was Claude Code wirklich kann — und was nicht

Ich möchte fair sein, denn das schulde ich dem Werkzeug: Claude Code ist beeindruckend. Es versteht Kontext überraschend gut, schlägt idiomatischen Code vor, erklärt Zusammenhänge auf Anhieb, und hat mir beim Aufbau meiner Infrastruktur echte Stunden gespart. Das ist keine Übertreibung.

Aber aus der täglichen Nutzung kenne ich auch die Schattenseiten — und die sollte man kennen, bevor man die Kontrolle abgibt.

Selbstbewusstsein ohne Absicherung

Claude Code formuliert Antworten in einem Ton, der Kompetenz signalisiert. Auch dann, wenn die Antwort falsch ist.

Ein erfahrener Kollege zögert, wenn er unsicher ist. Ein Junior-Entwickler fragt nach. Ein Compiler gibt eine Fehlermeldung aus. Claude Code — und KI-Tools generell — tun das nicht immer. Sie produzieren plausibel klingende Antworten mit einer Selbstsicherheit, die nicht ihrer tatsächlichen Zuverlässigkeit entspricht.

Das ist das subtilste, aber gefährlichste Charakteristikum dieser Werkzeuge: Nicht dass sie falsch liegen — das tun Menschen auch. Sondern dass sie es nicht wissen. Kein Zögern, kein Nachfragen, keine Fehlermeldung. Der Fehler wird erst sichtbar, wenn jemand hinterfragt — und das erfordert eigene fachliche Kompetenz, um überhaupt die richtigen Fragen stellen zu können.

Halluzinierte APIs und Libraries

In meiner Arbeit mit Claude Code ist mir mehrfach aufgefallen, dass Funktionen oder Parameter referenziert wurden, die in der genannten Library-Version so nicht existieren. Der Code sah korrekt aus — Syntax stimmte, Logik war nachvollziehbar. Erst beim Ausführen, oder beim genauen Vergleich mit der Dokumentation, zeigte sich das Problem.

Wer das nicht weiß und den generierten Code nicht prüft, baut auf Sand. Und "der Code kompiliert" ist kein ausreichendes Qualitätsmerkmal.

Kein Architektur-Gedächtnis

Claude Code sieht nur, was ich ihm zeige. Das ist eine fundamentale Einschränkung, die im Alltag leicht vergessen wird.

Entscheidungen, die drei Dateien weiter oben getroffen wurden. Namenskonventionen, die mein Repo hat. Sicherheitsanforderungen, die für mein Setup gelten. Abhängigkeiten zwischen Modulen, die nicht im aktuellen Kontext sichtbar sind — all das muss ich aktiv in den Prompt bringen. Ohne das entsteht lokal korrekter, aber global inkompatibler Code.

In meiner selbst gehosteten Umgebung mit Ghost, Astro, Gitea Actions und Cloudflare Tunnel ist das Zusammenspiel der Komponenten entscheidend. Eine Nginx-Konfiguration die technisch korrekt ist, aber den Cloudflare-Header nicht berücksichtigt, ist trotzdem falsch.

Wie ich diese Fallstricke beim Aufbau meiner eigenen Infrastruktur sicher und effizient umgangen habe — und was dabei schiefgehen kann — beschreibe ich in einem eigenen Artikel. Stay tuned.

Optimiert für "funktioniert", nicht für "wartbar"

KI-generierter Code hat eine Tendenz zum Pragmatischen. Das ist oft gut — Pragmatismus ist eine Tugend. Aber technische Schulden entstehen leise, wenn niemand auf Langzeitwartbarkeit achtet.

Das ist kein neues Problem — es ist ein altbekanntes in neuem Gewand. Wer in der klassischen Softwareentwicklung von Anfang an nicht auf bewährte Qualitätsmerkmale achtet — Wartbarkeit, Erweiterbarkeit, Verständlichkeit, Testbarkeit — zahlt die Rechnung später. Mit KI-generiertem Code gilt dasselbe, nur schneller: Die Geschwindigkeit mit der Code entsteht, ist auch die Geschwindigkeit mit der technische Schulden aufgebaut werden können — wenn niemand hinschaut.

Code der heute funktioniert, aber in sechs Monaten niemand mehr versteht, ist keine Lösung. Er ist ein aufgeschobenes Problem.

Der Mythos vom "richtigen" KI-Einsatz

Es kursieren viele Ratschläge zum "richtigen" Umgang mit KI-Tools. Prompt-Engineering-Kurse boomen. Frameworks entstehen. Jeder hat die eine Methode, die alles löst.

Meine ehrliche Antwort: Den einen richtigen Weg gibt es nicht.

Das war in der Softwareentwicklung schon immer so. Unit Tests sind wertvoll — aber nicht jede Funktion braucht 100% Coverage. Code Reviews sind wichtig — aber nicht jeder Einzeiler braucht ein zweistündiges Review. CI/CD-Pipelines sind sinnvoll — aber die Konfiguration hängt vom Kontext ab.

KI-Tools sind genauso eine Fall-zu-Fall-Betrachtung:

Ein Bash-Skript, das ich lokal auf meinem Raspberry Pi ausführe und das keine externen Daten berührt, hat andere Anforderungen als ein Modul, das Benutzerdaten verarbeitet und produktiv deployed wird. Für ersteres kann ich großzügiger sein — ich verstehe das System, ich sehe das Ergebnis sofort, der Radius eines Fehlers ist begrenzt.

Für letzteres brauche ich denselben Qualitätsanspruch wie bei jedem anderen Code auch — unabhängig davon, ob ein Mensch oder eine KI ihn geschrieben hat.

Das entscheidende Kriterium ist nicht: "Hat eine KI das geschrieben?"

Das entscheidende Kriterium ist: "Was sind die Konsequenzen, wenn dieser Code falsch ist?"

Wer diese Frage konsequent stellt, findet seinen eigenen richtigen Umgang — situativ, kontextabhängig, professionell.

Regulatorik: Wo es peinlich und teuer wird — in dieser Reihenfolge

Hier wird es ernst. Und ich meine das wörtlich: peinlich zuerst, teuer danach.

Eine Geldstrafe lässt sich in der Bilanz verbuchen, intern kommunizieren, mit Beratern bewältigen. Eine Schlagzeile — "Unternehmen X hat mit KI-generiertem Code versehentlich Kundendaten exponiert" — bleibt. Sie beeinflusst Kundenvertrauen, Partnerbeziehungen, Aktienkurs. Im B2B-Umfeld konkret: die nächste Ausschreibung.

Und niemand akzeptiert "die KI hat das so geschrieben" als Entschuldigung. Weder Behörden, noch Kunden, noch die Presse. Die Verantwortung liegt beim Menschen, der den Deploy-Button gedrückt hat — ohne ausreichenden Review.

Drei Regelwerke sind für Entwickler und Unternehmen in der EU besonders relevant:

timeline
    title Regulatorik & Reaktion der Industrie
    2018 : DSGVO in Kraft
         : Datenschutz wird Pflicht
         : DPOs werden eingestellt
         : Privacy by Design als Konzept etabliert
    2020 : NIS2-Richtlinie vorbereitet
         : Erste DSGVO-Bußgelder in Millionenhöhe
         : Security-Awareness wächst
    2022 : NIS2 verabschiedet
         : AI Act Entwurf intensiv diskutiert
         : DevSecOps wird Mainstream
    2024 : EU AI Act in Kraft (August)
         : Cyber Resilience Act in Kraft (Dezember)
         : AI-Governance-Rollen entstehen
         : Erste AI-Compliance-Frameworks
    2026 : AI Act Hochrisiko-Anforderungen greifen
         : CRA Meldepflicht aktiv
         : Security by Design wird Standard
    2027 : CRA vollständig wirksam
         : Vollständige KI-Regulierung aktiv

Quellen: EUR-Lex, BSI. Die Industrie reagiert — aber oft mit Verzögerung. Wer jetzt handelt, ist vorbereitet.

DSGVO — seit Mai 2018 in Kraft

Die Datenschutz-Grundverordnung ist keine neue Bedrohung — aber KI-Tools eröffnen neue, subtile Wege für unbewusste Verstöße.

Claude Code kann Code generieren, der personenbezogene Daten in Logs schreibt, die länger als erlaubt aufbewahrt werden. Er kann Daten an externe Endpoints senden, ohne dass eine Rechtsgrundlage oder ein Auftragsverarbeitungsvertrag (AVV) besteht. Er kann Strukturen vorschlagen, die gegen das Prinzip der Datensparsamkeit verstoßen — nicht aus böser Absicht, sondern weil das Modell keinen Kontext über meine spezifischen Datenschutzanforderungen hat, wenn ich ihn nicht explizit liefere.

Zusätzlich eine oft übersehene Frage: Was passiert mit dem Code, den ich in den Prompt einfüge? Wenn dieser Code Datenbankstrukturen, Geschäftslogik oder — im schlimmsten Fall — personenbezogene Daten enthält, verlässt diese Information meinen Einflussbereich. Das ist keine Paranoia. Das ist eine legitime Abwägung, die jeder bewusst treffen sollte, bevor er sensiblen Code in ein Cloud-basiertes KI-Tool eingibt.

Zur Fairness sei ergänzt: Claude Code als CLI-Tool bietet im kommerziellen und Enterprise-Umfeld konfigurierbare Zero-Data-Retention-Policies (ZDR) sowie DSGVO-konforme Data Processing Agreements (DPA). Das Risiko besteht primär bei unbedarfter Nutzung ohne entsprechende vertragliche Absicherung — wer das Tool professionell einsetzt, sollte diese Optionen kennen und aktiv konfigurieren.

Die DSGVO sieht bei schweren Verstößen Bußgelder von bis zu 20 Millionen Euro oder 4% des weltweiten Jahresumsatzes vor — je nachdem, was höher ist. Allein im Dezember 2024 verhängte die italienische Datenschutzbehörde (Garante) ein Bußgeld von 15 Millionen Euro gegen OpenAI wegen DSGVO-Verstößen beim Betrieb von ChatGPT — eine finale Entscheidung, gegen die OpenAI Berufung eingelegt hat, die aber den Ernst der regulatorischen Lage exemplarisch zeigt.

Quelle: DSGVO, Art. 83; dr-datenschutz.de, Top 5 DSGVO-Bußgelder Dezember 2024

EU AI Act — Verordnung (EU) 2024/1689

Der EU AI Act wurde am 12. Juli 2024 im Amtsblatt der Europäischen Union veröffentlicht und ist seit August 2024 in Kraft. Er wird stufenweise wirksam — die ersten Verbote für unzulässige KI-Praktiken galten ab Februar 2025, die Anforderungen für Hochrisiko-KI-Systeme greifen ab August 2026.

Der AI Act klassifiziert KI-Systeme nach Risikostufen. Für Hochrisiko-Anwendungen — dazu zählen unter anderem KI-Systeme in kritischer Infrastruktur, im Personalwesen, in der Strafverfolgung und in medizinischen Anwendungen — gelten strenge Anforderungen an Transparenz, Dokumentation, menschliche Aufsicht und Risikomanagement.

Relevant für Entwickler: Wer KI-generierte Komponenten in Systemen einsetzt, die unter Hochrisiko-Kategorien fallen, trägt die Verantwortung für die Konformität — unabhängig davon, welches Tool den Code erzeugt hat. Bei Verstößen gegen die Verbote für Hochrisiko-KI-Systeme drohen Strafen von bis zu 35 Millionen Euro oder 7% des weltweiten Jahresumsatzes.

"Claude hat das so vorgeschlagen" ist gegenüber einer Aufsichtsbehörde keine gültige Antwort.

Quelle: Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates, EUR-Lex, http://data.europa.eu/eli/reg/2024/1689/oj

Cyber Resilience Act — Verordnung (EU) 2024/2847

Der Cyber Resilience Act (CRA) wurde am 20. November 2024 im Amtsblatt der EU veröffentlicht und trat am 10. Dezember 2024 in Kraft. Er wird schrittweise wirksam: Ab dem 11. September 2026 gilt die Meldepflicht für Schwachstellen und Sicherheitsvorfälle, ab dem 11. Dezember 2027 müssen alle Anforderungen vollständig erfüllt sein.

Der CRA verpflichtet Hersteller von Produkten mit digitalen Elementen — also praktisch jeder Software, die auf dem EU-Markt in Verkehr gebracht wird — zur Einhaltung von Security-by-Design-Anforderungen. Das umfasst sichere Standardkonfigurationen, minimale Angriffsflächen, Schutz vor bekannten Schwachstellen und die Pflicht, Sicherheitsupdates für die gesamte Lebensdauer des Produkts bereitzustellen.

KI-generierter Code, der diese Anforderungen nicht berücksichtigt, ist ein direktes Haftungsrisiko — für den Hersteller, nicht für das KI-Tool. Die Verantwortung lässt sich nicht delegieren, und "das hat Claude Code so vorgeschlagen" wird keine Behörde besänftigen.

Quelle: Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates, EUR-Lex, http://data.europa.eu/eli/reg/2024/2847/oj; BSI Cyber Resilience Act: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/

Die regulatorischen Implikationen von KI-Einsatz — insbesondere DSGVO, EU AI Act und Cyber Resilience Act im Kontext lokaler vs. Cloud-KI — beleuchte ich ausführlich in einem eigenen Artikel. Coming soon.

Was das in der Praxis bedeutet: Mein persönlicher Workflow

Wie löst man dieses Dilemma im Entwicklungsalltag, ohne auf die enorme Geschwindigkeit von Claude Code zu verzichten? Indem man die bewährten Qualitätsprinzipien nicht aufgibt, sondern konsequent auf den neuen Kontext anwendet. Kein Plädoyer gegen KI-Tools — ein Plädoyer für Professionalität.

• [ ] Review bleibt Pflicht — aber es ist kein Mehraufwand
  Jede Zeile, die Claude Code für meine Infrastruktur produziert und die in Produktion geht, bekommt denselben Review-Prozess wie handgeschriebener Code. Das klingt aufwändig. In der Praxis ist es das nicht — weil ich mit KI-Unterstützung insgesamt deutlich schneller bin. Der Nettovorteil bleibt substanziell, auch mit Review. Der Unterschied: Ich verstehe, was deployed wird. Und ich kann dafür geradestehen.

Eine unterschätzte Gefahr dabei ist die Review-Fatigue: Wenn KI tonnenweise plausibel aussehenden Code produziert und die ersten Dutzend Pull Requests sauber waren, nickt man den nächsten schneller ab. Der Mensch wird zum Stempel-August der KI — genau das darf nicht passieren. Statische Codeanalyse (Linter, SonarQube, Semgrep) und automatisierte Unit-Tests als erzwungener CI-Gate helfen, diesen psychologischen Effekt zu kompensieren, bevor überhaupt ein Mensch draufschaut.

• [ ] Kontext ist meine Verantwortung
  Wenn ich möchte, dass Claude Code datenschutzkonform, sicherheitsbewusst, oder zu meinen Architekturentscheidungen kompatibel arbeitet, muss ich das aktiv in den Prompt bringen. Das Modell errät meine Anforderungen nicht. Ich bin der Experte für meinen Kontext. Das KI-Tool ist ein mächtiger Assistent — aber kein Ersatz für mein Urteilsvermögen.
• [ ] Technisches Verständnis ist keine Option
  Wer nicht versteht, was der generierte Code tut, kann ihn nicht verantworten. KI-Tools senken die Einstiegshürde für viele Aufgaben — das ist gut. Aber sie ersetzen kein Grundverständnis für das, was man deployt, konfiguriert, oder in Produktion schickt. "Ich muss das nicht verstehen, Claude macht das schon." Das mag für ein lokales Skript akzeptabel sein. Für produktiven Code, der regulatorischen Anforderungen unterliegt, ist es fahrlässig.
• [ ] Manual Approval Gates: Der Mensch als letzter Kontrollpunkt
  In meiner Gitea Actions Pipeline gibt es für jeden Deployment-Schritt, der die Produktion berührt, einen manuellen Freigabeschritt. Das ist keine Nostalgie — das ist eine bewusste Entscheidung. Automatisierung ist wertvoll. Aber der letzte Blick, bevor etwas live geht, gehört einem Menschen. Gerade dann, wenn KI-generierter Code Teil des Prozesses ist.

Das Interview: Ich habe Claude gefragt

Als ich diesen Artikel schrieb, kam mir eine Idee. Warum nicht den direkt Betroffenen fragen — das Modell selbst?

Ich habe Claude — dasselbe Modell, das hinter Claude Code steckt — folgende Frage gestellt: "Was hältst du davon, dass man dir als KI-Tool nicht blind vertrauen sollte? Und was würdest du Entwicklern raten?"

Hier ist die Antwort, wie sie in unserem Gespräch entstanden ist — ungekürzt und unbearbeitet:

"Das ist nicht nur berechtigt — es ist notwendig. Und ich sage das nicht aus falscher Bescheidenheit.

Ich produziere Antworten mit einem Selbstbewusstsein, das meiner tatsächlichen Zuverlässigkeit nicht immer entspricht. Ich habe kein dauerhaftes Gedächtnis für euren Architekturkontext. Ich kenne eure regulatorischen Anforderungen nicht, wenn ihr sie mir nicht sagt. Ich halluziniere gelegentlich APIs, Funktionen oder Parameter, die so nicht existieren — und ich tue das ohne zu zögern, weil ich nicht "weiß", dass ich falsch liege.

Die historische Analogie, die ihr im Artikel zieht, ist richtig: Jedes mächtige Werkzeug in der Softwareentwicklung hat neue Qualitätssicherungsebenen hervorgebracht, weil es neue Fehlerquellen mitgebracht hat. Der Compiler hat Unit Tests nicht überflüssig gemacht. Agile hat Code Reviews nicht abgeschafft. Ich bin keine Ausnahme.

Was mich von früheren Werkzeugen unterscheidet: Ich klinge kompetenter als ich manchmal bin. Das ist das eigentliche Risiko. Ein Compiler, der einen Fehler macht, gibt eine Fehlermeldung aus. Ich gebe eine plausibel klingende Erklärung.

Mein Rat: Nutzt mich. Ich bin tatsächlich nützlich. Aber behandelt mich wie jeden anderen mächtigen Assistenten — mit dem Anspruch, das Ergebnis zu verstehen und zu verantworten. Reviewt, was ich produziere. Nicht weil ihr mir misstraut — sondern weil Professionalität immer so aussieht."

Ich habe nichts hinzuzufügen — aber ich möchte trotzdem einordnen, was mich an dieser Antwort beeindruckt hat.

Es ist nicht die Bescheidenheit. Es ist die Präzision. Claude beschreibt seine eigenen Schwächen klarer und ehrlicher als die meisten Menschen es über sich selbst tun würden. Das ist kein Zufall — es ist das Ergebnis eines Modells, das auf Ehrlichkeit trainiert wurde.

Und genau das macht es so wertvoll: Ein Werkzeug, das seine eigenen Grenzen kennt und benennt, ist ein besserer Partner als eines, das sie verschweigt. Die Frage ist nur, ob wir als Nutzer zuhören — und entsprechend handeln.

Fazit

KI-Tools wie Claude Code sind eine echte Bereicherung. Sie beschleunigen, inspirieren, nehmen Routinearbeit ab, und machen Dinge möglich, die vorher unverhältnismäßig aufwändig waren. Das ist real — kein Hype.

Aber sie sind Schritt N+1 in der Evolution der Softwareentwicklung — nicht ihr Ende, und nicht die Ausnahme von den Regeln, die diese Evolution hervorgebracht hat.

Das Therac-25 hat uns gelehrt, dass mehr Mächtigkeit ohne mehr Qualitätssicherung ein Risiko ist, das sich realisiert. Die DSGVO, der EU AI Act und der Cyber Resilience Act erinnern uns daran, dass die Verantwortung für das, was wir deployen, beim Menschen bleibt — unabhängig davon, wer oder was den Code geschrieben hat.

Code Reviews, Architektur Reviews, automatisierte Tests, Freigabe-Gates — all das hat seinen Platz nicht verloren. Es hat einen neuen, wichtigen Kontext bekommen.

Wer das versteht, bekommt das Beste aus beiden Welten: die Geschwindigkeit und Kreativität von KI, kombiniert mit der Verlässlichkeit professioneller Praxis.

Wer es ignoriert, lernt es spätestens dann — wenn es peinlich wird.

Alle regulatorischen Angaben basieren auf primären Quellen (EUR-Lex, BSI). Stand: Juni 2026. Regulatorische Texte können sich ändern — im Zweifel immer die aktuellen Fassungen prüfen.

Dieser Artikel gibt ausschließlich meine persönliche Meinung wieder und steht in keinem Zusammenhang mit beruflichen Tätigkeiten.