**axe MCP Server**

Überblick

Der axe MCP Server ist ein Model Context Protocol (MCP) Server, der die barrierefreie Prüfung auf Unternehmensniveau direkt in Ihren Entwicklungsworkflow integriert. Basierend auf der bewährten axe-Plattform ermöglicht er Entwicklern, umfassende Barrierefreiheits-Scans durchzuführen und fundierte Unterstützung zur Behebung von Problemen direkt in ihrer IDE zu erhalten.

Der Server bietet drei Funktionen — analyze, remediate und igt.

Diese Tools integrieren sich nahtlos mit MCP-kompatiblen Clients (wie Claude Desktop, VS Code mit Copilot oder Cursor) und berücksichtigen die axe-Konfigurationseinstellungen Ihrer Organisation.

Zugang erhalten

Der Axe MCP Server ist im Axe DevTools für Web-Paket enthalten. Ein Abonnement zur Freischaltung des Zugriffs auf den Axe-MCP-Server wird durch Gespräche mit einem Deque-Vertriebsmitarbeiter eingerichtet.

Tools & Funktionen

Das analyze-Tool

Das analyze-Tool führt eine umfassende Barrierefreiheitsanalyse von Webseiten durch, indem es mithilfe der Axe DevTools Browser Extension in einer realen Browserumgebung scannt. Es funktioniert nahtlos sowohl mit lokalen Entwicklungs-URLs (z. B. localhost:3000) als auch mit Remote-Produktions-URLs.

Was es macht

1. Authentifizierung — Validiert die Benutzeranmeldedaten (entweder einen API-Schlüssel oder ein OAuth 2.0 Access Token), um autorisierten Zugriff zu gewährleisten
2. Konfigurationsabfrage — Ruft die benutzerspezifischen axe-Konfiguration-Einstellungen der Organisation ab, einschließlich:
   • Barrierefreiheits-Standard (z. B. WCAG 2.2 AA)
   • axe-core Version
   • Bedarf an Überprüfung / bewährte Praktiken
3. Browserbasierte Analyse — Startet eine Browserinstanz im Hintergrund mit installierter Axe DevTools Extension
4. Seitennavigation — Navigiert zur vom Benutzer im AI-Agenten-Prompt angegebenen URL
5. Barrierefreiheits-Scan — Führt eine vollständige Barrierefreiheitsanalyse auf der gerenderten-Seite mit der Axe DevTools Browsererweiterung durch, um sicherzustellen, dass die tatsächliche Benutzererfahrung getestet wird (nicht nur statisches HTML)
6. Ergebnisauslieferung — Gibt umfassende Analyseergebnisse in einem strukturierten Format an den Agenten zurück

Reaktionsfähiges Testen

Das analyze-Tool unterstützt optionale viewportWidth- und viewportHeight-Parameter, die es ermöglichen, Seiten in bestimmten Ansichtsfensterabmessungen zu testen. Dies ist nützlich, um Barrierefreiheitsprobleme zu erkennen, die nur bei bestimmten Bildschirmgrößen auftreten, wie z. B. bei Mobilgeräten oder Tablet-Breakpoints.

Analyze http://localhost:3000 for accessibility issues at a mobile viewport of 375x812

Wenn diese Parameter weggelassen werden, verwendet der Browser seine Standard-Viewport-Größe.

Teilschrittscans

Standardmäßig scannt das analyze-Tool die gesamte Seite. Um den Scan auf einen bestimmten Bereich zu beschränken, übergeben Sie den optionalen selector-Parameter — nützlich, um sich auf eine einzelne Komponente zu konzentrieren oder laute, unzusammenhängende Teile der Seite aus den Ergebnissen auszuschließen.

• Ein einzelner CSS-Selektor-String zielt auf ein Element im obersten Frame ab:

  {
    "url": "http://localhost:3000",
    "selector": "#main"
  }

• Ein Array von CSS-Selektoren durchläuft iframe- oder Shadow-DOM-Grenzen — jedes Segment wählt den Host für das nächste aus. Verwenden Sie ein Array nur, wenn das Ziel in einem iframe oder Shadow-Root lebt:

  {
    "url": "http://localhost:3000",
    "selector": ["iframe#checkout", "#payment-form"]
  }

