Programmieren mit KI und Vibe Coding

Management-Zusammenfassung

Die zentrale Einordnung

Vibe Coding ist eine reale Veränderung der Softwareerstellung, aber kein einheitliches Verfahren. Empirische Studien zeigen ein Spektrum: Manche Nutzer beschreiben Ziele in natürlicher Sprache, testen nur oberflächlich und lassen sich bei Fehlern erneut Code generieren. Andere nutzen denselben dialogischen Zugang, lesen Diffs, verändern Code manuell, schreiben Tests und behalten Architektur sowie Betrieb vollständig in eigener Verantwortung. Wer beide Arbeitsweisen unter demselben Begriff zusammenfasst, erzeugt falsche Schlussfolgerungen über Fähigkeit und Risiko. ^{[S-001, S-003, S-006, S-007]}

Die Technik senkt die Eintrittshürde zur Codeerzeugung massiv. Sie senkt nicht automatisch die Eintrittshürde zu sicherer und dauerhaft betreibbarer Software. Ein Mensch ohne klassische Programmierausbildung kann heute Prototypen, kleine Werkzeuge, Webseiten und Automationen erstellen, die früher einen Entwickler benötigt hätten. Sobald jedoch Authentisierung, personenbezogene Daten, Zahlungsflüsse, Mandantentrennung, Datenmigration, Betrieb, Skalierung oder Kundenhaftung hinzukommen, bleibt professionelle Software-Engineering-Kompetenz erforderlich - entweder beim Ersteller selbst oder durch qualifizierte Prüfung und Betrieb. ^{[S-004, S-007, S-065, S-067, S-103, S-105]}

Produktivität ist real, aber nicht universell

Die Studienlage ist nicht widerspruchsfrei, weil sie unterschiedliche Fragen beantwortet. In einer begrenzten Programmieraufgabe waren Copilot-Nutzer im Mittel 55,8 Prozent schneller. Drei Unternehmens-RCTs mit 4.867 Entwicklern schätzten kombiniert rund 26 Prozent mehr erledigte Aufgaben. Dagegen waren 16 sehr erfahrene Open-Source-Maintainer bei 246 realen Issues mit erlaubter KI im Mittel 19 Prozent langsamer. Gerade dieser Gegenbefund ist wichtig: Die Entwickler glaubten trotzdem, beschleunigt worden zu sein. ^{[S-015, S-016, S-017, S-018]}

Die richtige Schlussfolgerung ist deshalb weder „KI macht Programmierer schneller“ noch „KI bremst Profis“. Der Effekt hängt von Aufgabe, Codebasis, Erfahrung, Modell, Agenten-Harness, Kontextqualität, Testabdeckung und Definition von Produktivität ab. Boilerplate, Dokumentation, kleine Greenfield-Funktionen und klar spezifizierte Änderungen sind häufig günstiger. Tief vertraute Legacy-Systeme, unklare Anforderungen, große Refactorings und sicherheitskritische Änderungen erhöhen dagegen Kontext-, Review- und Reworkkosten. ^{[S-012, S-011, S-022, S-004, S-026]}

Die neue Engstelle heißt Verifikation

Codegenerierung skaliert schneller als menschliches Verständnis und Review. Das verschiebt den Engpass: Nicht die Tippgeschwindigkeit, sondern Spezifikation, Kontext, Tests, Code Review, Sicherheitsprüfung und Betrieb bestimmen den realisierten Wert. Eine große Mining-Studie mit 304.362 explizit als KI-authentifiziert markierten Commits fand hunderttausende statisch erkannte Probleme; 24,2 Prozent der verfolgten KI-eingeführten Probleme bestanden am letzten Repository-Stand fort. Der Befund ist als Preprint und aufgrund seiner Attribution begrenzt, zeigt aber, warum „der Code läuft“ kein ausreichendes Qualitätsurteil ist. ^{[S-039, S-042, S-046]}

Tests sind unverzichtbar, aber ebenfalls kein Orakel. OpenAI fand 2026 bei mindestens 59,4 Prozent von 138 auditierten schwierigen SWE-bench-Verified-Fällen materielle Aufgaben- oder Testprobleme. Im Juli 2026 schätzte ein weiterer OpenAI-Audit, dass rund 30 Prozent der öffentlichen SWE-Bench-Pro-Aufgaben gebrochen sind. Zusätzliche Testgenerierung veränderte in anderen Arbeiten Rankings und deckte falsch positiv bewertete Patches auf. Wer Code und Tests vom selben Agenten erzeugen lässt, darf deshalb nicht von unabhängiger Verifikation sprechen. ^{[S-058, S-059, S-064, S-045]}

Kompetenz und Verantwortung

KI kann kurzfristig Output erhöhen, ohne Verständnis im selben Maß zu steigern. Studien zu Skill Formation und Brownfield-Aufgaben zeigen eine Lücke zwischen bestandenen Tests beziehungsweise schnellerer Umsetzung und tatsächlichem Codeverständnis. Besonders riskant ist vollständige Delegation bei Fähigkeiten, die später zur Kontrolle der KI benötigt werden: Code-Lesen, Debugging, Architektur und Sicherheitsbeurteilung. Lernförderlicher waren Interaktionsmuster, in denen Nutzer konzeptuelle Fragen stellten, eigene Vorhersagen machten und generierten Code erklärten oder manuell reparierten. ^{[S-029, S-030, S-031, S-032]}

Sicherheitsgrenze

Coding-Agenten können Dateien lesen und schreiben, Befehle ausführen, Pakete installieren, Webseiten aufrufen, Pull Requests öffnen und über MCP weitere Systeme bedienen. Damit wird aus einem Textgenerator ein handlungsfähiges Softwarewerkzeug. Offizielle Dokumentationen von OpenAI, Anthropic, GitHub und Google setzen deshalb auf Sandboxen, Freigaben, begrenzten Netzwerkzugriff und sichtbare Änderungen. Diese Kontrollen sind keine Formalität: Studien dokumentieren unsicheren Code, erfundene Paketnamen, indirekte Prompt Injection über Repositories und reale Fehlermuster agentischer Coding-Systeme. ^{[S-090, S-094, S-098, S-102, S-047, S-049, S-051]}

Schlussfolgerung für die Buchreihe

Die überzeugendste Position für ein Praxisbuch lautet: Vibe Coding ist ein leistungsfähiger Einstieg in die Softwareerstellung, aber kein Ersatz für Software Engineering. Für kleine, isolierte, reversible und nicht kritische Projekte kann der Mensch bewusst mit geringerer Codekenntnis arbeiten. Mit wachsender Reichweite, Datenkritikalität und Kundenverantwortung müssen Spezifikation, Versionskontrolle, Tests, unabhängige Prüfung, Least Privilege, Monitoring, Backup und benannter Betriebseigner verbindlich hinzukommen. Die Frage ist nicht, ob jemand „programmieren kann“, sondern ob er die Folgen seiner Software begrenzen, prüfen und verantworten kann. ^{[S-007, S-065, S-075, S-067, S-081]}

Die 50 wichtigsten Kernaussagen

F-001 - BEGRIFF / FORSCHUNGSSTAND

Der Ausdruck „Vibe Coding“ wurde 2025 populär, ist aber kein technischer Standard und wird in Forschung und Praxis unterschiedlich eng verwendet.

Einschränkung: Für belastbare Aussagen muss die konkrete Arbeitsweise beschrieben werden, nicht nur das Etikett. Quellen: S-001, S-002, S-003, S-007 · Refresh-Risiko: hoch

F-002 - BEGRIFFLICHE ABGRENZUNG

Im engen Sinn bedeutet Vibe Coding, dass der Mensch Software überwiegend per natürlicher Sprache erzeugt und den resultierenden Code nur selektiv oder gar nicht vollständig liest.

Einschränkung: Viele professionelle Nutzer arbeiten zwar dialogisch, prüfen aber Diffs, Tests und Architektur; das ist besser als KI-gestützte Softwareentwicklung zu bezeichnen. Quellen: S-003, S-001, S-006 · Refresh-Risiko: mittel

F-003 - EMPIRISCHER BEFUND

Empirisch beobachtetes Vibe Coding ist selten ein einziger Prompt: Es besteht aus wiederholten Zyklen aus Zielbeschreibung, Generierung, Ausprobieren, Fehlersuche, Korrektur und manueller Bearbeitung.

Einschränkung: Die untersuchten Sitzungen sind nicht repräsentativ für alle Werkzeuge und Nutzer. Quellen: S-001, S-008, S-013 · Refresh-Risiko: mittel

F-004 - FORSCHUNGSSYNTHESE

Programmierkompetenz verschwindet nicht, sondern verlagert sich zu Kontextaufbau, Bewertung, Fehlersuche, Architekturentscheidungen und der Wahl zwischen Delegation und manueller Arbeit.

Einschränkung: Nicht-Programmierer können Ergebnisse erzeugen, tragen aber ohne diese Kompetenzen ein höheres Prüf- und Betriebsrisiko. Quellen: S-001, S-004, S-006, S-005 · Refresh-Risiko: mittel

F-005 - EMPIRISCHER BEFUND

In einer Studie sagte Computer-Science-Leistung den Vibe-Coding-Erfolg stärker voraus als Schreibfähigkeit; gute natürliche Sprache ersetzt technisches Verständnis daher nicht.

Einschränkung: Korrelationsstudie; keine universelle Kausalitätsaussage. Quellen: S-005 · Refresh-Risiko: mittel

F-006 - EMPIRISCHER BEFUND

Nicht-Programmierer, Anfänger und Profis unterscheiden sich deutlich darin, welche Fehler sie erkennen, wann sie vertrauen und welche Qualitätssicherungsmaßnahmen sie tatsächlich anwenden.

Einschränkung: Selbsteinschätzung und tatsächliches Prüfverhalten können auseinanderfallen. Quellen: S-006, S-003, S-014 · Refresh-Risiko: mittel

F-007 - FORSCHUNGSSYNTHESE

Die bisher stärkste Evidenz für Vibe Coding liegt bei Prototypen, Benutzeroberflächen, kleinen Automationen und klar abgegrenzten Greenfield-Aufgaben.

Einschränkung: Die Evidenz ist schwächer für produktive, datenintensive, regulierte und sicherheitskritische Systeme. Quellen: S-007, S-004, S-009 · Refresh-Risiko: hoch

F-008 - ENGINEERING-GRUNDSATZ

Ein funktionierender Prototyp ist kein Nachweis für Produktionsreife: Betrieb, Sicherheit, Datenmigration, Wartung, Monitoring, Backup und Haftung werden im Demo-Erfolg kaum sichtbar.

Einschränkung: Produktionsreife ist risikobasiert und hängt vom Einsatzkontext ab. Quellen: S-004, S-065, S-081, S-103 · Refresh-Risiko: mittel

