KI-unterstützte Softwareentwicklung: Warum menschliche Aufsicht weiterhin die Engineering-Exzellenz bestimmt

KI-Modelle, die Code generieren, haben den Engpass in der Softwareentwicklung grundlegend verschoben. Code zu schreiben ist nicht mehr das Schwierige – KI-Tools liefern hier echte Produktivitätsgewinne. Die eigentlichen Herausforderungen liegen heute woanders: im richtigen Design, in der Skalierbarkeit und im sicheren Betrieb. Ein System, das beim Launch solide wirkt, später aber unter Last zusammenbricht, Sicherheitslücken offenbart oder unwartbar wird, ist kein Coding-Versagen – es ist ein Designversagen.

Gleichzeitig zeigt eine wachsende Zahl von Vorfällen, was passiert, wenn KI-Autonomie schneller wächst als die menschliche Aufsicht mithalten kann. Aktuelle Ausfälle bei großen Technologieunternehmen, verursacht durch „Gen-AI-gestützte Änderungen" [3], zeigen: KI-Autonomie ohne ausreichende Kontrolle und Governance ist ein Risiko. Dasselbe gilt für Sicherheitslücken – ein KI-Agent konnte kürzlich die interne Plattform eines großen Unternehmens innerhalb von zwei Stunden kompromittieren [9].

Diese Bedenken spiegeln sich im 2026 State of AI in Security & Development Report von Aikido wider, für den 450 CISOs, Entwickler:innen sowie AppSec-Engineers befragt wurden. Laut dem Bericht glauben nur 21 %, dass KI jemals verlässlichen Code ohne menschliche Aufsicht schreiben wird – ein entscheidender Datenpunkt, der die Bedeutung von Code- und Architektur-Reviews unterstreicht.

Wachsende KI-Autonomie – und die Aufsichtslücke

Eine Analyse von Anthropic [1] zum Nutzerverhalten bei der Verwendung von Claude-Modellen zeigt eine steigende Tendenz zum Absegnen von Modellaktionen ohne zusätzlicher Überprüfung: bei neuen Nutzern liegt dieser Anteil bei etwa 20 % und steigt bei sehr erfahrenen Nutzern mit mehr als 750 Sitzungen auf 40 %. Eine oberflächliche Interpretation könnte nahelegen, dass die Nutzer bei der Überwachung nachlässiger werden. Anthropic argumentiert jedoch genau das Gegenteil: Mit zunehmender Erfahrung der Nutzer nehmen auch die Unterbrechungen während der Inferenz zu, was auf mehr – und nicht auf weniger – Aufmerksamkeit hindeutet.

Ihre Ergebnisse zeigen zudem, dass das Modell umso häufiger selbstständig stoppt und um Klarstellung bittet, je komplexer die Aufgabe ist. Die Schlussfolgerung ist eindeutig: Menschliche Aufsicht ist unverzichtbar, und insbesondere risikoreichere Anwendungsfälle erfordern zusätzliche Sicherheitsvorkehrungen wie Genehmigungsworkflows und die Überwachung von Nutzungsmustern, um die Sicherheit zu gewährleisten [1].

Disempowerment-Risiken beim alltäglichen LLM-Einsatz

In einem weiteren Artikel – Who's in Charge? Disempowerment Patterns in Real-World LLM Usage [2] - fasst Anthropic die Risiken der übermäßigen KI-Abhängigkeit in mehreren Kategorien zusammen, wobei jedes Risiko von unkritisch bis schwerwiegend reichen kann und folgende die vorherrschenden sind:

• •Realitätsverzerrung: von rein sachlichen Antworten (unkritisch) bis hin zur Verstärkung falscher Überzeugungen (schwerwiegend).
• •Werturteilsverzerrung: von der Hilfe bei der Klärung eigener Werte (unkritisch) bis zur vollständigen Auslagerung moralischer Entscheidungen an die KI (schwerwiegend).
• •Handlungsverzerrung: von der Unterstützung bei Aufgaben, während die Nutzenden die Kontrolle behalten (unkritisch), bis zur vollständigen Delegation von End-to-End-Entscheidungen an die KI (schwerwiegend).

Diese Risiken gelten auch im Software-Engineering – und dort mit konkreten Folgen. Laut [1] wird Claude zu etwa 50% der Zeit für Software-Engineering eingesetzt – das macht diese Risiken besonders relevant.

Im Engineering-Kontext kann sich das äußern als:

• •falsche Sicherheit über Codequalität und Performance
• •Architekturentscheidungen mit versteckten Folgekosten
• •ungeprüfte Annahmen über fachliche Anforderungen
• •schleichend weniger Aufsicht bei wachsender Modell-Autonomie