Ein Array unterstützt bis zu 10 Segmente. Wenn der Selektor kein Element auf der Seite trifft, gibt der Scan einen Fehler zurück. Wenn selector weggelassen wird, wird die gesamte Seite gescannt.

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf — der Agent übersetzt Ihre Absicht in den Werkzeugaufruf:

Scan only the #main region of http://localhost:3000 for accessibility issues

Browser-Interaktionen vor dem Scannen

Das analyze-Tool unterstützt ein optionales before-Array von Interaktionsschritten, die nach dem Laden der Seite, aber vor dem Barrierefreiheits-Scan ausführen. Dies eröffnet verschiedene reale Testszenarien:

• Anmeldeseiten — Füllen Sie Anmeldedaten aus und senden Sie diese ab, bevor Sie die Seite nach dem Login scannen
• Cookie/Einwilligungsbanner — Schließen Sie Banner, die sonst den Seiteninhalt überlagern oder verdecken würden
• Dynamische Inhalte — Warten Sie, bis vom Client gerenderte Inhalte (Routenänderungen, spät eingefügte DOM-Elemente) angezeigt werden, bevor Sie scannen

Schritte werden in Array-Reihenfolge ausgeführt, im gleichen Browserkontext wie der Scan, sodass Cookies, localStorage und alle durch click oder fill ausgelösten Routenänderungen in den Scan übergehen.

Das before-Array unterstützt bis zu 20 Schritte. Jeder Schritt erhält ein eigenes Timeout von BROWSER_TIMEOUT_MS (Standardmäßig 30000 ms); es gibt keinen überschreibenden Timeout pro Schritt.

Unterstützte Aktionen

Beispiel: Anmeldung vor dem Scannen

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf — der Agent übersetzt Ihre Absicht in den Werkzeugaufruf:

Analyze http://localhost:3000 for accessibility issues. Before running
the analysis, fill in the #username and #password fields with USERNAME
and PASSWORD from ./.env.local, click the button[type=submit] button,
and wait for #main-content to appear.

Der Agent löst den Prompt auf und ruft das analyze-Tool mit einer Nutzlast auf, die ähnlich ist wie:

{
  "url": "http://localhost:3000",
  "before": [
    {
      "action": "fill",
      "selector": "#username",
      "value": "<resolved-from-.env.local>"
    },
    {
      "action": "fill",
      "selector": "#password",
      "value": "<resolved-from-.env.local>"
    },
    { "action": "click", "selector": "button[type=submit]" },
    { "action": "waitFor", "selector": "#main-content" }
  ]
}

Cookie-Injektion

Das analyze-Tool unterstützt ein optionales cookies-Array, das Cookies im Browserkontext vor der Navigation setzt — sodass sie bei der allerersten Anfrage an die Seite übermittelt werden. Dies unterscheidet sich von before Aktionen, die nach der Navigation laufen und daher keinen Einfluss darauf haben, wie die anfängliche Anfrage geroutet wird. Zwei häufige Anwendungsfälle:

• Umgebungsrouting — setzen Sie ein Staging- oder Feature-Branch-Selektorkookie, das von einer Edge- oder CDN-Schicht gelesen wird, um zu entscheiden, welche Version der Seite bereitgestellt wird.
• Vorausgefüllte Sitzungen — einen gültigen Sitzungscookie injizieren, damit der Scan bereits eingeloggt startet, ohne ein Anmeldeformular über before durchlaufen zu müssen.

Das cookies-Array unterstützt bis zu 20 Cookies.

Cookie-Felder

Beispiel: Auf einer vorab authentifizierten Seite landen

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf — der Agent übersetzt Ihre Absicht in den Werkzeugaufruf:

Analyze https://app.example.com for accessibility issues. Set the session
cookie for app.example.com from ./.env.local so the scan starts already
logged in.

Der Agent löst den Cookie-Wert auf und ruft das analyze-Tool mit einer Nutzlast ähnlich wie folgt auf:

{
  "url": "https://app.example.com",
  "cookies": [
    {
      "name": "session",
      "value": "<resolved-from-.env.local>",
      "domain": "app.example.com"
    }
  ]
}

Wichtige Vorteile