F-009 - METHODISCHE GRUNDLAGE

Erzeugte Codezeilen, angenommene Vorschläge oder kurze Bearbeitungszeit sind keine vollständigen Produktivitätsmaße; entscheidend ist der akzeptierte, integrierte und betriebene Nutzen.

Einschränkung: Messung muss Qualität, Review, Rework, Stabilität und Teamwirkung einschließen. Quellen: S-023, S-024, S-022, S-046 · Refresh-Risiko: mittel

F-010 - EMPIRISCHER BEFUND

In einem kontrollierten Versuch mit einer eng begrenzten Aufgabe waren Teilnehmende mit GitHub Copilot im Mittel 55,8 Prozent schneller.

Einschränkung: Ein einzelnes Task-Setting ist kein universeller Effekt für reale Repositories. Quellen: S-015 · Refresh-Risiko: niedrig

F-011 - EMPIRISCHER BEFUND

Drei randomisierte Feldexperimente mit 4.867 Softwareentwicklern schätzten kombiniert rund 26 Prozent mehr erledigte Aufgaben unter KI-Unterstützung.

Einschränkung: Unternehmens-, Aufgaben- und Messkontext begrenzen die Übertragbarkeit. Quellen: S-016 · Refresh-Risiko: mittel

F-012 - EMPIRISCHER GEGENBEFUND

METR fand bei sehr erfahrenen Open-Source-Maintainern in vertrauten Repositories eine durchschnittliche Verlangsamung von 19 Prozent, obwohl die Beteiligten einen positiven Effekt erwarteten.

Einschränkung: Kleine, spezialisierte Stichprobe und frühe 2025er Werkzeuge; nicht als allgemeiner Durchschnitt missverstehen. Quellen: S-017, S-018 · Refresh-Risiko: mittel

F-013 - FORSCHUNGSSYNTHESE

Selbstberichteter Nutzen und objektiv gemessener Effekt können bei KI-Programmierung deutlich auseinanderfallen.

Einschränkung: Wahrgenommener Komfort bleibt relevant, ersetzt aber keine Zeit- und Qualitätsmessung. Quellen: S-017, S-020, S-014 · Refresh-Risiko: mittel

F-014 - METHODISCHE WARNUNG

Spätere METR-Daten konnten wegen Selbstselektion keinen unverzerrten durchschnittlichen Produktivitätseffekt liefern.

Einschränkung: Nutzer, die KI als hilfreich erleben, wählen eher KI-Aufgaben; Nichtnutzer verschwinden aus der Vergleichsgruppe. Quellen: S-019 · Refresh-Risiko: hoch

F-015 - FORSCHUNGSSYNTHESE

Die empirischen Befunde sind heterogen, weil Aufgabe, Erfahrung, Codebasis, Modell, Agenten-Harness, Akzeptanzkriterium und Organisation variieren.

Einschränkung: Ein globaler Prozentwert ohne Kontext ist methodisch schwach. Quellen: S-012, S-011, S-022, S-025, S-026 · Refresh-Risiko: hoch

F-016 - FORSCHUNGSSYNTHESE

Greenfield-Projekte sind für KI meist leichter als Brownfield-Arbeit, weil Legacy-Konventionen, versteckte Abhängigkeiten, historische Entscheidungen und implizite Verträge fehlen.

Einschränkung: Auch Greenfield-Code kann schnell Architektur- und Sicherheitsprobleme ansammeln. Quellen: S-004, S-031, S-030, S-026 · Refresh-Risiko: mittel

F-017 - ENGINEERING-SYNTHESE

Guter Kontext ist nicht bloß ein langer Prompt: Relevante Dateien, Architekturregeln, Definition of Done, Tests, Schnittstellen und Ausschlusskriterien müssen auffindbar und widerspruchsfrei sein.

Einschränkung: Lange Kontexte können relevante Informationen trotzdem übersehen oder ungünstig gewichten. Quellen: S-004, S-008, S-123, S-124 · Refresh-Risiko: hoch

F-018 - SICHERHEITS- UND ENGINEERING-GRUNDSATZ

Je autonomer ein Coding-Agent arbeitet, desto wichtiger werden klare Aufgabenzerlegung, begrenzte Berechtigungen, sichtbare Arbeitsprotokolle und reversible Änderungen.

Einschränkung: Autonomie ohne Observability vergrößert den möglichen Schadensradius. Quellen: S-090, S-094, S-098, S-087 · Refresh-Risiko: hoch

F-019 - ENGINEERING-SYNTHESE

Anforderungen und Akzeptanzkriterien werden durch KI-Codegenerierung wichtiger, nicht unwichtiger, weil plausible Implementierungen unklare Ziele besonders schnell verfestigen.

Einschränkung: Akzeptanzkriterien müssen fachliche und nicht nur technische Eigenschaften abdecken. Quellen: S-004, S-080, S-045, S-059 · Refresh-Risiko: mittel

F-020 - PRAXISREGEL / ANBIETERÜBERGREIFEN

Kleine, überprüfbare Änderungen mit engem Scope sind robuster als breite Aufforderungen wie „baue mir die ganze Anwendung“.

Einschränkung: Bei kleinen Experimenten kann eine breite Delegation vertretbar sein, wenn Ergebnis und Umgebung wegwerfbar sind. Quellen: S-097, S-089, S-093, S-001 · Refresh-Risiko: hoch

F-021 - SOFTWARE-ENGINEERING-GRUNDSATZ

Tests sind ausführbare Spezifikationen und Regression-Schutz, aber kein Beweis vollständiger Korrektheit.

Einschränkung: Fehlende oder zu enge Tests können falsche Lösungen akzeptieren und korrekte ablehnen. Quellen: S-065, S-067, S-064, S-058, S-059 · Refresh-Risiko: mittel

F-022 - FORSCHUNGS- UND PRAXISBEFUND

Von demselben Agenten erzeugte Implementierung und Tests können dieselben Missverständnisse teilen.

Einschränkung: Unabhängige Testquellen, negative Fälle und menschliche Prüfungen reduzieren korrelierte Blindstellen. Quellen: S-045, S-064, S-059 · Refresh-Risiko: hoch

F-023 - SICHERHEITSSTANDARD

Produktionsprüfungen benötigen neben Happy Paths auch Randfälle, Fehlermodi, Berechtigungen, Datenintegrität, Last, Wiederanlauf und Sicherheitsmissbrauch.

Einschränkung: Tiefe und Umfang hängen vom Risikoprofil ab. Quellen: S-065, S-067, S-068, S-081 · Refresh-Risiko: mittel

F-024 - ENGINEERING-GRUNDSATZ

Versionskontrolle mit kleinen Commits, Branches und nachvollziehbaren Diffs ist bei KI-generierten Änderungen zentrale Sicherheits- und Lerninfrastruktur.

Einschränkung: Git verhindert keine Fehler, macht Änderungen aber prüfbar und rücksetzbar. Quellen: S-075, S-097, S-076 · Refresh-Risiko: niedrig

F-025 - ENGINEERING-GRUNDSATZ

CI/CD-Gates automatisieren wiederholbare Prüfungen, ersetzen aber nicht fachliche Abnahme, Architekturreview und Risikobewertung.

Einschränkung: Automatisierte Checks sind nur so gut wie ihre Regeln und Testdaten. Quellen: S-076, S-065, S-024 · Refresh-Risiko: mittel

F-026 - SICHERHEITSBEFUND

Sandboxen und Entwicklungscontainer reduzieren den Schadensradius, beseitigen aber keine Risiken durch freigegebene Netzwerke, Secrets, Host-Mounts oder überprivilegierte Tools.

Einschränkung: Konfiguration und tatsächliche Boundary müssen geprüft werden. Quellen: S-077, S-090, S-094, S-098 · Refresh-Risiko: hoch

F-027 - SICHERHEITSGRUNDSATZ

Agenten sollten standardmäßig mit minimalen Rechten arbeiten; schreibende, ausführende, veröffentlichende und externe Aktionen benötigen risikobasierte Freigaben.

Einschränkung: Pauschale Dauerfreigaben erhöhen Komfort und Schadensradius zugleich. Quellen: S-094, S-090, S-099, S-087 · Refresh-Risiko: hoch

F-028 - OFFIZIELLE PRODUKT- UND SICHERHEITSAUSSAGE

Netzwerkzugriff erweitert die Leistungsfähigkeit eines Coding-Agenten, zugleich aber die Angriffsfläche für Prompt Injection, Datenabfluss, Malware und problematische Abhängigkeiten.

Einschränkung: Allowlisting und Review reduzieren, aber eliminieren das Risiko nicht. Quellen: S-091, S-050, S-051, S-070 · Refresh-Risiko: hoch

F-029 - SICHERHEITSSTANDARD

Secrets gehören weder in Prompts noch in Repositories; sie müssen über geeignete Secret-Stores, kurzlebige Identitäten und minimale Scopes bereitgestellt werden.

Einschränkung: Auch Log- und Telemetriepfade sind einzubeziehen. Quellen: S-065, S-068, S-076, S-096 · Refresh-Risiko: hoch

F-030 - EMPIRISCHER SICHERHEITSBEFUND

KI-generierte Paketnamen und Abhängigkeiten müssen gegen vertrauenswürdige Register und Projektquellen geprüft werden, weil Package Hallucinations empirisch dokumentiert sind.

Einschränkung: Raten variieren stark nach Modell, Sprache, Prompt und Studiendesign. Quellen: S-049, S-054 · Refresh-Risiko: hoch

F-031 - EMPIRISCHER SICHERHEITSBEFUND

Kontrollierte Studien zeigen, dass KI-Hilfe unsicheren Code erzeugen und zugleich das Vertrauen der Nutzer erhöhen kann.

Einschränkung: Die Studien messen begrenzte Aufgaben; heutige Modelle und Kontrollen können abweichen. Quellen: S-047, S-048, S-102 · Refresh-Risiko: hoch

F-032 - SICHERHEITSFORSCHUNG

Indirekte Prompt Injection kann über README-Dateien, Issues, Webseiten, Tool-Metadaten oder MCP-Ressourcen in den Arbeitskontext eines Coding-Agenten gelangen.

Einschränkung: Die konkrete Ausnutzbarkeit hängt von Toolrechten und Sicherheitsarchitektur ab. Quellen: S-050, S-051, S-086, S-087 · Refresh-Risiko: hoch

F-033 - PROTOKOLL- UND SICHERHEITSAUSSAGE

MCP standardisiert Verbindungen zu Werkzeugen und Daten, schafft aber keine automatische Vertrauenswürdigkeit des Servers oder der angebotenen Tools.