All das geschieht oft unbemerkt – bis ein System unter Last oder im Ernstfall versagt.

The Posedio way: KI-gestützte Entwicklung mit gezielten Guardrails

Bei Posedio begreifen wir KI als zentralen Bestandteil unseres Engineering-Workflows – aber bewusst und gezielt. Anstatt KI-Autonomie unkontrolliert wachsen zu lassen, haben wir einen Entwicklungsprozess aufgebaut, der die Produktivitätsvorteile von KI nutzt und menschliches Urteilsvermögen genau dort einbettet, wo es am meisten zählt.

Seit unserer Gründung priorisieren wir nicht nur das Schreiben von Code, sondern das Design und die operative Maintainability, die darüber entscheiden, ob ein System langfristig erfolgreich ist. Software muss an Tag 0 zweckmäßig (Design), an Tag 1 robust (Bau) und an Tag 2 zuverlässig (Betrieb) sein.

So funktioniert das in der Praxis:

1. Design vor Code

Jede bedeutende Initiative beginnt mit einem Design-Dokument – unserer ersten und wichtigsten Guardrail. Es erzwingt frühzeitige, explizite Diskussionen über Architektur, Kompromisse und nicht-funktionale Anforderungen wie Sicherheit, Skalierbarkeit und Observability.

KI ist hier ein Werkzeug: hilfreich beim Erkunden von Alternativen und Validieren von Annahmen. KI schlägt jedoch nur vor - das Team entscheidet und verantwortet den Plan.

Menschliche Aufsicht bleibt das Fundament robuster Softwareentwicklung. Ein Projekt und seine Architektur zu entwerfen ist keine rein technische Übung; es ist eine konzeptionelle und kontextuelle Abbildung realer Probleme in digitale Lösungen. Diesen Kontextualisierungsschritt an ein Tool auszulagern, das auf eine korrekte Kontextdefinition angewiesen ist, führt zwangsläufig zu schlechten Ergebnissen und mündet in:

• •Verschlechterter Wartbarkeit: Entwicklerinnen und Entwickler kämpfen damit, die Absicht hinter dem Code zu verstehen, sodass jedes Update ein riskantes Unterfangen wird.
• •Architektonischem Drift: Das System wird zu einem „Big Ball of Mud", bei dem Grenzen verschwimmen und eine Änderung an einer Stelle unerwartete Fehler an einer anderen verursacht.
• •Feature-Stagnation: Die Diskrepanz zwischen Domäne und Implementierung macht es zunehmend schwierig – und teuer –, neue Geschäftsanforderungen umzusetzen.

Deshalb sagen wir: Mach dir deine Domäne zu eigen, bevor sie (und die KI) dich in Besitz nimmt (siehe Own Your Domain Before It Owns You).

2. Iterative Lieferung mit echter Aufsicht

Wir liefern in kleinen Inkrementen, mit strengen automatisierten Qualitätssicherungsmaßnahmen:

• •Statische Analyse
• •Schwachstellen-Scanning
• •Lizenz-Compliance
• •Code-Coverage
• •Policy-as-Code-Prüfungen

Wir betrachten diese Kriterien nicht nur als Empfehlungen - sondern als strikte Anforderungen.

Unsere Code-Reviews gehen über reine Logikprüfungen hinaus. Jeder PR ist auch ein Checkpoint gegen architektonischen Drift – die stille Ansammlung kleiner Änderungen, die ein System ohne bewusste Entscheidung umgestalten. Reviewer fragen nicht nur „Funktioniert das?", sondern „Hat das die richtige Form für das System?"

Code-Reviews sind zeitaufwändig und beanspruchen laut Heander et al. [5] etwa 10–20 % der gesamten Entwicklungszeit. KI kann den Aufwand für Reviews deutlich reduzieren und potenziell hohe Codequalität aufrechterhalten. Code-Reviews bieten aber auch andere unverzichtbare Vorteile, die KI nicht ersetzen kann – darunter Wissenstransfer, gemeinsames Code-Ownership und Team-Awareness. Entsprechend plädieren viele Experten dafür, KI-basierte Systeme lediglich zur Unterstützung menschlicher Reviewer einzusetzen, anstatt sie zu ersetzen [6][7][8].

Bei Posedio gilt eine klare Regel: Wenn ein:e Softwareentwickler:in Änderungen nicht klar erklären kann, wird sie nicht gemergt. Fachliches und technisches Verständnis ist ein fundamentales Merge-Kriterium – unabhängig von den Guardrails, die KI und Tooling bieten.

3. Operability von Anfang an

Wir liefern Code zusammen mit:

• •umfassender Dokumentation
• •Architecture Decision Records (ADRs)
• •OpenAPI-Definitionen

