Programmieren mit Claude als Sparringspartner: Wie viel eine KI kann, und warum Experten wichtiger werden als je zuvor

IMO - In unseren Projekten hat sich die Softwareentwicklung in den letzten Monaten spürbar verändert. Tools wie Claude, ChatGPT & Co. schreiben Code, generieren Tests, erklären Legacy-Systeme und schlagen Architekturvarianten vor. In vielen Teams gehört ein KI-Copilot inzwischen so selbstverständlich zum Alltag wie Git oder ein Debugger.

Unser Eindruck: Die besten Ergebnisse entstehen nicht, wenn die KI „allein" entwickelt, sondern wenn erfahrene Entwicklerinnen und Entwickler sie bewusst als Sparringspartner einsetzen. In diesem Artikel teilen wir, was KI im Entwicklungsalltag aus unserer Sicht sinnvoll leisten kann, wo wir klare Grenzen sehen und warum Seniorität, Domänenwissen und Architekturkompetenz aus unserer Perspektive heute wichtiger sind als je zuvor.

Was Claude als Sparringspartner aus unserer Sicht wirklich gut kann

In der Praxis erleben wir KI-Tools als produktive „zweite Person am Schirm". Sie sind besonders stark überall dort, wo es um Muster, Wiederholungen und bekanntes Wissen geht.

Typische Stärken im Entwickleralltag, wie wir sie beobachten:

• Standardcode und wiederkehrende Bausteine: Einfache Abläufe in der Anwendung oder kleine Hilfsfunktionen entstehen in Sekunden. So muss niemand mehr die gleichen Zeilen Code ständig neu schreiben.
• Refactoring und Code-Verbesserung: Aus langer, unübersichtlicher Business-Logik macht Claude häufig saubere Funktionen, kleinere Klassen und klarere Schnittstellen – oft mit sinnvolleren Namen und besserer Struktur, als man sie „auf die Schnelle" selbst schreiben würde.
• Tests generieren: Unit-Tests, einfache Integrationstests, Mocks und Testdaten entstehen auf Basis vorhandenen Codes deutlich schneller. So wird eine realistische Testabdeckung auch in gewachsenen Codebasen machbar, ohne dass das Team sich in repetitiver Testschreibarbeit verliert.
• Fremden Code verstehen: Legacy-Funktionen, die niemand mehr anfassen möchte, lassen sich in natürlicher Sprache erklären („Was macht diese Methode? Welche Annahmen stecken drin? Wo könnten Risiken sein?"). Das beschleunigt Onboarding und Fehlersuche.
• „Second Opinion" für Lösungswege: Statt nur nach Code zu fragen, nutzen wir Claude, um verschiedene Lösungsansätze gegeneinander zu stellen: „Welche Vor- und Nachteile hätte Ansatz A vs. B in diesem Kontext? Welche Implementierung passt besser zu unserer Architektur?"

Richtig eingesetzt, kann das die Produktivität aus unserer Sicht deutlich steigern – insbesondere bei erfahrenen Entwicklerinnen und Entwicklern, die gute Prompts formulieren, Vorschläge kritisch prüfen und zielgerichtet verwerten.

Wo wir ohne Expertenwissen klare Risiken sehen

In genau den Bereichen, in denen Softwareentwicklung anspruchsvoll wird – also Architektur, Sicherheit, Domänenlogik und Betriebsmodell – stoßen KI-Tools ohne menschliches Gegenüber nach unserer Erfahrung schnell an Grenzen.

Typische Risikobereiche, die wir immer wieder sehen:

• Architektur statt nur Code-Schnipsel: Claude optimiert häufig lokal („Diese Funktion schöner machen"), kennt aber eure strategische Architektur nicht: fachliche Grenzen, Integrationsstrategie, Skalierungsanforderungen, Betriebsmodell. Ein „schönerer" Codeblock kann das Gesamtsystem verschlechtern, wenn er Abhängigkeiten zwischen Teilen des Systems unnötig verstärkt oder Zuständigkeiten durcheinanderbringt.
• Sicherheit und Compliance: Generierter Code kann Frameworks korrekt nutzen – aber Themen wie Input-Validierung, Rechteprüfung, Secrets-Handling oder Logging-Regeln werden nicht automatisch in der Tiefe berücksichtigt, die euer Kontext braucht. Ohne Security- und Compliance-Verständnis im Team bleiben solche Lücken leicht unentdeckt.
• Domänenspezifische Fachlogik: Die eigentliche Wertschöpfung liegt für uns fast immer in der korrekten Abbildung von Geschäftslogik: Tarife, Abrechnungsregeln, regulatorische Anforderungen, Branchenlogik. Hier hilft kein allgemeines Modellwissen. Da technische Expertinnen und Experten oft keine Fachexpertinnen bzw. -experten sind, braucht es ein gutes Zusammenspiel mit Product Ownern und Fachbereichen, um KI-Vorschläge fachlich zu bewerten.
• „Plausibel, aber falsch": Sprachmodelle sind darauf ausgelegt, plausible Antworten zu liefern. Im Code heißt das: Vorschläge kompilieren, wirken logisch, enthalten aber subtile Logikfehler oder zeitliche Abhängigkeiten, bei denen sich Teile des Systems gegenseitig in die Quere kommen. Gerade bei komplexer Businesslogik oder parallelen Abläufen ist das gefährlich.

Je komplexer die Lösung und je kritischer der Anwendungsfall, desto größer ist aus unserer Sicht das Risiko, wenn KI-Code unreflektiert übernommen wird – insbesondere wenn im Team wenig Architektur- und Domänenwissen vorhanden ist.

Der limitierende Faktor: das Wissen der Person, die promptet

Ein Punkt, den wir in der täglichen Arbeit oft sehen: Die Qualität des Outputs ist direkt an die Qualität des Inputs gebunden – und die kommt von der Person, die Claude nutzt. „Garbage in, garbage out" gilt auch im Pair-Programming mit großen Sprachmodellen.

Zwei Extreme, die das gut verdeutlichen:

• Junior ohne Tiefenwissen: Fragt zum Beispiel: „Schreib mir eine sichere Zahlungs-API in Technologie X." Claude liefert ein Beispiel, das korrekt aussieht und sich schlüssig liest. Ob wichtige Punkte wie spezielle Branchenvorgaben, saubere Fehlerbehandlung oder saubere Trennung von Kunden und Mandanten wirklich stimmen, kann der Junior oft nicht beurteilen. Das Ergebnis wirkt professionell, ist aber fachlich und technisch nicht zuverlässig.
• Senior mit Architektur- und Domänenwissen: Fragt stattdessen: „Wir bauen eine Zahlungs-API für B2B-Kunden in Branche Y. Anforderungen A/B/C, regulatorische Vorgaben D/E. Skizziere drei Varianten mit Vor- und Nachteilen in unserem Kontext." Oder: „Prüfe diesen bestehenden Code auf mögliche Logikfehler, problematische zeitliche Abhängigkeiten und fehlende Validierung. Sei explizit bei Annahmen, die du triffst." Der Senior nutzt Claude wie einen starken Kollegen, dessen Vorschläge er bewusst einbettet, überprüft und anpasst. Die KI wirkt dabei als Verstärker: Sie macht gute Architektur und Arbeitsweisen stärker sichtbar und legt gleichzeitig Schwächen im Prozess oder in der Expertise schonungslos offen.

Deshalb ist ein klarer, professioneller Entwicklungsprozess aus unserer Sicht heute wichtiger denn je.

Best Practices: Wie wir Claude professionell als Sparringspartner nutzen

Damit Claude zum echten Sparringspartner wird und nicht zur „Stack Overflow 2.0 auf Steroiden"-Quelle, haben sich für uns einige Arbeitsprinzipien bewährt:

• Kontext zuerst, Code danach: Statt „Schreib mir einen Service in Framework XY" beschreiben wir zuerst das Geschäftsproblem, relevante Randbedingungen (Skalierung, Sicherheit, Latenz, Technologie-Stack) und den Systemkontext. Die Qualität der Vorschläge steigt spürbar, wenn die KI versteht, „wo das Bauteil im System hängt".
• In kleinen Iterationen arbeiten: Wir arbeiten mit kleinen, klar definierten Schritten: ein Modul, eine Funktion, ein Testpaket. Vorschläge werden direkt ausprobiert, erweitert oder verworfen. So verhindern wir, dass große Blöcke generierten Codes ungetestet ins System rutschen.
• Alternativen und Reviews einfordern: Wir nutzen KI nicht nur zum Generieren, sondern zum Diskutieren: „Gib mir zwei alternative Implementierungen und erläutere die Tradeoffs." oder „Wo siehst du potenzielle Schwächen in diesem Design?" Das schärft das eigene Denken, statt es zu ersetzen.
• Tests und Reviews nicht verhandeln: Für produktiven Code sind Tests und menschliche Reviews aus unserer Sicht nicht verhandelbar – unabhängig davon, ob der Code von einem Menschen oder von KI stammt. Gerade sicherheitskritische oder komplexe Bereiche brauchen immer ein menschliches Vier-Augen-Prinzip.
• Standards und Guardrails definieren: Wir legen gemeinsam fest, in welchen Bereichen KI-Code akzeptabel ist und wo nicht – zum Beispiel: unterstützend bei Hilfsfunktionen oder Tests, aber nicht für besonders sicherheitskritische oder geschäftlich zentrale Teile des Systems. Interne Entwicklungsrichtlinien und Architekturentscheidungen binden wir bewusst in die Prompts ein („Bitte orientiere dich an unseren XYZ-Guidelines."), damit Vorschläge zur eigenen Arbeitsweise passen.

Warum Expertinnen und Experten aus unserer Sicht wichtiger werden als je zuvor

Auf den ersten Blick könnte man meinen: Wenn KI immer mehr Code schreiben kann, brauchen wir weniger Senior-Entwickler und Architekten. In unseren Projekten erleben wir eher das Gegenteil.

• Mehr Output braucht mehr Einordnung: Wenn in Minuten entsteht, was früher Stunden gedauert hat, verschiebt sich der Engpass: weg von der Schreibarbeit, hin zur Frage, was davon fachlich sinnvoll, sicher, wartbar und langfristig tragfähig ist.
• Systemkomplexität wächst schneller: Schnellerer Feature-Output erhöht die Gefahr, dass Systeme unkontrolliert komplex werden – insbesondere, wenn Architekturentscheidungen nicht bewusst getroffen werden. Seniorität wird gebraucht, um langfristige Konsequenzen mitzudenken und Komplexität aktiv zu steuern.
• Verantwortung bleibt beim Menschen: Unabhängig davon, ob KI involviert ist – für Security Incidents, Datenschutzverstöße oder regulatorische Probleme tragen Menschen und Unternehmen die Verantwortung. KI ist ein Tool, kein Verantwortlicher.
• Coaching und Enablement werden wichtiger: Teams brauchen Unterstützung beim sinnvollen Einsatz von KI: Wie prompten wir? Wie binden wir Claude in unsere Architekturentscheidungen ein? Wie definieren wir Qualitätskriterien? Hier sehen wir die Rolle von erfahrenen Entwicklern, Tech-Leads und Beraterinnen, die Teams befähigen, statt nur „Tickets abzuarbeiten".

Gut eingesetzt, ermöglicht KI aus unserer Sicht, dass Expertinnen und Experten mehr Wirkung entfalten: dabei bleibt weniger Zeit für Routine, mehr Zeit für Architektur, Coaching, Qualität und Innovation.

Fazit: KI als Beschleuniger ist nur so wirksam wie das Team dahinter

Programmieren mit Claude als Sparringspartner kann Entwicklung massiv beschleunigen und qualitativ verbessern. Unser zentrales Learning: Entscheidend ist, wer die Fragen stellt, wie bewusst mit den Vorschlägen umgegangen wird und wie klar die Verantwortung im Team geregelt ist.

Für uns heißt das:

• Die Rolle erfahrener technischer Expertinnen und Experten verschiebt sich weg vom reinen „Code-Schreiben" hin zu Systemdenken, Review, Coaching und Entscheidungen.
• KI wird zu einem Werkzeug, das gute Teams noch stärker macht, schwache Strukturen aber nicht automatisch repariert.
• Der eigentliche Engpass ist weniger, was Claude kann, sondern wie reif das Team ist, das mit ihm arbeitet.

Autor: Denis Appelganz, IT-Consultant bei WaveAccess