Einschränkung: Authentisierung, Autorisierung, Herkunft, Toolbeschreibung und Laufzeitisolation bleiben Implementierungsaufgaben. Quellen: S-085, S-086, S-087 · Refresh-Risiko: hoch

F-034 - AKTUELLER PREPRINT-BEFUND

Große Repository-Mining-Studien deuten darauf hin, dass KI-authentifizierte Commits Code Smells, Fehler und Sicherheitsprobleme einführen können, von denen ein Teil langfristig bestehen bleibt.

Einschränkung: Attribution über explizite Git-Metadaten deckt nur einen Teil aller KI-Nutzung ab; statische Analyse ist kein vollständiges Qualitätsurteil. Quellen: S-039 · Refresh-Risiko: hoch

F-035 - FORSCHUNGSSYNTHESE

Technische Schuld durch KI entsteht nicht nur im Code, sondern auch durch unklare Anforderungen, fehlende Tests, unverständliche Abhängigkeiten und verlorenes Systemwissen.

Einschränkung: Schuld ist kontextabhängig und muss über Zeit beobachtet werden. Quellen: S-040, S-032, S-041, S-043 · Refresh-Risiko: mittel

F-036 - AKTUELLER PREPRINT-BEFUND / INFERENZ

KI kann Code schneller erzeugen, als Teams ihn verantwortungsvoll prüfen können; dadurch kann die Review-Warteschlange zum neuen Engpass werden.

Einschränkung: Der Effekt muss lokal über PR-Größe, Reviewzeit, Rework und Defektdaten gemessen werden. Quellen: S-046, S-042, S-022 · Refresh-Risiko: hoch

F-037 - METHODISCHE GRUNDLAGE

Wartbarkeit kann nicht zuverlässig aus einer Demo oder einem einmaligen statischen Score abgeleitet werden; Folgeänderungen und Incident-Daten sind entscheidend.

Einschränkung: Langzeitdaten zu KI-generiertem Code sind noch jung und überwiegend vorläufig. Quellen: S-039, S-044, S-041 · Refresh-Risiko: hoch

F-038 - EMPIRISCHER BEFUND

AI-Unterstützung kann kurzfristige Leistung erhöhen, ohne dass das Verständnis der Codebasis im gleichen Maß wächst.

Einschränkung: Das Ausmaß hängt von Aufgabe, Vorerfahrung und Interaktionsmuster ab. Quellen: S-030, S-031, S-029 · Refresh-Risiko: mittel

F-039 - EMPIRISCHER BEFUND / PRAXISSYNTHESE

Vollständige Delegation kann Skill Formation und Debuggingfähigkeit schwächen; konzeptuelle Fragen, Vorhersagen und eigenes Erklären erhalten Lernen eher.

Einschränkung: Die Evidenz ist noch jung und überwiegend aus Lern- oder Experimentalsituationen. Quellen: S-029, S-035, S-032 · Refresh-Risiko: hoch

F-040 - PÄDAGOGISCHE SYNTHESE

Für Lernende sollte KI nicht nur Lösungen liefern, sondern Erklärungen einfordern, Fehlerdiagnosen ermöglichen und produktives Scheitern erhalten.

Einschränkung: Nicht jede Arbeitssituation ist eine Lernsituation; bei kritischen Kompetenzen bleibt Verständnis dennoch nötig. Quellen: S-037, S-036, S-033, S-010 · Refresh-Risiko: mittel

F-041 - METHODISCHE GRUNDLAGE

Ein Benchmarkwert misst ein festgelegtes Modell-Agent-Harness in einer bestimmten Umgebung und ist kein direkter Zuverlässigkeitswert für die eigene Codebasis.

Einschränkung: Lokale Eval-Sets und wiederholte Läufe sind erforderlich. Quellen: S-056, S-061, S-062, S-022 · Refresh-Risiko: hoch

F-042 - OFFIZIELLER BENCHMARK-AUDIT

SWE-bench Verified verlor 2026 als Frontier-Maßstab an Aussagekraft, nachdem ein Audit fehlerhafte Tests und Kontaminationshinweise fand.

Einschränkung: Der Audit untersuchte gezielt schwierige Fälle; das Dataset bleibt für bestimmte Analysen nutzbar, wenn Grenzen offengelegt werden. Quellen: S-058, S-057 · Refresh-Risiko: hoch

F-043 - OFFIZIELLER BENCHMARK-AUDIT

Auch SWE-Bench Pro wurde 2026 auditiert; OpenAI schätzte rund 30 Prozent gebrochene Aufgaben.

Einschränkung: Die Schätzung und Dataset-Version müssen bei jeder Nutzung genannt werden. Quellen: S-059 · Refresh-Risiko: hoch

F-044 - BENCHMARK-AUDIT

Zusätzliche Tests können Rankings von Coding-Agenten erheblich verändern, weil ursprüngliche Test-Suiten fehlerhafte Patches akzeptieren können.

Einschränkung: Der Befund gilt für untersuchte Aufgaben und Agenten, zeigt aber eine allgemeine Verifikationsgefahr. Quellen: S-064, S-045 · Refresh-Risiko: hoch

F-045 - METHODISCHE KLARSTELLUNG

METRs „Task-Completion Time Horizon“ ist die menschliche Dauer von Aufgaben, bei denen ein Agent eine bestimmte Erfolgswahrscheinlichkeit erreicht; sie ist nicht die Zeit, die der Agent autonom läuft.

Einschränkung: Die Aufgabe, der Scaffold und die menschliche Zeitschätzung prägen den Wert. Quellen: S-062, S-063 · Refresh-Risiko: hoch

F-046 - AKTUELLER PRODUKTSTAND

Aktuelle Coding-Werkzeuge unterscheiden sich in IDE-, Terminal-, Cloud-, Sandbox-, Netzwerk-, Freigabe- und Teamfunktionen; Produktnamen und Details ändern sich schnell.

Einschränkung: Vor Veröffentlichung oder Beschaffung müssen Funktionen und Vertragsbedingungen erneut geprüft werden. Quellen: S-088, S-093, S-097, S-100 · Refresh-Risiko: hoch

F-047 - ENGINEERING-SYNTHESE

Ein robuster Entwicklungsprozess sollte werkzeug- und modellagnostisch bleiben: Anforderungen, Repository, Tests, Build, CI, Security und Betrieb dürfen nicht von einem einzelnen Anbieter abhängen.

Einschränkung: Anbieterfunktionen können trotzdem gezielt genutzt werden. Quellen: S-065, S-075, S-076, S-077 · Refresh-Risiko: mittel

F-048 - GOVERNANCE- UND ENGINEERING-GRUNDSATZ

Produktiver KI-Code benötigt einen benannten menschlichen oder organisatorischen Owner, der Architektur, Freigabe, Betrieb, Incident Response und Stilllegung verantwortet.

Einschränkung: Die Rollenverteilung hängt von Teamgröße und Risiko ab. Quellen: S-022, S-065, S-080, S-081 · Refresh-Risiko: mittel

F-049 - RISIKOBASIERTE SCHLUSSFOLGERUNG

Für hochriskante, personenbezogene, finanzielle, medizinische oder sicherheitskritische Funktionen reicht „funktioniert bei mir“ grundsätzlich nicht als Freigabekriterium.

Einschränkung: Konkrete Rechts- und Branchenpflichten sind in den Dossiers 1 bis 5 und 10 zu prüfen. Quellen: S-103, S-104, S-105, S-067 · Refresh-Risiko: mittel

F-050 - EIGENE SYNTHESE AUS DEN GENANNTEN QUELLEN

Die stärkste praktische Mindestregel lautet: Kein produktiver Merge von Code, dessen Zweck, relevante Risiken und Prüfnachweise niemand erklären und verantworten kann.

Einschränkung: Bei wegwerfbaren, isolierten Experimenten kann der Prüfmaßstab bewusst niedriger sein. Quellen: S-065, S-006, S-029, S-058, S-090 · Refresh-Risiko: mittel

Methodik, Evidenzhierarchie und Recherchegrenzen

Recherchefrage

Untersucht wurde nicht nur, ob Modelle Code erzeugen können. Die zentrale Frage lautete: Unter welchen Bedingungen entsteht aus KI-generiertem Code ein fachlich korrektes, verständliches, sicheres, wartbares und betreibbares Softwaresystem? Dafür wurden Forschung zu Mensch-KI-Interaktion, Produktivität, Lernen, Softwarequalität, Sicherheit, Benchmarks und aktuelle offizielle Werkzeugdokumentation zusammengeführt.

Evidenzhierarchie

Zentrale Grenzen

Das Forschungsfeld ist sehr jung. Viele 2026er Arbeiten sind Preprints. Werkzeuge und Modelle verändern sich schneller als klassische Begutachtungszyklen. Produktivitätsstudien messen unterschiedliche Einheiten - Zeit, erledigte Tasks, akzeptierte Vorschläge, Tests oder Selbstauskünfte. Repository-Mining kann KI-Nutzung nur erkennen, wenn sie in Metadaten, Text oder Toolspuren sichtbar ist. Benchmarks messen stets Modell plus Agenten-Harness und Testorakel. Aktuelle Produktdokumentation beschreibt Funktionen, beweist aber nicht deren Qualität im eigenen Projekt. ^{[S-007, S-012, S-022, S-058, S-059]}

Abgrenzung zu den Dossiers 1 bis 10

Dieses Dossier behandelt technische und arbeitspraktische Fragen. Datenschutz, AI Act, Urheberrecht, Haftung, Governance, allgemeiner ROI, Grundlagen, Automatisierung, Arbeitsmarkt und Missbrauch werden nur an den notwendigen Schnittstellen angesprochen. Vor realer Produktnutzung sind die jeweiligen Spezialdossiers zusätzlich anzuwenden.

Begriffe und drei Arbeitsmodi

Arbeitsmodus A: Enges Vibe Coding

Der Mensch beschreibt Absichten in natürlicher Sprache, probiert das Ergebnis aus und delegiert Fehlerkorrekturen erneut an das Modell. Code wird nur grob oder gar nicht gelesen. Dieses Vorgehen kann für wegwerfbare Prototypen erstaunlich leistungsfähig sein. Es ist jedoch riskant, sobald Fehler nicht sichtbar sind, Daten dauerhaft gespeichert werden oder Dritte von der Funktion abhängen. ^{[S-001, S-003, S-002]}

Arbeitsmodus B: Professionell KI-gestützte Softwareentwicklung

Die KI erzeugt oder verändert Code, aber der Mensch besitzt Architektur, Anforderungen, Teststrategie und Betriebsverantwortung. Änderungen laufen über Repository, Branch, Diff, Review und CI. Der Assistent beschleunigt Routinearbeit, Suche, Erklärungen, Testentwürfe und Refactoring, ohne selbst die Freigabeinstanz zu sein. ^{[S-013, S-008, S-004, S-065]}