• Echtbrowser-Tests - Testet die tatsächlich gerenderte Seite, nicht nur Quellcode, um genaue Ergebnisse sicherzustellen
• Organisationsstandards - Respektiert die axe-Konfigurationseinstellungen Ihres Teams für konsistentes Testen über alle Benutzer hinweg
• Umfassende Abdeckung - Nutzt die branchenführende axe Plattform
• Reaktionsfähiges Testen - Testen bei bestimmten Viewport-Abmessungen, um breakpointspezifische Zugänglichkeitsprobleme zu erfassen
• Gezielte Scans - Begrenzen Sie einen Scan auf eine bestimmte Region, ein Iframe oder eine Shadow-Root mit dem selector-Parameter
• Authentifizierte & Interaktive Seiten - Scannen Sie Seiten hinter einem Login, blenden Sie Cookie-Banner aus oder warten Sie auf dynamische Inhalte mithilfe von before-Aktionen
• Sitzungs- und Umgebungscookies - Landen Sie bereits authentifiziert oder routen Sie zu einer spezifischen Umgebung, indem Sie Cookies vor der Navigation mit dem cookies-Parameter injizieren

Ausgabe

Das Tool gibt eine strukturierte JSON-Antwort zurück, die Folgendes enthält:

• Alle festgestellten Barrierefreiheitsverletzungen
• Schweregrad der Verstöße (kritisch, ernst, moderat, geringfügig)
• Spezifische Elementselektoren und Quellcode
• Regel-IDs und Beschreibungen

Das remediate-Tool

Das remediate-Tool nimmt eines oder mehrere von den analyze- oder igt-Tool identifizierte Zugänglichkeitsprobleme entgegen und generiert kontextbezogene, KI-gesteuerte Behebungsanleitungen, die Codierungsagenten in tatsächliche Codekorrekturen übersetzen können. Probleme werden als Batch übermittelt, sodass ein einziger Aufruf Korrekturen für jede auf einer Seite gefundene Verletzung zurückgeben kann.

Was es macht

1. Authentifizierung - Validiert die Anmeldeinformationen des Benutzers - entweder einen API-Schlüssel oder ein OAuth 2.0-Zugangstoken - um autorisierten Zugriff sicherzustellen
2. AI-Guthaben Nutzung - Jedes Problem im Batch verbraucht KI-Guthaben aus dem Budget Ihrer Organisation, was die Verwendung fortschrittlicher KI-Modelle ermöglicht, die auf umfangreichem Zugänglichkeitswissen von Deque trainiert wurden
3. KI-erzeugte Behebung - Erarbeitet hochwertige, umsetzbare Zugänglichkeitskorrekturen, die Codierungsagenten interpretieren und im Quellcode implementieren können

Batch-Behebung

Das Tool akzeptiert ein issues-Array. Reichen Sie alle die Probleme von einem einzelnen analyze- oder igt-Lauf gesammelt in einem Aufruf ein, anstatt das Tool für jedes Problem einzeln aufzurufen - ein Batch unterstützt zwischen 1 und 25 Problemen.

Jedes Problem hat die folgenden Felder:

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf – er erstellt das Batch aus den Analyseergebnissen:

Analyze http://localhost:3000 and remediate every issue found

Der Agent löst die Eingabeaufforderung und ruft das remediate-Tool mit einer Nutzlast ähnlich wie folgt auf:

{
  "issues": [
    {
      "id": "color-contrast-0",
      "rule": "color-contrast",
      "elementHtml": "<span style=\"color: #aaa\">Sign up</span>",
      "remediation": "Increase the contrast ratio to at least 4.5:1",
      "pageUrl": "http://localhost:3000"
    },
    {
      "id": "image-alt-1",
      "rule": "image-alt",
      "elementHtml": "<img src=\"logo.png\">",
      "remediation": "Add alt text describing the image"
    }
  ]
}

Ausgabe

Das Tool gibt ein Array von Ergebnissen pro Problem zurück, das jeweils durch id mit seiner Eingabe verknüpft ist. Ein Ergebnis hat eine von zwei Formen:

• Erfolg — status: "ok", mit einem remediation-Objekt, das eine allgemeine Beschreibung, die Behebungsschritte und eine konkrete Codekorrektur enthält
• Fehler — status: "error", mit einem error-Objekt (code und message) für ein Problem, das nicht behoben werden konnte

