Verifikationsdisziplin für generierten Code

1. Überblick über das Konzept und das Systemproblem

Mit der Entwicklung von Tools zur automatischen Codegenerierung ist eine kritische Lücke zwischen der einfachen Erstellung von Code und seiner tatsächlichen Zuverlässigkeit entstanden. Ein Modell kann 400 Zeilen makellos formatierten Code mit plausibel klingenden Methodennamen generieren, der autoritativ wirkt, aber in der ersten Sekunde der Ausführung abstürzt – etwa wegen des Aufrufs einer nicht existierenden Methode oder eines Typenkonflikts.

Verification Discipline (Verifikationsdisziplin) ist die entscheidende Trennlinie zwischen professionellen Softwareingenieuren und Amateuren. Es handelt sich um eine unerschütterliche innere Haltung:

• Kein Wort des Sprachmodells wird blind vertraut.
• Jeder generierte Code gilt als potenziell fehlerhaft, bis das Gegenteil durch ein unabhängiges, deterministisches Werkzeug (Compiler, Linter, Test Runner) bewiesen wurde.
• Der Ingenieur trägt die persönliche berufliche Verantwortung für jedes Zeichen, das in das Repository gemerged wird.

Ohne Verifikationsdisziplin gleitet das Projekt in einen Zustand des „fragilen Kartenhauses“, bei dem jede neue Feature zwei vorherige bricht und das Team all seine Energie darauf verwendet, plötzliche Brände in der Produktion zu löschen.

Аматорський підхід (Сліпа довіра):
[LLM: "Я все виправив, код готовий!"] ---> [Клік "Accept All"] ---> [Commit & Push] ---> [502 Bad Gateway в продакшені]

Інженерна дисципліна верифікації (Evidence-First):
[LLM: "Я все виправив!"]
          |
          v
[Крок 1: tsc --noEmit] -----------------> [Помилка типу! Повернення агенту на доопрацювання]
          | (Зелено)
          v
[Крок 2: vitest run] -------------------> [Падіння тесту! Виправлення логіки]
          | (Зелено)
          v
[Крок 3: git diff --cached] ------------> [Виявлено зайвий console.log та галюциновану бібліотеку]
          | (Чисто)
          v
[Крок 4: Smoke Test у браузері] --------> [Фізичний клік по формі]
          |
          v
[Свідомий Production Commit]

2. Architektonische Taxonomie und mentales Modell

Ebenen der Schutzbarrieren der Verifikation (Das Swiss Cheese Model):

1. Ebene 1: Statische syntaktische und semantische Analyse (Compile-time):
   • Strikte Compiler (tsc --noEmit, rustc, cargo check).
   • Style- und Security-Linter (ESLint, Biome, ShellCheck).
   • Filtert 70 % der Halluzinationen bezüglich nicht existierender Felder oder Methoden heraus.
2. Ebene 2: Automatisiertes dynamisches Testing (Dynamic Verification):
   • Unit-Tests: Überprüfung reiner Funktionen und Randfälle.
   • Integrationstests: Überprüfung der Interaktion mit echten Datenbanken oder Caches.
   • Schützt vor logischen Fehlern und Regressionen.
3. Ebene 3: Änderungsaudit (Diff Hygiene):
   • Menschliches Lesen der Zeilendifferenzen via git diff.
   • Ziel: Erkennen von „Müll“, versehentlich gelöschten Kommentaren oder Verstößen gegen architektonische Grenzen.
4. Ebene 4: Runtime-Verifikation (End-to-End & Observability):
   • Durchlaufen echter Benutzerszenarien via Playwright oder manuell im Browser/Terminal.
   • Überwachung der Logs nach dem Release auf Spitzen bei 5xx-Fehlern.

3. Technischer Pipeline und interne Mechanik

Automatischer Git Pre-Commit-Hook zur Verifikation (Husky / Lefthook)

Menschen können aufgrund von Ermüdung vergessen, den Code zu überprüfen. Um das System vor dem menschlichen Faktor zu schützen, blockiert der Verifikationskreislauf den Commit hardwareseitig bzw. auf Tool-Ebene:

# lefthook.yml — надійний та швидкий валідатор
pre-commit:
  parallel: false
  commands:
    typecheck:
      run: npx tsc --noEmit
    lint:
      run: npx @biomejs/biome check --staged --apply
    test:
      run: npx vitest run --passWithNoTests

Wenn auch nur ein Test fehlschlägt oder der Compiler Typinkonsistenzen erkennt, wird der Versuch, den Code zu committen, abgebrochen.

Checkliste für das manuelle Diff-Audit (Diff Inspection Protocol)

Vor der Ausführung des Befehls git push überprüft der Ingenieur:

- [ ] Чи не видалив агент важливий код у непов'язаних частинах файлу?
- [ ] Чи оброблені крайні випадки (null, undefined, порожній масив, 404)?
- [ ] Чи відсутні захардкоджені паролі, секрети та тестові токени?
- [ ] Чи немає в diff випадкових змін форматування у 50 чужих файлах?
- [ ] Чи відповідають назви нових сутностей прийнятим стандартам проекту?

4. Praktische Engineering-Szenarien in der Produktion

01. Erkennung einer tückischen Halluzination im Finanzmodul

Ein Agent schrieb eine Funktion zur Berechnung von Bankgebühren und meldete selbstbewusst: „Die Logik wurde gemäß den Regeln aktualisiert.“ Der Ingenieur wandte die Verifikationsdisziplin an und schrieb einen Test für die Übergabe eines negativen Betrags (amount: -100). Es stellte sich heraus, dass die Funktion eine negative Gebühr zurückgab, was es Angreifern ermöglicht hätte, Geld von den Konten des Unternehmens zu stehlen. Der Bug wurde vor dem Release behoben.

02. Schutz vor stiller Löschung von Kommentaren in Legacy-Systemen

Während eines Refactorings enthielt ein Modul einen wichtigen Kommentar: // CRITICAL: do not reorder this call due to Safari bug #19284. Das Modell entschied, dass der Kommentar überflüssig sei, löschte ihn und änderte die Reihenfolge der Aufrufe. Dank einer sorgfältigen Prüfung des git diff bemerkte der Architekt die Löschung, behielt den schützenden Workaround bei und fügte einen regressiven E2E-Test hinzu.

03. Vollständige reproduzierbare Testabdeckung vor der Fehlerbehebung (Bug Repro First)

Bei Eingang einer Fehlermeldung verbietet der disziplinierte Ingenieur dem Agenten, den Produktionscode anzufassen. Zuerst wird ein Test geschrieben, der den Bug exakt reproduziert und mit einer roten Fehlermeldung scheitert (Red Phase). Erst nachdem der Bug garantiert vom Test erfasst wurde, nimmt der Agent Änderungen vor, bis der Test grün wird (Green Phase).

5. Fallstricke, typische Fehler und Sicherheit

1. „Diff Blindness“ (Blindheit beim Review): Wenn ein Diff mehr als 800 Zeilen enthält, ermüden die Augen, und nach 2 Minuten Scrollen drückt der Ingenieur einfach auf „Approve“. Wenn der PR zu groß ist – bestätigen Sie ihn niemals komplett. Verlangen Sie, die Aufgabe in atomare Teile von maximal 200 Zeilen pro Einheit aufzuteilen.
2. Tautologische Tests (Mocking Always Passes): Agenten generieren oft Tests, die ihre eigenen Mocks testen: mockService.get.mockReturnValue(true); expect(mockService.get()).toBe(true). Solch ein Test ist immer grün, testet aber keine einzige Zeile realen Codes. Überprüfen Sie stets die Semantik der Assertions in generierten Tests.
3. Ignorieren von Compiler-Warnungen: Die Gewohnheit, gelbe Warnungen des Linters zu ignorieren oder Typen implizit via as unknown as Type zu konvertieren, zerstört das Sicherheitsnetz von TypeScript vollständig. Arbeiten Sie nach der Regel: Null Warnungen in der Konsole.