Arbeitsmodus C: Agentische Entwicklung

Ein Coding-Agent analysiert Repositories, plant, bearbeitet mehrere Dateien, führt Befehle und Tests aus und kann Pull Requests oder andere Artefakte erzeugen. Der Leistungsgewinn kommt aus Werkzeugzugriff und längeren Schleifen; das Risiko wächst mit Rechten, Netzwerk und externer Aktionsfähigkeit. Daher sind Sandbox, Least Privilege, Approval Gates und nachvollziehbare Traces Teil des Systems, nicht optionale Zusätze. ^{[S-088, S-093, S-097, S-100, S-090]}

Was Coding-Modelle und Coding-Agenten tatsächlich tun

Ein Sprachmodell erzeugt zunächst wahrscheinlich passende Token. Coding-Fähigkeit entsteht aus Trainingsmustern, In-Context-Informationen, Post-Training und Werkzeugnutzung. Ein Agent erweitert dieses Modell um Dateioperationen, Shell, Tests, Suche, Browser, Git und externe Tools. Deshalb ist ein Agentenergebnis immer das Resultat eines Gesamtsystems: Modell, Systemprompt, Kontextauswahl, Tooldefinitionen, Berechtigungen, Umgebung, Schleifenlogik und Abbruchbedingungen. ^{[S-115, S-116, S-089, S-093, S-085]}

Das Modell besitzt kein verlässliches internes Signal dafür, dass eine konkrete Bibliotheksversion, API oder lokale Geschäftsregel stimmt. RAG, Repository-Suche und Tools können die Evidenz verbessern, erzeugen aber neue Fehlerquellen: falsches Retrieval, veraltete Dokumentation, übersehene Dateien oder unzuverlässige Toolausgaben. Lange Kontextfenster garantieren zudem nicht, dass relevante Informationen an jeder Position gleich gut genutzt werden. ^{[S-123, S-124, S-049, S-008]}

Der reale Arbeitsablauf: Absicht, Kontext, Code, Prüfung und Betrieb

Der vollständige Wertstrom

Der häufigste Denkfehler ist, die Implementierungsphase mit dem Gesamtprojekt gleichzusetzen. KI drückt die Kosten der Codeerzeugung. Dadurch werden vorher versteckte Kosten sichtbarer: klare Anforderungen, Testdaten, Integrationen, Security, Deployment, Support und Wartung. Je schneller Code entsteht, desto wichtiger wird ein System, das schlechte Änderungen billig verwirft. ^{[S-022, S-023, S-004, S-046]}

Prompt ist nicht Spezifikation

Ein Prompt kann eine Aufgabe initiieren, ist aber häufig flüchtig, unvollständig und schwer versionierbar. Für produktive Systeme sollten dauerhafte Anforderungen in Repository-Artefakten liegen: README, Architekturregeln, Schnittstellenverträge, Akzeptanzbeispiele, Tests, ADRs und Sicherheitsvorgaben. Produktdokumentationen mehrerer Anbieter unterstützen Projektanweisungen und konfigurierbare Policies; ihre Wirksamkeit hängt jedoch davon ab, ob die Informationen aktuell, kurz, auffindbar und widerspruchsfrei sind. ^{[S-095, S-097, S-089, S-004]}

Produktivität: Gewinne, Gegenbefunde und Messfehler

Warum die Prozentwerte nicht addierbar sind

Die Studien untersuchen nicht dasselbe Produkt. Autocomplete, Chat, IDE-Agent und Cloud-Agent unterscheiden sich. Ebenso unterscheiden sich Aufgaben, Testbarkeit, Codebasiskenntnis und Erfolgsmaß. Ein Unternehmen sollte deshalb keinen externen Durchschnittswert als Business Case verwenden, sondern eigene Aufgabenklassen randomisiert oder gestaffelt messen. ^{[S-015, S-016, S-017, S-012, S-022]}

Lokale Produktivitätsformel

Nettonutzen je Änderung = eingesparte aktive Entwicklungszeit - zusätzliche Prompt-/Wartezeit - Review - Rework - Incident-/Wartungserwartung + Qualitäts- oder Durchsatzwert.

Die Formel ist bewusst breiter als „Zeit im Editor“. Wird eine Änderung schneller erstellt, aber später häufiger zurückgewiesen, entsteht kein gleichermaßen positiver Produktivitätsgewinn. Das gleiche gilt, wenn Senior-Review zur knappen Ressource wird oder Junioren weniger Systemwissen aufbauen.

Messdesign

Nicht-Programmierer, Anfänger und Profis

Nicht-Programmierer besitzen häufig starkes Domänenwissen und können deshalb sinnvolle Werkzeuge spezifizieren. Ihr Risiko liegt weniger in der Idee als in unsichtbaren technischen Eigenschaften: Authentisierung, Datenzugriff, Race Conditions, Migration, Browser-/Geräteunterschiede und Betrieb. Anfänger erkennen Syntax und offensichtliche Fehler, aber oft noch nicht Architektur- oder Sicherheitsfolgen. Profis können schneller prüfen, sind jedoch nicht immun gegen Übervertrauen, Kontextfehler oder Reviewüberlastung. ^{[S-006, S-005, S-047, S-004]}

Die wichtigste Grenze für Nicht-Programmierer ist nicht eine bestimmte Programmiersprache. Sie ist der Punkt, an dem ein Fehler für Dritte, Daten, Geld oder Sicherheit relevant wird und niemand im Projekt die Ursache zuverlässig diagnostizieren kann.

Kompetenzaufbau, Verständnis und kognitive Schuld

AI-Unterstützung kann Lernen erleichtern, wenn sie Feedback, Beispiele und Erklärungen liefert. Sie kann Lernen umgehen, wenn sie den gesamten Lösungsweg übernimmt. Die Skill-Formation-Studie von Shen und Tamkin fand im Mittel schlechteres Konzeptverständnis, Code-Lesen und Debugging unter KI-Unterstützung. Entscheidend waren die Interaktionsmuster: Konzeptfragen und aktives Untersuchen waren günstiger als vollständige Delegation. ^{[S-029, S-037, S-035]}

Praktiken gegen Verständnisverlust

Die entstehende Schuld ist nicht nur „technisch“. Epistemische oder Comprehension Debt entsteht, wenn Software existiert, aber Gründe, Annahmen und Wirkzusammenhänge im Team fehlen. Diese Schuld wird erst bei Incident, Audit, Anbieterwechsel oder ungewöhnlicher Änderung sichtbar. ^{[S-032, S-030, S-033]}

Anforderungen und Context Engineering

Modelle können unklare Anforderungen nicht zuverlässig in die richtige Geschäftsentscheidung verwandeln. Sie wählen eine plausible Interpretation. Je größer die Delegation, desto stärker wirkt eine falsche Annahme. Professionelles Context Engineering bedeutet deshalb nicht, das gesamte Repository in ein Kontextfenster zu kopieren, sondern relevante Regeln maschinen- und menschenlesbar zu strukturieren. ^{[S-004, S-008, S-123, S-124]}

Ein guter Auftrag enthält: Ziel, Kontext, betroffene Grenze, vorhandene Beweise, Akzeptanzkriterien, Nicht-Ziele, erlaubte Tools und gewünschte Prüfnachweise. Ein langer Prompt ohne diese Struktur ist keine belastbare Spezifikation.

Architektur: Greenfield, Brownfield und Systemgrenzen

Greenfield-Arbeit bietet wenige Altlasten und schnelle sichtbare Fortschritte. Gerade deshalb kann unkontrollierter Code früh falsche Grundentscheidungen festschreiben: Datenmodell, Authentisierung, Mandantentrennung, Fehlersemantik und Deployment. Brownfield-Arbeit ist langsamer, weil vorhandene Verträge respektiert werden müssen. Coding-Agenten benötigen dort nicht nur Quellcode, sondern Tests, Logs, Konfiguration, Historie und Domänenwissen. ^{[S-004, S-031, S-030, S-026]}

Eine Architekturentscheidung ist dann agententauglich, wenn sie explizit genug ist, dass eine Änderung automatisch geprüft werden kann. „Sauber“, „modern“ oder „skalierbar“ sind keine Akzeptanzkriterien.

Tests, Verifikation und Code Review

Die Auditkrise bei SWE-bench ist für die Praxis lehrreich: Selbst professionell kuratierte Test-Suiten können korrekte Lösungen ablehnen, falsche akzeptieren oder eine unterbestimmte Aufgabe nur über die historische Goldimplementierung bewerten. Tests bleiben zentral, müssen aber als unvollständige Messinstrumente behandelt werden. ^{[S-058, S-059, S-064]}

Unabhängigkeit der Prüfung

Code Review sollte nicht nur fragen, ob der Patch kompiliert. Zu prüfen sind Zweck, Annahmen, Datenfluss, Rechte, Fehlerfälle, Dependencies, Migration, Observability und Rückweg. Große KI-generierte PRs sind besonders problematisch, weil der menschliche Reviewer den Kontext erst rekonstruieren muss. Kleine, reversible Änderungen verbessern sowohl Reviewqualität als auch Lernwert. ^{[S-042, S-046, S-075, S-076]}

Codequalität, Wartbarkeit und technische Schuld

Die aktuelle Forschung deutet nicht darauf hin, dass jede KI-Zeile schlechte Qualität hat. Sie zeigt vielmehr ein Risiko systematischer Schuld: plausible Duplikation, unnötige Komplexität, fehlende Tests, architekturfremde Abhängigkeiten und Entscheidungen, die niemand bewusst getroffen hat. Die große 2026er Mining-Studie ist wichtig, bleibt aber ein Preprint und erfasst nur explizit markierte AI-Commits. Ihre Aussage ist daher ein Warnsignal, kein universeller Fehlerprozentsatz. ^{[S-039, S-040, S-043]}

Wartbarkeit muss über Folgeänderungen gemessen werden: Wie schnell kann ein anderer Mensch den Code verstehen? Wie oft wird dieselbe Stelle nachbearbeitet? Wie viele Defekte entkommen? Wie häufig muss die KI den eigenen Code erneut umschreiben? Ein einmaliger Qualitätscheck reicht nicht.

Security, Supply Chain und Geheimnisse

AI-Code kann klassische Schwachstellen enthalten: fehlende Eingabevalidierung, unsichere Deserialisierung, fehlerhafte Zugriffskontrolle, Injection, Race Conditions oder Kryptografiefehler. Das besondere Risiko liegt in Geschwindigkeit und Vertrauen. Eine kontrollierte Studie fand weniger sichere Lösungen in vier von fünf Aufgaben und gleichzeitig höhere Zuversicht der KI-Nutzer. ^{[S-047, S-048, S-067]}