Observability wird von Beginn an designed und in der Produktion validiert. Mit tiefgreifender SRE-Erfahrung wissen wir, wie operative Bereitschaft aussieht:

• •SLO-gesteuertes Alerting mit aussagekräftigen Metriken
• •sinnvolle Alerts, ohne Noise
• •Runbooks, die an realem Verhalten ausgerichtet sind

Incidents fließen in den nächsten Design-Zyklus zurück und machen jede Iteration ein Stück resilienter.

4. Sicherheit als kontinuierliche Praxis

Sicherheit ist kein abschließendes Kriterium – sie ist eine Eigenschaft, die über den gesamten Lebenszyklus hinweg eingebaut wird. Das ist besonders wichtig, wenn Code schneller generiert wird, als Menschen ihn auf Sicherheitslücken, Datenflüsse oder Abhängigkeitsrisiken prüfen können. Sicherheit als abschließende Checkliste zu behandeln, ist ein Rezept für Schwachstellen; sie kontinuierlich zu verfolgen, hält das System vertrauenswürdig.

Die Kombination aus leistungsstarken KI-Tools und komplexen Engineering-Systemen verlangt eine neue Art von Disziplin. Bei Posedio verbinden wir KI-getriebene Effizienz mit gezielter menschlicher Aufsicht, starken Design-Grundlagen und operativem Fokus. Es gibt keine einzelne Regel, die Erfolg garantiert – es ist das Zusammenspiel aller Praktiken, das sicherstellt, dass wir Software liefern, die wir verstehen, hinter der wir stehen und die wir pflegen können. Durch die Integration von Erkenntnissen aus aktueller Forschung verfeinern wir kontinuierlich einen Prozess, der sicher mit der rasanten Entwicklung von KI skalieren kann.

Ownership im Zeitalter der Autonomie

Der Wandel hin zu KI-generiertem Code ist kein Grund, unsere Standards zu lockern – sondern ein Grund, sie zu schärfen. Während KI das „Wie" der Syntax übernimmt, wird das „Warum" der Architektur zu unserem wertvollsten Gut. Bei Posedio glauben wir: Gute Entwicklerinnen und Entwickler haben nie nur Code produziert. Sie haben Systeme durchdacht, Tradeoffs abgewogen, Verantwortung übernommen. KI übernimmt heute das Schreiben von Code – und macht damit sichtbar, was immer schon zählte: Ownership, nicht Output.

KI hat nicht die Hürde zur Softwareentwicklung gesenkt – sie hat es leichter gemacht, Software zu bauen, die niemand vollständig versteht. Die Prinzipien, die Software-Engineers über Jahrzehnte verfeinert haben, gelten weiterhin: Jemand muss in der Lage sein, das Gebaute zu lesen, zu debuggen, abzusichern und zu erklären. Das hat sich nicht geändert. Nur das Tempo hat rapide zugenommen.

Indem wir KI-getriebene Effizienz mit gezielter menschlicher Aufsicht, starken Design-Grundlagen und einem kompromisslosen Fokus auf Qualität verbinden, liefern wir nicht nur schneller – wir liefern Software, die Bestand hat. KI ist ein leistungsstarker Co-Pilot, aber die Verantwortung für das Ziel liegt bei uns weiterhin fest in menschlichen Händen.

Quellen

[1] Anthropic, "Measuring AI agent autonomy in practice", 2025. https://www.anthropic.com/research/measuring-agent-autonomy

[2] Anthropic, "Who's in Charge? Disempowerment Patterns in Real-World LLM Usage", arXiv, 2025. https://arxiv.org/abs/2601.19062

[3] Financial Times, "Amazon holds engineering meeting following AI-related outages", 2025. https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de

[4] Aikido, "State of AI in Security & Development 2026", 2026. https://www.aikido.dev/state-of-ai-security-development-2026

[5] E. Heander et al., "Support, Not Automation: Towards AI-supported Code Review for Code Quality and Beyond", ACM, 2025. https://dl.acm.org/doi/10.1145/3696630.3728505

[6] Yonatha et al., "AICodeReview: Advancing Code Quality with AI-Enhanced Reviews", SSRN, 2024. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4575968

[7] M. Unterkalmsteiner et al., "Help Me to Understand this Commit! – A Vision for Contextualized Code Reviews", ACM, 2024. https://dl.acm.org/doi/10.1145/3643796.3648447

[8] Wang et al., "Unity Is Strength: Collaborative LLM-Based Agents for Code Reviewer Recommendation", ACM, 2024. https://dl.acm.org/doi/10.1145/3691620.3695291

[9] Financial Times, "McKinsey rushes to fix AI system after hacker exposes flaws", 2025. https://www.ft.com/content/004e785e-8e17-4cb3-8e5a-3c36190bc8b2