--- title: "QA für KI-generierten Code" canonical: https://wavect.io/de/blog/qa-for-ai-generated-code/ language: de description: "Was an KI-generiertem Code aus Lovable, Cursor, Claude Code und Replit bricht, und die Production-Readiness-Checkliste, mit der Wavect es abfängt." image: "https://wavect.io/img/blog/headers/header_qa-for-ai-generated-code.png" --- [**Zurück**](/de/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/de/team/christof-jori/) [Christof Jori](/de/team/christof-jori/) https://linkedin.com/company/wavect 8 Min Lesezeit · 8. Juni 2026 [**Weiter**](/de/blog/why-ai-agent-projects-get-cancelled/) # QA für KI-generierten Code: Was vor dem Launch bricht und wie man es abfängt TL;DR KI-generierter Code ist nicht schlechterer, sondern ungeprüfter Code: Er bricht vorhersehbar an denselben Stellen, fehlende Autorisierungschecks, unvalidierte Eingaben, geleakte Secrets, kein Error-Handling und Queries, die nicht skalieren. Der Post liefert die Production-Readiness-Checkliste, die wir vor jedem Launch fahren. Ein fokussierter Review- und Hardening-Durchgang läuft ein bis drei Wochen und endet in einer reparierten, getesteten Codebasis. Passende Leistung: [Vibe Coding Rescue](/de/services/vibe-coding-rescue/) Ein KI-Prototyp aus Lovable, Cursor, Claude Code oder Replit bringt dich an einem Wochenende zu einer funktionierenden Demo. Er bringt dich nicht in Produktion. Die Lücke zwischen "läuft auf meinem Bildschirm" und "übersteht echte Nutzer, echte Last und ein Security-Review" ist genau dort, wo KI-generierter Code still versagt. Das ist der QA-Prozess, den wir bei KI-gestützten Builds fahren, bevor sie live gehen, und die Fehlermuster, die wir am häufigsten sehen. Nichts davon ist ein Argument gegen das Bauen mit KI. Wir bauen auch damit. Es ist ein Argument dafür, den Output genauso zu testen wie jeden anderen Code, der gleich echtes Geld, echte Daten und echte Nutzer berührt. ## Warum bricht KI-generierter Code in Produktion? KI-Coding-Tools optimieren auf eine Sache: etwas zu produzieren, das läuft und zum Prompt passt. Sie optimieren nicht auf die Dinge, die entscheiden, ob Software den Kontakt mit Nutzern übersteht. Das Modell kennt dein Threat-Model nicht, deine Datenmengen nicht, deine Edge-Cases nicht und deine Compliance-Pflichten nicht. Es schreibt den Happy Path gut und überspringt fast alles andere, weil niemand danach gefragt hat. Das Ergebnis ist Code, der sauber demonstriert und vorhersehbar bricht. Die Brüche sind nicht zufällig. Sie sammeln sich jedes Mal an denselben Stellen, und genau das macht sie testbar. ## Was bricht tatsächlich an KI-generiertem Code? Hier ist die Liste, die wir bei jedem KI-gestützten Build durchgehen, sortiert danach, wie oft es zubeißt. - **Lücken bei Authentifizierung und Autorisierung.** Der Login-Screen funktioniert. Die Prüfung, die Nutzer A daran hindert, die Daten von Nutzer B zu lesen, fehlt oder läuft nur im Frontend. Das ist der mit Abstand häufigste schwere Defekt, den wir finden. - **Eingaben, die nie validiert werden.** Formulare nehmen alles an. Keine Längenlimits, keine Typ-Checks, keine Sanitisierung. Die Demo-Daten waren sauber, also fiel die Lücke nie auf. - **Secrets am falschen Ort.** API-Keys, Datenbank-URLs und Tokens hartkodiert im Client-Code oder ins Repo committet. KI-Tools schreiben sie inline, weil das Beispiel dann läuft. - **Kein Error-Handling.** Der Happy Path ist abgedeckt. Ein fehlgeschlagener Netzwerkaufruf, ein Timeout oder ein leeres Ergebnis wirft eine unbehandelte Exception und der Screen wird weiß. - **Queries, die nicht skalieren.** Code, der einen Datenbankaufruf in ein Render schleift oder eine ganze Tabelle zieht, um Zeilen zu zählen. Okay bei 10 Datensätzen, fatal bei 100.000. - **Race Conditions und Doppel-Submits.** Zwei Klicks erzeugen zwei Bestellungen. Zwei parallele Requests bestehen beide eine Saldo-Prüfung und buchen beide ab. - **Dependencies, die niemand geprüft hat.** Das Modell zieht Pakete herein, die veraltet, verwaist oder mit bekannten Schwachstellen behaftet sind. - **State, der lügt.** Die UI sagt, die Zahlung sei erfolgreich; das Backend hat sie nie erfasst. Optimistische Updates ohne Abgleich. ![Christof Jori](/img/team/christof.webp) "KI schreibt nicht absichtlich unsicheren Code. Sie schreibt den Code, nach dem du gefragt hast, und nichts, was du zu fragen vergessen hast. Produktion ist die Summe von allem, was du zu fragen vergessen hast." ## Die Production-Readiness-Checkliste für KI-gestützte Builds Das ist die Struktur eines Wavect-Reviews. Einen ersten Durchgang kannst du selbst machen, bevor du jemanden anrufst. 1. **Autorisierungs-Audit.** Für jeden Endpunkt und jeden Datenzugriff bestätigen, dass der Server prüft, wer fragt und ob es erlaubt ist. Frontend-Checks zählen nicht. 2. **Eingabegrenzen-Test.** Wirf fehlerhafte, übergroße und feindliche Eingaben an jeden Eintrittspunkt. Bestätige, dass sie sauber abgewiesen und nicht geschluckt werden. 3. **Secret-Sweep.** Repo und Client-Bundle nach Keys, Tokens und Credentials scannen. Alles Geleakte rotieren und serverseitig verlagern. 4. **Fehlerpfad-Abdeckung.** Jeden externen Aufruf zum Scheitern zwingen und bestätigen, dass die App sanft degradiert statt abzustürzen. 5. **Last- und Query-Review.** Die Datenbank unter realistischen Datenmengen profilen. N+1-Queries und unbegrenzte Reads killen, bevor sie dich killen. 6. **Concurrency-Test.** Parallele und doppelte Requests an alles feuern, das Geld oder State schreibt. Idempotenz ergänzen, wo sie fehlt. 7. **Dependency- und Lizenz-Scan.** Jedes Paket auf bekannte Schwachstellen und inkompatible Lizenzen prüfen. 8. **Regressions-Suite.** Die Tests schreiben, die der Prototyp nie hatte, damit die nächste KI-gestützte Änderung nicht still bricht, was schon funktioniert. Siehe [testgetriebene Entwicklung](/de/glossary/tdd/) dafür, warum das wichtiger wird, nicht weniger, wenn KI den Code schreibt. Das ist der Kern unseres [Software-QA-Service](/de/services/software-quality-assurance/). Das Ergebnis ist kein PDF voller Beschwerden. Es ist eine reparierte, getestete Codebasis und die Test-Suite, die sie repariert hält. ## Kann ich die KI einfach ihren eigenen Code reparieren lassen? Teilweise. Ein KI-Tool ergänzt gern einen Validierungs-Check oder wickelt einen Aufruf in Error-Handling, sobald du auf die Stelle zeigst. Was es nicht kann, ist entscheiden, wo es hinschauen soll. Es hat kein Modell deiner [technischen Schulden](/de/glossary/technical-debt/), keine Erinnerung an die Reihenfolge, in der Dinge gebaut wurden, und kein Gespür für den Edge-Case, den ein echter Nutzer an Tag zwei trifft. Die Lücken zu finden ist menschliche Arbeit. Sie zu schließen ist zunehmend geteilte Arbeit. Genau so fahren wir diese Engagements. Für einen engen Discovery-Schritt zeigt unser [Cisco-Antares-Review zur lokalen CWE-basierten Schwachstellenlokalisierung](/de/blog/cisco-antares-local-vulnerability-localization/), warum Kandidatendateien weiterhin einen Security Reviewer brauchen. ## Wie lange dauert es, KI-generierten Code produktionsreif zu machen? Für ein typisches Vibe-Coded-MVP läuft ein fokussierter Review- und Hardening-Durchgang ein bis drei Wochen. Die Streuung wird von zwei Dingen getrieben: wie viel echtes Geld oder sensible Daten das Produkt berührt, und wie weit die KI ohne Aufsicht gelaufen ist. Ein Wochenend-Prototyp, der Zahlungen und personenbezogene Daten verarbeitet, braucht mehr als ein Wochenende QA. Ein read-only internes Tool braucht weit weniger. Wir scopen es nach einem ersten Blick, nicht davor. ## Wann ist der Code nicht mehr zu retten? Selten, aber es kommt vor. Wenn das Datenmodell grundlegend falsch ist oder dasselbe kaputte Muster über hundert Dateien kopiert wurde, ist der Kern neu zu bauen billiger, als ihn zu flicken. Das sagen wir dir am ersten Telefonat, statt dir einen Monat dafür zu berechnen, ein Fundament zu flicken, das neu gegossen werden muss. Ehrlichkeit ist hier für alle billiger. ## Fazit KI-generierter Code ist nicht schlechterer Code. Es ist ungeprüfter Code. Der Prototyp, der ein Wochenende gedauert hat, hat dieselben Wochen an Hardening übersprungen, die jedes Produktionssystem braucht, und die Rechnung für diese Wochen verschwindet nicht, weil ein Modell den ersten Entwurf geschrieben hat. Sie verschiebt sich nur auf den Launch-Tag, wo sie am teuersten ist. Geh die Checkliste durch, bevor du echte Nutzer vor einen KI-gestützten Build setzt. Wenn die Abschnitte zu Autorisierung, Eingaben und Fehlerpfaden dich nervös machen, ist das das Signal, ein zweites Paar Augen draufzuholen, vor dem Launch, nicht nach dem Incident. ## Das könnte dich auch interessieren.. [**Externer QA-Benchmark: Die ersten 30 Tage** Was publizierte Defect-Forschung stützt, welche QA-Metriken vergleichbar sind und warum es keine ehrliche universelle Bug-Quote gibt.](/de/blog/external-qa-benchmark-first-30-days/) [**Wavect vs Dotbite** Ein fairer Vergleich zweier österreichischer Software-Shops, und welcher zu einem gründergeführten KI-Build passt versus einem Wiener Custom-Software-Projekt.](/de/compare/wavect-vs-dotbite/) QA und Produktionsreife ## In diesem Cluster weiterlesen - [Externer QA-Benchmark: Was wir in den ersten 30 Tagen finden](/de/blog/external-qa-benchmark-first-30-days/) - [Was Software-Wartung nach dem Launch kostet: Ein DACH-SaaS-Benchmark](/de/blog/software-maintenance-cost-benchmark-dach-saas/) - [Agile De-Engineering](/de/blog/agile-de-engineering/) - [Due Diligence für Lovable-, Bolt- und Replit-Apps](/de/blog/lovable-bolt-replit-app-due-diligence/) - [Die Vibe-Code-Production-Readiness-Checkliste](/de/blog/vibe-code-production-readiness-checklist/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/de/team/christof-jori/) [Christof Jori](/de/team/christof-jori/) https://linkedin.com/company/wavect 8 Min Lesezeit · 8. Juni 2026 [**Weiter**](/de/blog/why-ai-agent-projects-get-cancelled/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/qa-for-ai-generated-code/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/de/blog/qa-for-ai-generated-code/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "KI-generierter Code ist nicht schlechterer, sondern ungeprüfter Code: Er bricht vorhersehbar an denselben Stellen, fehlende Autorisierungschecks, unvalidierte Eingaben, geleakte Secrets, kein Error-Handling und Queries, die nicht skalieren. Der Post liefert die Production-Readiness-Checkliste, die wir vor jedem Launch fahren. Ein fokussierter Review- und Hardening-Durchgang läuft ein bis drei Wochen und endet in einer reparierten, getesteten Codebasis.", "articleBody": " Blog-Übersicht/Delivery und QA/QA und Produktionsreife QA für KI-generierten Code: Was vor dem Launch bricht und wie man es abfängt TL;DR KI-generierter Code ist nicht schlechterer, sondern ungeprüfter Code: Er bricht vorhersehbar an denselben Stellen, fehlende Autorisierungschecks, unvalidierte Eingaben, geleakte Secrets, kein Error-Handling und Queries, die nicht skalieren. Der Post liefert die Production-Readiness-Checkliste, die wir vor jedem Launch fahren. Ein fokussierter Review- und Hardening-Durchgang läuft ein bis drei Wochen und endet in einer reparierten, getesteten Codebasis. Passende Leistung: Vibe Coding Rescue Ein KI-Prototyp aus Lovable, Cursor, Claude Code oder Replit bringt dich an einem Wochenende zu einer funktionierenden Demo. Er bringt dich nicht in Produktion. Die Lücke zwischen \"läuft auf meinem Bildschirm\" und \"übersteht echte Nutzer, echte Last und ein Security-Review\" ist genau dort, wo KI-generierter Code still versagt. Das ist der QA-Prozess, den wir bei KI-gestützten Builds fahren, bevor sie live gehen, und die Fehlermuster, die wir am häufigsten sehen. Nichts davon ist ein Argument gegen das Bauen mit KI. Wir bauen auch damit. Es ist ein Argument dafür, den Output genauso zu testen wie jeden anderen Code, der gleich echtes Geld, echte Daten und echte Nutzer berührt. Warum bricht KI-generierter Code in Produktion? KI-Coding-Tools optimieren auf eine Sache: etwas zu produzieren, das läuft und zum Prompt passt. Sie optimieren nicht auf die Dinge, die entscheiden, ob Software den Kontakt mit Nutzern übersteht. Das Modell kennt dein Threat-Model nicht, deine Datenmengen nicht, deine Edge-Cases nicht und deine Compliance-Pflichten nicht. Es schreibt den Happy Path gut und überspringt fast alles andere, weil niemand danach gefragt hat. Das Ergebnis ist Code, der sauber demonstriert und vorhersehbar bricht. Die Brüche sind nicht zufällig. Sie sammeln sich jedes Mal an denselben Stellen, und genau das macht sie testbar. Was bricht tatsächlich an KI-generiertem Code? Hier ist die Liste, die wir bei jedem KI-gestützten Build durchgehen, sortiert danach, wie oft es zubeißt. Lücken bei Authentifizierung und Autorisierung. Der Login-Screen funktioniert. Die Prüfung, die Nutzer A daran hindert, die Daten von Nutzer B zu lesen, fehlt oder läuft nur im Frontend. Das ist der mit Abstand häufigste schwere Defekt, den wir finden. Eingaben, die nie validiert werden. Formulare nehmen alles an. Keine Längenlimits, keine Typ-Checks, keine Sanitisierung. Die Demo-Daten waren sauber, also fiel die Lücke nie auf. Secrets am falschen Ort. API-Keys, Datenbank-URLs und Tokens hartkodiert im Client-Code oder ins Repo committet. KI-Tools schreiben sie inline, weil das Beispiel dann läuft. Kein Error-Handling. Der Happy Path ist abgedeckt. Ein fehlgeschlagener Netzwerkaufruf, ein Timeout oder ein leeres Ergebnis wirft eine unbehandelte Exception und der Screen wird weiß. Queries, die nicht skalieren. Code, der einen Datenbankaufruf in ein Render schleift oder eine ganze Tabelle zieht, um Zeilen zu zählen. Okay bei 10 Datensätzen, fatal bei 100.000. Race Conditions und Doppel-Submits. Zwei Klicks erzeugen zwei Bestellungen. Zwei parallele Requests bestehen beide eine Saldo-Prüfung und buchen beide ab. Dependencies, die niemand geprüft hat. Das Modell zieht Pakete herein, die veraltet, verwaist oder mit bekannten Schwachstellen behaftet sind. State, der lügt. Die UI sagt, die Zahlung sei erfolgreich; das Backend hat sie nie erfasst. Optimistische Updates ohne Abgleich. \"KI schreibt nicht absichtlich unsicheren Code. Sie schreibt den Code, nach dem du gefragt hast, und nichts, was du zu fragen vergessen hast. Produktion ist die Summe von allem, was du zu fragen vergessen hast.\" Die Production-Readiness-Checkliste für KI-gestützte Builds Das ist die Struktur eines Wavect-Reviews. Einen ersten Durchgang kannst du selbst machen, bevor du jemanden anrufst. Autorisierungs-Audit. Für jeden Endpunkt und jeden Datenzugriff bestätigen, dass der Server prüft, wer fragt und ob es erlaubt ist. Frontend-Checks zählen nicht. Eingabegrenzen-Test. Wirf fehlerhafte, übergroße und feindliche Eingaben an jeden Eintrittspunkt. Bestätige, dass sie sauber abgewiesen und nicht geschluckt werden. Secret-Sweep. Repo und Client-Bundle nach Keys, Tokens und Credentials scannen. Alles Geleakte rotieren und serverseitig verlagern. Fehlerpfad-Abdeckung. Jeden externen Aufruf zum Scheitern zwingen und bestätigen, dass die App sanft degradiert statt abzustürzen. Last- und Query-Review. Die Datenbank unter realistischen Datenmengen profilen. N+1-Queries und unbegrenzte Reads killen, bevor sie dich killen. Concurrency-Test. Parallele und doppelte Requests an alles feuern, das Geld oder State schreibt. Idempotenz ergänzen, wo sie fehlt. Dependency- und Lizenz-Scan. Jedes Paket auf bekannte Schwachstellen und inkompatible Lizenzen prüfen. Regressions-Suite. Die Tests schreiben, die der Prototyp nie hatte, damit die nächste KI-gestützte Änderung", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-08", "description": "KI-generierter Code ist nicht schlechterer, sondern ungeprüfter Code: Er bricht vorhersehbar an denselben Stellen, fehlende Autorisierungschecks, unvalidierte Eingaben, geleakte Secrets, kein Error-Handling und Queries, die nicht skalieren. Der Post liefert die Production-Readiness-Checkliste, die wir vor jedem Launch fahren. Ein fokussierter Review- und Hardening-Durchgang läuft ein bis drei Wochen und endet in einer reparierten, getesteten Codebasis.", "headline": "QA für KI-generierten Code", "image": "https://wavect.io/img/blog/headers/header_qa-for-ai-generated-code.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/qa-for-ai-generated-code/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/qa-for-ai-generated-code/", "wordCount": 1318 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/delivery-qa/", "name": "Delivery und QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/qa-production/", "name": "QA und Produktionsreife", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/qa-for-ai-generated-code/", "name": "QA für KI-generierten Code | ", "position": 5 } ] } ```