Supply Chain

Generierte Paketnamen müssen verifiziert werden. Package Hallucinations sind dokumentiert und können von Angreifern für Dependency Confusion oder Typosquatting ausgenutzt werden. Der Mindestprozess umfasst Registry-Prüfung, Projekt-/Maintainerprüfung, Lockfile, SBOM, Vulnerability Scan und idealerweise Build-Provenienz. ^{[S-049, S-054, S-071, S-073, S-072]}

Secrets und Daten

Agenten benötigen für realistische Aufgaben oft Zugang zu Repositories, Paketregistern, Cloud-Umgebungen oder Testdiensten. Diese Zugänge dürfen nicht als dauerhafte Vollzugriffsschlüssel im Prompt oder Projekttext liegen. Kurzlebige Identitäten, minimale Scopes, getrennte Testkonten und Auditlogs begrenzen Schäden. Auch automatisch hochgeladene Logs, Crash-Dumps und Chatverläufe können Secrets oder personenbezogene Daten enthalten.

Secure by Design

NIST SSDF, OWASP ASVS, CISA Secure by Design und der EU Cyber Resilience Act machen deutlich, dass Sicherheit in Anforderungen, Entwicklung, Auslieferung und Wartung eingebaut werden muss. KI kann diese Kontrollen beschleunigen, darf aber nicht selbst entscheiden, dass sie erfüllt sind. ^{[S-065, S-067, S-083, S-103]}

Agentenrechte, Sandbox, Netzwerk und MCP

Ein Chat ohne Tools kann falschen Text liefern. Ein Agent mit Shell, Dateisystem, Browser, Git und Cloud-Zugang kann falsche Handlungen ausführen. Die Sicherheitsarchitektur muss daher die Aktion begrenzen, nicht nur die Antwort filtern. Offizielle Coding-Agenten verwenden unterschiedliche Kombinationen aus Read-only-Default, expliziten Freigaben, Sandboxen, isolierten Cloud-Umgebungen und Netzwerkregeln. ^{[S-090, S-094, S-098, S-100]}

MCP löst ein Integrationsproblem, kein Vertrauensproblem. Ein Client kann Tools entdecken und aufrufen; er muss dennoch prüfen, welchem Server er vertraut, welche Ressourcen sichtbar sind, wie Tokens gebunden werden und ob Toolbeschreibungen manipuliert sind. Offizielle MCP-Sicherheitsguidance und die gemeinsame NSA-Leitlinie betonen Autorisierung, Token-Schutz und begrenzte Ressourcen. ^{[S-085, S-086, S-087]}

Indirekte Prompt Injection ist besonders gefährlich, weil der Angriff nicht in der Nutzeranweisung stehen muss. Eine präparierte README, ein Issue, eine Webseite oder Toolantwort kann den Agenten zu einer fremden Aktion bewegen. Netzwerkzugriff und schreibende Tools sollten deshalb getrennt freigegeben werden; sensible Aktionen benötigen eine Bestätigung, die nicht aus demselben potenziell kompromittierten Kontext stammt. ^{[S-050, S-051, S-052, S-091]}

Benchmarks und ihre Verfallsdaten

Coding-Benchmarks sind nützlich, aber leicht überinterpretiert. SWE-bench brachte reale GitHub-Issues in die Evaluation. SWE-Lancer ergänzte reale Freelance-Aufgaben. Terminal-Bench misst CLI-Aufgaben. METR modelliert den Zusammenhang zwischen Erfolgswahrscheinlichkeit und menschlicher Aufgabendauer. Keines dieser Verfahren misst direkt, ob ein Agent in Ihrem Unternehmen sichere, wartbare Software liefert. ^{[S-056, S-060, S-061, S-062]}

Die Audits von Verified und Pro zeigen eine Messkrise, aber nicht die Nutzlosigkeit aller Benchmarks. Die richtige Reaktion ist, Leaderboards durch lokale Eval-Sets zu ergänzen: eigene Repositories, echte Fehlerklassen, Wiederholung, unabhängige Review, Kosten und Sicherheitskontrollen. ^{[S-058, S-059, S-064, S-022]}

Werkzeuglandschaft am 8. August 2026

Die nachfolgende Einordnung beschreibt Funktionsklassen, keine Rangliste. Preise, Modellnamen, Quoten und Preview-Status ändern sich schnell und gehören in die Refresh-Liste.

Produktwahl sollte nicht mit Modellwerbung beginnen. Zuerst sind Repositoryzugriff, Datenklasse, Betriebsmodell, Identity, Netzwerk, Audit, Teamworkflow und Exit zu definieren. Danach lässt sich prüfen, welches Werkzeug die Anforderungen erfüllt.

Entscheidungsrahmen: Wann Vibe Coding vertretbar ist

Fünf Stoppsignale

• Niemand kann erklären, welche Daten wohin fließen und wer darauf zugreifen kann.
• Der Agent benötigt produktive Vollrechte, damit die Demo überhaupt funktioniert.
• Die Anwendung hat keine reproduzierbaren Tests, kein Backup oder keinen Rückweg.
• Eine Fehlentscheidung kann Menschen, Geld, Rechte oder Geschäftsgeheimnisse erheblich betreffen.
• Es gibt keinen benannten Menschen oder Dienstleister, der Fehler nach dem Launch behebt.

Vier gute Startfälle

• wegwerfbarer UI-Prototyp mit synthetischen Daten
• lokales Konvertierungs- oder Analyseskript auf Kopien
• regelbasierter interner Rechner mit klaren Tests
• kleine Erweiterung in einem gut getesteten Repository über Branch und Review

18 Forschungs- und Evidenzprofile

Vibe Coding als beobachtete Arbeitsweise

„Rolling the Dice“: Spektrum statt einheitlicher Methode

Großskalige IDE-Chat-Nutzung

Kontrolliertes Copilot-Experiment

Drei Unternehmens-Feldexperimente

METR-RCT mit erfahrenen Open-Source-Maintainern

METR-Update und Selektionsproblem

DORA 2025: KI als Organisationsverstärker

Skill Formation bei neuer Bibliothek

Comprehension-Performance Gap

Technische Schuld in 304.362 AI-Commits

Review als neuer Engpass

Sichere Codeerzeugung und Übervertrauen

Package Hallucinations

Prompt Injection gegen Coding-Agenten

SWE-bench Verified Audit

SWE-Bench Pro Audit

METR Task-Completion Time Horizons

18 Unternehmens- und Projektszenarien

Einseitige Marketing-Landingpage

Kontaktformular für ein eigenes Unternehmen

Interner Angebotsrechner

Kleines persönliches Dashboard

WordPress-Plugin für einen Kunden

CRM-Prototyp für fünf interne Nutzer

Öffentliche SaaS-Anwendung

Bewerber-Vorsortierung

Medizinische Dokumentation

Automatisches Löschen von Dateien

Agent mit E-Mail- und Kalenderzugriff

Automatischer Pull Request für Bugfix

Großes Refactoring in Legacy-System

Abhängigkeiten aktualisieren

Datenbankmigration

Einmaliges internes Skript

Open-Source-Beitrag

Kundenprojekt als Agenturleistung

36-stufiger Umsetzungsfahrplan

1. Problem und Risiko: Geschäftsproblem und erwarteten Nutzerwert in einem Satz definieren.
2. Problem und Risiko: Entscheiden, ob klassische Software, Konfiguration oder Regelwerk ohne KI genügt.
3. Problem und Risiko: Risikoklasse nach Daten, Geld, Gesundheit, Sicherheit, Öffentlichkeit und Reichweite bestimmen.
4. Problem und Risiko: Owner für Produkt, Technik, Daten, Sicherheit und Betrieb benennen.
5. Problem und Risiko: Minimalen Scope und explizite Nicht-Ziele formulieren.
6. Problem und Risiko: Akzeptanzkriterien als beobachtbare Beispiele und Grenzfälle festhalten.
7. Architektur und Umgebung: Architektur und Datenflüsse skizzieren, bevor produktiver Code erzeugt wird.
8. Architektur und Umgebung: Repository anlegen und Branch-/Merge-Regeln definieren.
9. Architektur und Umgebung: Reproduzierbare Entwicklungsumgebung oder Container einrichten.
10. Architektur und Umgebung: Secrets, Zugangsdaten und produktive Daten aus der Entwicklungsumgebung fernhalten.
11. Architektur und Umgebung: Coding-Agent zunächst read-only oder in einer Wegwerf-Sandbox einsetzen.
12. Architektur und Umgebung: Projektkontext in kurze, versionierte Anweisungen und Referenzdokumente aufteilen.
13. Implementierung: Eine kleine vertikale Funktionsscheibe statt der Gesamtanwendung beauftragen.
14. Implementierung: Agent zuerst Plan, Annahmen, betroffene Dateien und Teststrategie ausgeben lassen.
15. Implementierung: Unklare fachliche Annahmen vor der Implementierung entscheiden.
16. Implementierung: Änderungen in kleinen, thematisch geschlossenen Commits erzeugen.
17. Implementierung: Diff vollständig prüfen oder durch qualifizierte Person prüfen lassen.
18. Implementierung: Unit-, Integrations-, End-to-End- und Sicherheitsprüfungen risikobasiert ergänzen.
19. Implementierung: Negative Tests, Randwerte, Berechtigungsfehler und Wiederholungen abdecken.
20. Implementierung: Generierte Abhängigkeiten gegen Register, Herkunft, Lizenz und Wartungsstatus prüfen.
21. Qualität und Sicherheit: SBOM/Lockfile und Dependency-Scanning in den Build integrieren.
22. Qualität und Sicherheit: Statische Analyse, Linter, Typprüfung und Secret-Scanning automatisieren.
23. Qualität und Sicherheit: CI als verpflichtendes Merge-Gate konfigurieren.
24. Qualität und Sicherheit: Unabhängige fachliche Abnahme gegen Akzeptanzkriterien durchführen.
25. Qualität und Sicherheit: Bedrohungsmodell und Missbrauchsfälle vor externem Zugriff prüfen.
26. Qualität und Sicherheit: Berechtigungen des Agenten, von MCP-Servern und Deploy-Identitäten minimieren.
27. Qualität und Sicherheit: Staging mit realistischen, aber anonymisierten oder synthetischen Daten testen.
28. Betrieb und Skalierung: Last, Fehlerbehandlung, Timeouts, Retries und idempotentes Verhalten prüfen.
29. Betrieb und Skalierung: Backup, Restore, Migration und Rollback praktisch testen.
30. Betrieb und Skalierung: Logging, Monitoring, Alarmierung und SLOs definieren.
31. Betrieb und Skalierung: Datenschutz-, Urheber-, Haftungs- und Branchenprüfung mit den anderen Dossiers durchführen.
32. Betrieb und Skalierung: Verantwortliche Freigabe dokumentieren; keine Selbstfreigabe des Agenten.
33. Betrieb und Skalierung: Klein ausrollen, Telemetrie und Nutzerfeedback beobachten.
34. Betrieb und Skalierung: Rework, Defekte, Reviewzeit, Durchsatz und Incident-Zahlen als lokale Evidenz messen.
35. Betrieb und Skalierung: Agentenregeln, Modelle, Abhängigkeiten und Sicherheitsannahmen regelmäßig aktualisieren.
36. Betrieb und Skalierung: Stilllegung, Datenexport und Anbieterwechsel bereits vor Skalierung planen.