{
  "data": [
    {
      "id": "color-contrast-0",
      "status": "ok",
      "remediation": {
        "general_description": "...",
        "remediation": "...",
        "code_fix": "<span style=\"color: #595959\">Sign up</span>"
      }
    },
    {
      "id": "image-alt-1",
      "status": "error",
      "error": { "code": "LLM_ERROR", "message": "..." }
    }
  ]
}

Ergebnisse sind unabhängig: Ein Fehler bei einem Problem blockiert keine Hinweise für die anderen.

Credit-Nutzung

Das remediate-Tool ist Teil des AI-Credit-Management-Systems. Jedes Problem in einem Batch verbraucht Guthaben aus dem monatlichen Budget Ihrer Organisation. Administratoren können die Nutzung der Guthaben über das axe Account Portal überwachen.

Das igt-Tool

Das igt-Tool führt Deques Automatisierte Intelligente Geführte Tests (IGTs) gegen eine Webseite von Ihrer IDE aus. Wo die axe DevTools Browser-Erweiterung normalerweise einen Entwickler durch einen IGT mit manuellen Eingabeaufforderungen führt, führt das igt-Tool den Test automatisch durch und gibt strukturierte Ergebnisse zurück, auf die Codierungsagenten reagieren können.

Heute unterstützt das Tool den Tastatur-IGT, der bewertet, ob die interaktiven Elemente auf einer Seite mit der Tastatur allein erreicht und bedient werden können.

Was es macht

1. Authentifizierung - Validiert die Anmeldeinformationen des Benutzers - entweder einen API-Schlüssel oder ein OAuth 2.0-Zugangstoken - um autorisierten Zugriff sicherzustellen
2. Browser-basierter Lauf - Testet in derselben Chromium-Instanz mit der montierten axe DevTools-Erweiterung, die das analyze-Tool verwendet
3. Seitennavigation - Navigiert zur URL, die vom Benutzer in seiner Eingabeaufforderung an den KI-Agent gesendet wurde
4. Automatisiertes Tastatur-IGT - Durchläuft die Seite, während die KI jeden Tabstopp analysiert und die Fokusreihenfolge und Tastaturbedienbarkeit bewertet – keine manuelle Eingabe erforderlich
5. Ergebnisauslieferung - Gibt strukturierte Ergebnisse an den Agenten zurück

Verbrauch

Das Tool akzeptiert ein url und ein igtTools-Array, das angibt, welche IGTs ausgeführt werden sollen. Das Keyboard IGT ist derzeit der einzige unterstützte Wert:

{
  "url": "http://localhost:3000",
  "igtTools": ["keyboard"]
}

Fordern Sie Ihren KI-Agenten in natürlicher Sprache auf—der Agent übersetzt Ihre Absicht in den Tool-Aufruf:

Run the keyboard IGT on http://localhost:3000

Browser-Interaktionen vor dem Testen

Wie das analyze-Tool akzeptiert igt ein optionales before-Array von Interaktionsschritten, die nach dem Laden der Seite ausführen, aber bevor der geführte Test ausgelöst wird. Dies ermöglicht es Ihnen, einen geführten Test gegen login-geschützte Seiten durchzuführen, Cookie-Banner zu schließen oder auf das Erscheinen dynamischer Inhalte zu warten.

Die Schritte laufen im gleichen Browserkontext des Tests (sodass Cookies, localStorage und Routenänderungen erhalten bleiben), nutzen die gleichen click, fill und waitFor Aktionen und sind auf das gleiche 20 Schritte begrenzt. Siehe Unterstützte Aktionen unter dem analyze-Tool für die vollständige Referenz, einschließlich der Behandlung sensibler Werte von fill.value und der Selektorregeln.

{
  "url": "http://localhost:3000",
  "igtTools": ["keyboard"],
  "before": [
    { "action": "fill", "selector": "#username", "value": "<resolved-from-.env.local>" },
    { "action": "click", "selector": "button[type=submit]" },
    { "action": "waitFor", "selector": "#main-content" }
  ]
}

Ausgabe

Das Tool gibt eine strukturierte JSON-Antwort zurück:

{
  "pageUrl": "http://localhost:3000",
  "data": {
    "keyboard": {
      "issues": [],
      "unanalyzedElements": [],
      "terminatedReason": "keyboard-trap"
    }
  }
}