Der Fahrplan ist bewusst technologieagnostisch. Ein kleines internes Skript benötigt nicht jede Maßnahme in gleicher Tiefe. Wer einzelne Schritte auslässt, sollte dies jedoch als bewusste, risikobasierte Entscheidung dokumentieren - nicht als Folge davon, dass die KI das Thema nicht erwähnt hat.

KPI- und Evaluationsrahmen

Eine Einführung ist nur dann wirtschaftlich und fachlich bewertbar, wenn vorab eine Baseline und eine eindeutige Arbeitseinheit festgelegt werden. Die Metriken müssen Geschwindigkeit, Qualität, Verständnis, Betrieb und Kosten gemeinsam abbilden. Einzelwerte wie erzeugte Codezeilen oder angenommene Vorschläge sind leicht zu optimieren und können den tatsächlichen Wert verschlechtern.

DORA und SPACE liefern geeignete Ausgangspunkte, weil sie Produktivität als Systemmerkmal verstehen. Für KI-Programmierung sollte zusätzlich erfasst werden, welche Änderungen wesentlich von einem Assistenten erzeugt wurden, welches Werkzeug und welcher Modus verwendet wurde und wie viel menschliche Prüfzeit anfiel. Diese Kennzeichnung dient der Evaluation, nicht der individuellen Leistungskontrolle. ^{[S-023, S-024, S-022, S-046]}

Minimaler Evaluationsaufbau

• Vier bis acht Wochen Baseline mit derselben Arbeitseinheit erheben.
• Geeignete Aufgaben zufällig oder nach transparenten Regeln mit und ohne KI vergleichen.
• Modell, Tool, Version, Policies, Rechte und Kontextartefakte dokumentieren.
• Zeit nicht nur am Editor, sondern bis zur Abnahme und nachgelagertem Rework messen.
• Qualität durch unabhängige Reviewer und produktive Ergebnisdaten prüfen.
• Lern-, Verständnis- und Bus-Factor-Risiken separat erfassen.
• Nach 30, 90 und 180 Tagen prüfen, ob Wartungskosten den Anfangsgewinn verändern.

20 Mythenprüfungen

„„Mit KI kann jeder programmieren.““

„„Wer gut promptet, braucht kein Informatikwissen.““

„„Wenn die App läuft, ist sie fertig.““

„„KI macht Entwickler immer schneller.““

„„Erfahrene Entwickler profitieren am meisten.““

„„Selbstberichtete Zeitersparnis ist ein Produktivitätsnachweis.““

„„Mehr generierter Code bedeutet mehr Output.““

„„Tests beweisen, dass der Code korrekt ist.““

„„Der Agent hat Tests geschrieben, also hat er sich unabhängig geprüft.““

„„Eine Sandbox macht einen Agenten sicher.““

„„Internet an verbessert nur die Recherche.““

„„Open-Source-Pakete aus einem KI-Vorschlag kann man einfach installieren.““

„„MCP ist eine sichere Standardverbindung.““

„„KI-Code ist objektiv schlechter als menschlicher Code.““

„„KI-Code ist objektiv besser, weil das Modell mehr Beispiele kennt.““

„„Ein hoher SWE-bench-Wert beweist Produktionsreife.““

„„Der METR-Zeithorizont sagt, wie lange ein Agent selbstständig arbeitet.““

„„Vibe Coding ist nur für Nicht-Programmierer.““

„„Verständnis ist unwichtig, solange der Agent Fehler reparieren kann.““

„„Man kann eine Kundenanwendung bauen und Wartung später klären.““

20 offene Forschungs- und Praxisfragen

Die folgenden Punkte sind nicht bloß Wissenslücken einzelner Unternehmen. Mehrere betreffen ein Forschungsfeld, dessen Werkzeuge, Nutzergruppen und Messmethoden sich schneller ändern als Langzeitstudien abgeschlossen werden können.

Wie verändern sich Produktivitätseffekte, wenn 2026er Agenten in denselben RCT-Designs wie frühe Copilots getestet werden?

Warum wichtig: Neue Werkzeuggenerationen können frühere Ergebnisse umkehren. Beobachtungsbedarf: Replikation mit identischen Aufgaben, offenen Traces und aktuellen Modellen.

Welche Effekte bleiben nach sechs, zwölf und 24 Monaten bestehen, wenn Lern-, Wartungs- und Reviewkosten einbezogen werden?

Warum wichtig: Kurzfristige Zeitgewinne können durch Lern- und Wartungskosten verschwinden. Beobachtungsbedarf: Längsschnittdaten über 6, 12 und 24 Monate.

Wie lässt sich der Anteil KI-generierter Änderungen verlässlich messen, wenn Commit-Metadaten fehlen?

Warum wichtig: Ohne Attribution sind Repository-Mining und interne Evaluation verzerrt. Beobachtungsbedarf: Standardisierte, datenschutzgerechte Provenance- und Commit-Metadaten.

Welche lokalen Repository-Eigenschaften sagen voraus, ob ein Coding-Agent beschleunigt oder verlangsamt?

Warum wichtig: Lokaler Kontext entscheidet über Nutzen und lässt sich nicht aus Modellrankings ableiten. Beobachtungsbedarf: Repository-Metriken, Aufgabeigenschaften und kontrollierte Feldversuche.

Wie groß ist die Verständnislücke zwischen funktionierendem Output und tatsächlicher mentaler Modellbildung in der Praxis?

Warum wichtig: Funktionierende Software kann mit geringer mentaler Modellbildung entstehen. Beobachtungsbedarf: Verständnistests, Diagnoseaufgaben und reale Folgeänderungen.

Welche Interaktionsmuster erhalten Debugging- und Architekturkompetenz über längere Zeit?

Warum wichtig: Kompetenzverlust wäre ein langfristiger Preis kurzfristiger Beschleunigung. Beobachtungsbedarf: Lern- und Arbeitsstudien mit stabilen Interaktionsmustern.

Wie müssen Prüf- und Lernsysteme aussehen, damit Nicht-Programmierer Risiken realistisch erkennen?

Warum wichtig: Selbstüberschätzung erhöht Risiko bei öffentlichen oder kundenbezogenen Anwendungen. Beobachtungsbedarf: Kalibrierungsstudien und realistische Sicherheits-/Debugging-Aufgaben.

Wann werden Agentenreviews zu einem belastbaren zweiten Prüfer statt zu einer korrelierten Wiederholung?

Warum wichtig: Korrelierte Prüfer können dieselbe falsche Annahme bestätigen. Beobachtungsbedarf: Unabhängigkeit von Modellen, Prompts, Testorakeln und Daten messen.

Welche Kombination aus unabhängigen Modellen, statischer Analyse und Tests reduziert gemeinsame Blindstellen am stärksten?

Warum wichtig: Mehr Prüfschichten sind nur sinnvoll, wenn ihre Fehler nicht identisch sind. Beobachtungsbedarf: Ablationsstudien mit Modell-, Tool- und Methodenvielfalt.

Wie misst man technische Schuld KI-generierter Änderungen über Jahre und nicht nur beim Commit?

Warum wichtig: Technische Schuld zeigt sich oft erst bei späteren Änderungen und Incidents. Beobachtungsbedarf: Mehrjährige Repository- und Betriebsdaten.

Welche Risikoklassen rechtfertigen vollständig autonome Merge- oder Deploymentrechte?

Warum wichtig: Autonomie verändert den Schadensradius stärker als reine Codegenerierung. Beobachtungsbedarf: Risikoklassen, Incident-Daten und formale Freigabekriterien.

Wie wirksam sind aktuelle Prompt-Injection-Abwehren unter adaptiven Angriffen und realen Toolrechten?

Warum wichtig: Indirekte Prompt Injection bleibt ein Grundproblem agentischer Systeme. Beobachtungsbedarf: Adaptive Red-Team-Tests mit realistischen Tools und Rechten.

Welche MCP-Implementierungsfehler treten in produktiven Entwicklungsumgebungen am häufigsten auf?

Warum wichtig: MCP erweitert die Angriffsfläche durch neue Server, Tokens und Toolbeschreibungen. Beobachtungsbedarf: Incident-Daten, Audits und standardisierte Conformance-Tests.

Wie wirken sich AI-generierte Abhängigkeiten langfristig auf Supply-Chain-Risiken und Lizenzcompliance aus?

Warum wichtig: Erfundene oder ungeprüfte Pakete erzeugen Sicherheits- und Lizenzrisiken. Beobachtungsbedarf: SBOM-/SCA-Daten und Langzeitbeobachtung von Abhängigkeitsentscheidungen.

Wie stabil sind Benchmark-Rankings über Harnesses, Seeds, Budgets und Infrastrukturvarianten?

Warum wichtig: Scores können durch Scaffold, Seed, Budget und Infrastruktur verschoben werden. Beobachtungsbedarf: Mehrfachläufe und standardisierte Harness-Reporting-Pflichten.

Wie können Benchmarks korrekt bewerten, wenn mehrere funktional richtige Implementierungen existieren?

Warum wichtig: Enge Testorakel können korrekte Lösungen ablehnen oder falsche akzeptieren. Beobachtungsbedarf: Mehrere Orakel, menschliche Audits und metamorphe Tests.

Welche Metriken erfassen Teamproduktivität, Reviewengpässe und Wissensverteilung besser als Einzeloutput?

Warum wichtig: Einzeloutput kann Reviewlast und Wissensverlust im Team verdecken. Beobachtungsbedarf: Teammetriken nach SPACE/DORA plus Wissens- und Reviewindikatoren.

Wie verändert KI die Rollen von Junior-, Senior- und Staff-Engineers in kleinen und großen Unternehmen?

Warum wichtig: Rollenprofile könnten sich schneller ändern als Ausbildungswege. Beobachtungsbedarf: Berufs-, Aufgaben- und Kompetenzdaten über mehrere Jahre.

Welche Vertrags-, Haftungs- und Versicherungsmodelle entstehen für mit Coding-Agenten entwickelte Kundenprodukte?

Warum wichtig: Unklare Verantwortung kann Markteinführung und Schadensregulierung erschweren. Beobachtungsbedarf: Vertrags-, Versicherungs- und Rechtsprechungsentwicklung beobachten.

Wie können kleine Unternehmen professionellen Betrieb sicherstellen, wenn die Erstellung extrem billig, Wartung aber dauerhaft bleibt?

Warum wichtig: Niedrige Erstellungskosten können eine Welle schlecht gewarteter Software auslösen. Beobachtungsbedarf: TCO-, Ausfall-, Support- und Stilllegungsdaten kleiner Unternehmen.

50 buchrelevante Faktenkarten

Faktenkarte F-001

Faktenkarte F-002

Faktenkarte F-003

Faktenkarte F-004

Faktenkarte F-005

Faktenkarte F-006

Faktenkarte F-007

Faktenkarte F-008

Faktenkarte F-009

Faktenkarte F-010

Faktenkarte F-011

Faktenkarte F-012

Faktenkarte F-013

Faktenkarte F-014

Faktenkarte F-015

Faktenkarte F-016

Faktenkarte F-017

Faktenkarte F-018

Faktenkarte F-019

Faktenkarte F-020

Faktenkarte F-021

Faktenkarte F-022

Faktenkarte F-023

Faktenkarte F-024

Faktenkarte F-025

Faktenkarte F-026

Faktenkarte F-027

Faktenkarte F-028

Faktenkarte F-029

Faktenkarte F-030

Faktenkarte F-031

Faktenkarte F-032

Faktenkarte F-033

Faktenkarte F-034

Faktenkarte F-035

Faktenkarte F-036

Faktenkarte F-037

Faktenkarte F-038

Faktenkarte F-039

Faktenkarte F-040

Faktenkarte F-041

Faktenkarte F-042

Faktenkarte F-043

Faktenkarte F-044

Faktenkarte F-045

Faktenkarte F-046

Faktenkarte F-047

Faktenkarte F-048

Faktenkarte F-049

Faktenkarte F-050

Glossar

Acceptance Criteria

Beobachtbare Bedingungen, die erfüllt sein müssen, damit eine Änderung fachlich angenommen wird.

Agent

System, das ein Modell in einer Schleife mit Werkzeugen, Zuständen und Regeln handeln lässt.

Agent Harness

Gesamtheit aus Systemprompt, Tools, Speicher, Schleifenlogik, Budgets, Umgebung und Evaluator um ein Modell.

AI-assisted Software Engineering

Softwareentwicklung, bei der KI unterstützt, während Menschen Spezifikation, Architektur, Prüfung und Verantwortung behalten.

Architecture Decision Record (ADR)

Kurzes versioniertes Dokument, das eine Architekturentscheidung, Gründe und Folgen festhält.

Artifact

Erzeugtes Entwicklungsobjekt wie Quellcode, Build, Paket, Testbericht oder SBOM.

Autonomie

Grad, in dem ein Agent ohne einzelne menschliche Freigaben plant und handelt.

Backlog

Priorisierte Sammlung noch nicht umgesetzter Anforderungen, Fehler und technischer Aufgaben.

Benchmark

Standardisierte Aufgabensammlung und Auswertungslogik zum Vergleich von Systemen.

Branch

Abzweigung im Versionskontrollsystem, auf der Änderungen isoliert entwickelt werden.

Brownfield

Entwicklung in einer bestehenden Codebasis mit Historie, Abhängigkeiten und impliziten Regeln.

Build

Reproduzierbarer Prozess, der Quellcode in ausführbare oder auslieferbare Artefakte überführt.

CD

Continuous Delivery/Deployment; automatisierte Bereitstellung bis hin zum Produktivsystem.

CI

Continuous Integration; automatische Integration und Prüfung von Änderungen.

Code Review

Systematische Prüfung einer Änderung durch Menschen und/oder Werkzeuge vor Integration.

Code Smell

Muster, das auf potenzielle Wartbarkeits- oder Designprobleme hinweist, ohne zwingend ein Fehler zu sein.

Commit

Versionierter Satz zusammengehöriger Änderungen mit Identität, Zeitpunkt und Beschreibung.

Comprehension Debt

Verständnislücke zwischen vorhandener Software und dem Wissen der verantwortlichen Personen.

Context Engineering

Gezielte Gestaltung der Informationen, Regeln, Beispiele und Werkzeuge, die ein Modell für eine Aufgabe erhält.

Context Window

Maximale Menge an Eingabe- und Ausgabetokens, die ein Modell in einer Interaktion verarbeiten kann.

Definition of Done

Teamweite Kriterien, die jede abgeschlossene Änderung erfüllen muss.

Dependency

Externe Bibliothek, Laufzeit, Dienst oder Komponente, von der eine Anwendung abhängt.

Deterministisch

Bei gleicher Eingabe und gleichem Zustand reproduzierbar gleiches Ergebnis liefernd.

Dev Container

Versionierte Containerbeschreibung für eine reproduzierbare Entwicklungsumgebung.

Diff

Darstellung der Unterschiede zwischen zwei Versionen einer Datei oder Codebasis.

Dry Run

Probeausführung, die geplante Aktionen zeigt, ohne die eigentliche Veränderung vorzunehmen.

End-to-End-Test

Test eines vollständigen Nutzer- oder Systemablaufs über mehrere Komponenten.

Ephemeral Environment

Kurzlebige, nach einer Aufgabe verworfene Ausführungsumgebung.

Epistemic Debt

Schuld aus nicht aufgebautem Wissen, fehlenden Begründungen und unverständlichen Entscheidungen.

Feature Flag

Schalter, mit dem Funktionen kontrolliert aktiviert, deaktiviert oder stufenweise ausgerollt werden.

Greenfield

Neuentwicklung ohne bestehende Codebasis und historische Kompatibilitätszwänge.

Halluzination

Plausibel wirkende, aber nicht verlässlich aus Daten oder Werkzeugen gestützte Ausgabe.

Human-in-the-loop

Menschliche Entscheidung oder Prüfung innerhalb eines automatisierten Ablaufs.

Idempotenz

Eigenschaft, dass wiederholte Ausführung denselben Endzustand erzeugt und keine unerwünschten Dopplungen verursacht.

Incident

Ereignis, das Verfügbarkeit, Sicherheit, Integrität oder Vertraulichkeit beeinträchtigt.

Integrationstest

Prüfung des Zusammenspiels mehrerer Komponenten oder Dienste.

Issue

Dokumentierte Aufgabe, Fehlerbeschreibung oder Änderungsanforderung in einem Repository.

Least Privilege

Prinzip, nur die minimal notwendigen Rechte, Ressourcen und Zeiträume zu gewähren.

Legacy-System

Bestehendes, oft geschäftskritisches System mit historisch gewachsenen Strukturen und Abhängigkeiten.

Linter

Werkzeug, das Quellcode auf Stil-, Qualitäts- und bestimmte Fehlermuster prüft.

Lockfile

Datei, die konkrete Versionen und Auflösungen von Abhängigkeiten festschreibt.

MCP

Model Context Protocol; Protokoll zur Verbindung von KI-Anwendungen mit Ressourcen und Tools.

Merge

Zusammenführen eines Branches oder Änderungssatzes in eine Zielversion.

Migration

Kontrollierte Veränderung von Daten, Schema, Schnittstellen oder Infrastruktur zwischen Versionen.

Mock

Kontrollierter Ersatz einer realen Abhängigkeit für Tests.

Monitoring

Fortlaufende Beobachtung von Zustand, Leistung, Fehlern und Sicherheitsereignissen.

Observability

Fähigkeit, internen Systemzustand aus Logs, Metriken und Traces zu verstehen.

On-Premises

Betrieb in eigener oder kontrollierter Infrastruktur statt als externer Cloud-Dienst.

Package Hallucination

Nennung einer nicht existierenden Softwareabhängigkeit durch ein Modell.

Patch

Kompakter Satz von Quellcodeänderungen zur Behebung oder Erweiterung.

Penetrationstest

Autorisierte Sicherheitsprüfung durch aktive Angriffssimulation.

Pipeline

Automatisierte Folge von Build-, Test-, Prüf- und Deployment-Schritten.

Prompt Injection

Angriff, bei dem fremde Inhalte das Verhalten eines Modells oder Agenten entgegen der eigentlichen Absicht steuern.

Pull Request

Formalisierter Vorschlag, Änderungen in einen Zielbranch zu übernehmen und zu prüfen.

Refactoring

Veränderung interner Codegestaltung ohne beabsichtigte Änderung des externen Verhaltens.

Regression

Unbeabsichtigte Verschlechterung oder Wiederkehr eines Fehlers nach einer Änderung.

Repository

Versionierter Speicherort für Code, Konfiguration, Dokumentation und Entwicklungsartefakte.

Rollback

Rückkehr zu einem vorherigen stabilen Software- oder Datenstand.

Sandbox

Abgegrenzte Umgebung mit beschränktem Zugriff auf Dateien, Netzwerk und Systemfunktionen.

SBOM

Software Bill of Materials; maschinenlesbares Verzeichnis von Komponenten und Abhängigkeiten.

Scaffold

Technische und prozessuale Einbettung eines Modells, etwa Tools, Prompts, Speicher und Steuerlogik.

Secret

Vertraulicher Zugangswert wie API-Key, Token, Passwort oder privater Schlüssel.

Semantic Versioning

Versionierungsschema MAJOR.MINOR.PATCH zur Kommunikation von Kompatibilitätsänderungen.

Shift Left

Frühzeitiges Verlegen von Qualität und Sicherheit in Anforderungen, Entwicklung und CI.

SLO

Service Level Objective; messbares Ziel für Zuverlässigkeit oder Leistung eines Dienstes.

Staging

Produktionsnahe Umgebung für Integration, Abnahme und Deploymenttests.

Statische Analyse

Prüfung von Quellcode oder Artefakten ohne deren vollständige Ausführung.

Technical Debt

Kurz- oder langfristige Mehrkosten aus Entscheidungen, die spätere Änderung, Betrieb oder Qualität erschweren.

Test Oracle

Regel oder erwartetes Ergebnis, anhand dessen ein Test Erfolg und Fehler unterscheidet.

Threat Model

Strukturierte Beschreibung von Schutzgütern, Angreifern, Angriffswegen und Gegenmaßnahmen.

Tool Calling

Strukturierter Aufruf externer Funktionen durch ein Modell oder einen Agenten.

Trace

Verknüpfte Aufzeichnung der Schritte und Abhängigkeiten einer Anfrage oder Ausführung.

Unit-Test

Test einer kleinen, isolierten Funktion oder Einheit.

Validation