• issues - Während des Laufs gefundene Verstöße gegen die Tastaturzugänglichkeit
• unanalyzedElements - Tabstopps, die die KI nicht analysieren konnte. Diese werden separat von issues gemeldet, damit sie manuell überprüft werden können, anstatt fälschlicherweise als bestanden oder fehlgeschlagen gemeldet zu werden.
• terminatedReason - Präsentieren Sie nur, wenn der Lauf abgebrochen wurde, bevor jeder Tabstopp analysiert wurde. Der aktuelle Wert ist "keyboard-trap", was bedeutet, dass der Test auf eine Tastaturfalle gestoßen ist, aus der er nicht entkommen konnte; die verbleibenden Schritte werden angehalten und die bis zu diesem Punkt analysierten Tabstopps werden in issues zurückgegeben.

Credit-Nutzung

Das igt-Tool ist ein KI-gestütztes Feature und Teil des AI-Credit-Management-Systems. Jeder Lauf verbraucht KI-Credits von der monatlichen Zuteilung Ihrer Organisation. Administratoren können die Nutzung der Credits über das axe Account Portal überwachen.

Erste Schritte

Die Einrichtung des axe MCP Servers umfasst drei unabhängige Entscheidungen:

1. Wählen Sie eine Distribution — Docker oder npm
2. Richten Sie die Authentifizierung ein — ein API-Schlüssel oder OAuth 2.0
3. Konfigurieren Sie Ihren Client — VS Code mit Copilot, Cursor oder **Claude Code**

Für Umgebungsvariablen und empfohlene Anweisungen für den KI-Agenten siehe Konfigurationsreferenz. Wenn etwas schiefgeht, siehe Fehlerbehebung.

Beispielaufforderungen

Sicherstellen, dass die erwarteten Werkzeuge aufgerufen werden

In vielen IDEs wird durch die Verwendung der folgenden Syntax (Präfix „#“) sichergestellt, dass die Werkzeuge des axe MCP Servers wie erwartet aufgerufen werden:

#analyze the http://localhost:3033/ web page for accessibility issues and #remediate any violations found

Eine localhost-URL auf Barrierefreiheitsprobleme analysieren:

Analyze http://localhost:3000 for accessibility issues

Analyse mit Behebung:

Analyze https://example.com for accessibility issues and fix any issues found

Eine Seite hinter einer Login-Schranke analysieren:

Analyze http://localhost:3000 for accessibility issues. Before running the
analysis, fill in the #username and #password fields with USERNAME and
PASSWORD from ./.env.local, click the button[type=submit] button, and
wait for #main-content to appear.

Ein Cookie-Banner vor dem Scannen schließen:

Analyze https://example.com for accessibility issues, but first click the
#cookie-dismiss button to dismiss the cookie consent banner.

Scannen einer Seite mit einem eingesetzten Sitzungscookie:

Analyze https://app.example.com for accessibility issues. Set the session
cookie for app.example.com from ./.env.local so the scan starts already
logged in.

Support

Für Fragen, Probleme oder Feedback bezüglich des axe MCP Servers:

• Technischer Support: helpdesk@deque.com
• Allgemeine Anfragen: helpdesk@deque.com
• Vertriebsfragen: sales@deque.com

Sicherheit & Datenschutz FAQ

Erfasst oder speichert axe MCP Server unseren Quellcode?

Nein. Der axe MCP Server erfasst oder speichert Ihren Quellcode nicht in einer Datenbank oder einem persistenten Speicher.

Wenn das analyze-Tool läuft, enthält die Antwort den HTML-Quellcode der Elemente mit Zugänglichkeitsproblemen zu Kontext- und Debugging-Zwecken. Diese Daten:

• Werden nur in der unmittelbaren API-Antwort an Ihr KI-Agent zurückgegeben
• Werden nie in von Deque verwalteten Datenbanken gespeichert
• Bleiben innerhalb Ihrer lokalen Entwicklungsumgebung
• Werden nach Abschluss der Analyse verworfen

Wie lange bleiben MCP-Testergebnisse in der von Deque verwalteten Infrastruktur?

Tun sie nicht. MCP-Testergebnisse werden in keiner von Deque verwalteten Datenbank oder Speichersystem gespeichert.

Das analyze-Tool:

• Läuft vollständig auf Ihrem Rechner — in einem Docker-Container oder als lokaler Node.js-Prozess mit der npm-Distribution
• Gibt die Ergebnisse direkt an Ihr KI-Agent zurück
• Sendet keine Analyseergebnisse an Deque-Server

Die einzige Ausnahme ist, wenn Sie das remediate-Tool aufrufen, das minimale Verstoßmetadaten (siehe unten) enthalten kann, um KI-gestützte Behebungsanleitungen zu generieren.

Welche Daten werden an Deque-Server gesendet?

Nur bei Verwendung des remediate-Tools:

Die folgenden Daten werden an den KI-Remediation-Endpunkt von Deque gesendet, um Korrekturanleitungen zu erstellen:

• Regel-ID - Die spezifische Zugänglichkeitsregel, die verletzt wurde
• Element-HTML - Das HTML-Markup des betroffenen Elements/der betroffenen Elemente
• Metadaten zu Problemen - Beschreibung des Verstoßes und Behebungsanleitung von axe-core

Diese Daten werden ausschließlich zur Erstellung von Korrekturanleitungen verwendet und nicht langfristig in Deque-Datenbanken gespeichert.

Das analyze-Tool sendet keine Daten an Deque-Server außer Authentifizierungsanfragen (Überprüfung Ihres API-Schlüssels oder OAuth 2.0-Zugriffstokens).

Welches Zugriffslevel benötigt das KI-Agent, um zu funktionieren?

Das KI-Agent (Claude, Copilot, Cursor usw.) benötigt Zugriff auf:

1. MCP-Server-Kommunikation - Der Agent muss in der Lage sein, die Werkzeuge des MCP-Servers über das Model Context Protocol aufzurufen

2. Tool-Antwortdaten - Der Agent erhält:

   • Daten zu Zugänglichkeitsverstößen aus analyze-Aufrufen
   • Behebungsanleitungen aus remediate-Aufrufen
   • Diese Daten sind für das Agent erforderlich, um Probleme zu verstehen und Codekorrekturen zu generieren

3. Ihr Codebase (optional) - Wenn Sie möchten, dass der Agent Codekorrekturen automatisch anwendet, benötigt er Zugriff auf Ihre Quellcodedateien

• Dies ist Standard für KI-Coding-Assistenten in IDEs (VS Code, Cursor usw.)
• Nicht erforderlich, wenn Sie die Tools nur zur Analyse und Anleitung verwenden (z.B. über die Claude Desktop-App)

Der MCP-Server selbst benötigt Zugriff auf:

• Von Ihnen zum Testen angegebene URLs (unterstützt sowohl lokal als auch remote)
• Ihre axe-Anmeldedaten: entweder ein API-Schlüssel (generiert im axe Account Portal) oder ein OAuth 2.0-Zugriffstoken (erhalten über @deque/axe-auth); bereitgestellt über Umgebungsvariable

Wichtig: Der MCP-Server läuft lokal auf Ihrem Rechner – in einem Docker-Container oder als Node.js-Prozess mit der npm-Distribution. Es erfordert keinen umfassenden Zugriff auf das Dateisystem oder erhöhte Berechtigungen.

Best Practices

• Anmeldedatensicherheit - Speichern Sie Ihr AXE_API_KEY oder AXE_ACCESS_TOKEN als Umgebungsvariable, nicht im Code. Bei OAuth 2.0 speichert @deque/axe-auth Token in Ihrem Betriebssystemschlüsselbund und injiziert ein neues Zugriffstoken beim Start, sodass kein langfristiges Geheimnis in Ihrer Konfiguration verbleiben muss.
• Lokale Tests - Testen Sie lokale Entwicklungs-URLs (localhost) oder Staging, um sensiblen Pre-Production-Code isoliert zu halten
• Netzwerkisolation - Der MCP-Server kommuniziert nur mit:
  • URLs, die Sie ausdrücklich zur Analyse anfordern
  • Deque-Server für Authentifizierung (API-Schlüssel- oder OAuth 2.0-Token-Validierung) und Behebung (bei Aufruf)
  • Ihrem lokalen AI-Agenten über das MCP-Protokoll
• Überprüfen vor der Anwendung - Überprüfen Sie immer von KI generierte Codeänderungen, bevor Sie sie in Ihre Codebasis übernehmen