Prüfung, ob das System im realen Kontext den beabsichtigten Nutzer- und Geschäftszweck erfüllt.

Vendor Lock-in

Erschwerte Wechselmöglichkeit durch proprietäre Schnittstellen, Datenformate oder Prozesse.

Verification

Prüfung, ob ein System spezifizierte Anforderungen und technische Regeln erfüllt.

Versionskontrolle

System zur nachvollziehbaren Speicherung, Vergleichbarkeit und Wiederherstellung von Änderungen.

Vibe Coding

Softwareerstellung primär per natürlicher Sprache, häufig mit reduzierter direkter Codebearbeitung und selektiver Prüfung.

Worktree

Separate Arbeitskopie eines Git-Repositories für parallele Branches oder Agentenaufgaben.

Beleg- und Quellenmatrix

Vollständiges Quellenregister

Die Quellen sind nach Aufnahme in das Dossier nummeriert. Peer-Review-Status und Dokumentart werden nur behauptet, soweit dies aus der Quelle oder dem Publikationskontext nachvollziehbar ist. Preprints bleiben als vorläufig gekennzeichnet. Produktdokumentationen belegen Funktionen und Policies am Prüftag, nicht die unabhängige Wirksamkeit des Produkts.

S-001 - Vibe coding: programming through conversation with artificial intelligence

S-002 - Good Vibrations? A Qualitative Study of Vibe Coding

S-003 - Building Software by Rolling the Dice: A Qualitative Study of Vibe Coding

S-004 - Context Before Code: An Experience Report on Building Deployable Systems with Vibe Coding

S-005 - Computer Science Achievement and Writing Skill as Predictors of Vibe Coding Performance

S-006 - From Prompting to Verification: How Experience Shapes Vibe Coding Practices

S-007 - Vibe Coding in Software Development: A Multivocal Literature Review

S-008 - Programming by Chat: A Large-Scale Behavioral Analysis of 11,579 Real-World AI-Assisted IDE Sessions

S-009 - Is Vibe Coding the Future? An Empirical Assessment of LLM Generated Codes for Construction Safety

S-010 - A vibe coding learning design to enhance EFL students' talking to, through, and about AI

S-011 - The State of Generative AI in Software Development

S-012 - A meta-analysis of the effect of generative AI on programming performance

S-013 - Grounded Copilot: How Programmers Interact with Code-Generating Models

S-014 - Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models

S-015 - The Impact of AI on Developer Productivity: Evidence from GitHub Copilot

S-016 - The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers

S-017 - Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

S-018 - Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - Paper

S-019 - Uplift Update: Late-2025 AI and Experienced Open-Source Developer Productivity

S-020 - AI Usage Survey: Self-Reported Value and Reasons for Skepticism

S-021 - Who is using AI to code? Global diffusion and impact of generative AI

S-022 - State of AI-assisted Software Development 2025

S-023 - The SPACE of Developer Productivity

S-024 - DORA metrics

S-025 - How Much Does AI Impact Development Speed? An Enterprise-Based Randomized Controlled Trial

S-026 - A Field Study of Developer-AI Interaction in a Software Organization

S-027 - The Programmer's Assistant: Conversational Interaction with a Large Language Model for Software Development

S-028 - 2025 Developer Survey - AI

S-029 - How AI Impacts Skill Formation

S-030 - Code Comprehension with GitHub Copilot

S-031 - The Effects of GitHub Copilot on Computing Students' Programming Performance, Behaviors, and Understanding

S-032 - Mitigating Epistemic Debt in Generative-AI-Scaffolded Programming

S-033 - Three Years with Classroom AI in Introductory Programming

S-034 - Incidental Learning Lost? Skill Formation under Agentic Delegation

S-035 - AI-Assisted Help-Seeking Trajectories in Programming

S-036 - How Students Respond to Buggy GenAI Code

S-037 - Scratch Copilot: Supporting Youth Creative Coding with AI

S-038 - AI-Mediated Metacognitive Decoupling and the Limits of Self-Assessment

S-039 - Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild

S-040 - GenAI-Induced Self-Admitted Technical Debt

S-041 - Maintaining Agent-Generated Code: A Longitudinal Study of Files and Changes

S-042 - Human Review of AI-Generated Pull Requests

S-043 - Architectural and Code Smells in AI-Generated Software

S-044 - Downstream Maintainability of AI-Generated Code

S-045 - Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents

S-046 - AI Writes Faster Than Humans Can Review

S-047 - Do Users Write More Insecure Code with AI Assistants?

S-048 - Security Weaknesses of Copilot Generated Code in GitHub Projects

S-049 - We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs

S-050 - Prompt Injection Attacks on Agentic Coding Assistants

S-051 - GitInject: Indirect Prompt Injection Through Software Repositories

S-052 - AI Agents May Always Fall for Prompt Injections

S-053 - What Breaks When LLMs Code? Characterizing Coding-Agent Failures in the Wild

S-054 - Skills That Don't Exist: A Large-Scale Study of Hallucinated Agent Skills

S-055 - Uncovering Security and Privacy Issues in LLM-native IDEs

S-056 - SWE-bench: Can Language Models Resolve Real-World GitHub Issues?

S-057 - SWE-bench official benchmark and leaderboards

S-058 - Why SWE-bench Verified no longer measures frontier coding capabilities

S-059 - Separating signal from noise in coding evaluations

S-060 - SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering?

S-061 - Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces

S-062 - Task-Completion Time Horizons of Frontier AI Models

S-063 - Measuring AI Ability to Complete Long Software Tasks

S-064 - UTBoost: Rigorous Evaluation of Coding Agents on SWE-Bench

S-065 - Secure Software Development Framework (SSDF) Version 1.1 - SP 800-218

S-066 - Secure Software Development Framework (SSDF) Version 1.2 - Initial Public Draft

S-067 - Application Security Verification Standard

S-068 - Secure Coding Practices Checklist

S-069 - Secure Code Review Cheat Sheet

S-070 - OWASP Top 10 for LLM Applications 2025

S-071 - Supply-chain Levels for Software Artifacts (SLSA)

S-072 - OpenSSF Scorecard

S-073 - SPDX Specification

S-074 - CycloneDX Specification

S-075 - Git Documentation

S-076 - GitHub Actions Documentation

S-077 - Development Containers Specification

S-078 - Semantic Versioning 2.0.0

S-079 - ISO/IEC 25010 - Systems and software Quality Requirements and Evaluation

S-080 - Guide to the Software Engineering Body of Knowledge - SWEBOK

S-081 - Site Reliability Engineering - online book

S-082 - The Twelve-Factor App

S-083 - Secure by Design

S-084 - Developing and maintaining secure code

S-085 - Specification

S-086 - Security Best Practices

S-087 - Model Context Protocol: Security Design Considerations for AI-Driven Automation

S-088 - Codex in ChatGPT - AI Coding Agents

S-089 - Codex developer documentation

S-090 - Running Codex safely at OpenAI

S-091 - Agent internet access - Codex web

S-092 - Introducing Codex

S-093 - Claude Code overview

S-094 - Claude Code security

S-095 - Claude Code settings

S-096 - Claude Code data usage

S-097 - About GitHub Copilot cloud agent

S-098 - About cloud and local sandboxes for GitHub Copilot

S-099 - Responsible use of GitHub Copilot features

S-100 - Gemini Code Assist agent mode overview

S-101 - Gemini CLI

S-102 - Gemini Code Assist and responsible AI

S-103 - Verordnung (EU) 2024/2847 - Cyber Resilience Act

S-104 - Konsolidierte Fassung der Verordnung (EU) 2024/1689 über künstliche Intelligenz

S-105 - Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte

S-106 - Karpukhin et al. / Facebook AI Research: Dense Passage Retrieval for Open-Domain Question Answering

S-107 - Izacard und Grave: Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering

S-108 - Schick et al. / Meta AI: Toolformer: Language Models Can Teach Themselves to Use Tools

S-109 - Yao et al.: ReAct: Synergizing Reasoning and Acting in Language Models

S-110 - Wei et al. / Google Research: Chain-of-Thought Prompting Elicits Reasoning in Large Language Models

S-111 - Lightman et al. / OpenAI: Let’s Verify Step by Step

S-112 - Hendrycks et al.: Measuring Massive Multitask Language Understanding

S-113 - Srivastava et al.: Beyond the Imitation Game: Quantifying and extrapolating the capabilities of language models

S-114 - Lin, Hilton, Evans: TruthfulQA: Measuring How Models Mimic Human Falsehoods

S-115 - Li et al.: HaluEval: A Large-Scale Hallucination Evaluation Benchmark for Large Language Models

S-116 - Gao et al. / Google DeepMind: FACTS Grounding: A Benchmark for Evaluating Groundedness of Language Models

S-117 - Google DeepMind: FACTS Grounding public benchmark data

S-118 - Vectara: Hallucination Leaderboard / HHEM-2.3

S-119 - Rajpurkar et al.: SQuAD: 100,000+ Questions for Machine Comprehension of Text

S-120 - Rajpurkar, Jia, Liang: Know What You Don’t Know: Unanswerable Questions for SQuAD

S-121 - Cole et al.: Selectively Answering Ambiguous Questions

S-122 - Ribeiro et al.: Beyond Accuracy: Behavioral Testing of NLP Models with CheckList

S-123 - Liu et al.: Lost in the Middle: How Language Models Use Long Contexts

S-124 - Bai et al.: LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding

Schnell veraltende Informationen und Qualitätsbericht

Refresh-Liste

Qualitätsbericht

Schlussfolgerung für die Buchreihe

Programmieren mit KI ist weder nur eine neue Form der Codevervollständigung noch die Abschaffung des Software-Engineerings. Die Codeerzeugung wird billiger, schneller und für mehr Menschen zugänglich. Dadurch verschiebt sich die knappe Ressource zu klaren Anforderungen, belastbarem Kontext, technischer Urteilskraft, Tests, Review, Sicherheit, Betrieb und Verantwortung. Für kleine, isolierte und reversible Vorhaben kann enges Vibe Coding ein sinnvoller Weg sein. Je größer Datenwert, Nutzerkreis, Schadenswirkung und Lebensdauer werden, desto stärker muss der Arbeitsmodus in professionell kontrollierte Softwareentwicklung übergehen.

Die entscheidende Kompetenz lautet deshalb nicht: „Ich kann mir Code generieren lassen.“ Sie lautet: „Ich kann ein Problem so in ein System übersetzen, dass Anforderungen, Datenflüsse, Grenzen, Prüfnachweise und Betrieb verständlich bleiben - auch dann, wenn ein Modell einen großen Teil des Codes erzeugt.“

Ende des Fakten-Dossiers 11 - Fakten- und Recherchestand: 8. August 2026.