Illusion of Competence (Ілюзія інженерної компетентності)

1. Konzeptüberblick und systemisches Problem

Vor dem Aufkommen leistungsstarker Sprachmodelle wurde ingenieurtechnische Expertise durch das Überwinden von Widerständen aufgebaut: Lesen der offiziellen Dokumentation, stundenlanges schrittweises Tracing im Debugger, Analyse von Memory Dumps und manuelle Behebung von Segmentation Faults. Dieser Unbehagen war eine zwingende Voraussetzung für Neuroplastizität – die Bildung stabiler mentaler Modelle im Gehirn.

Mit dem Erscheinen intelligenter Agenten entstand das Phänomen der Illusion of Competence (Kompetenz-Illusion). Ein Entwickler kann innerhalb weniger Stunden eine voll funktionsfähige Anwendung mit WebSocket, OAuth-Authentifizierung und einer PostgreSQL-Datenbank deployen, ohne dabei zu verstehen, wie das TCP-Protokoll funktioniert, was ein B-Tree-Index ist oder wie eine JWT-Signatur validiert wird.

Es entsteht eine gefährliche Diskrepanz zwischen externen Artefakten (funktionierendes Projekt) und dem internen kognitiven Kapital des Ingenieurs:

• Der Entwickler fühlt sich als Senior, weil er „Aufgaben schnell abschließt“.
• Er wird jedoch vollständig abhängig von der Modell-Schnittstelle: Ohne generative Code-Vervollständigung ist er nicht in der Lage, eine grundlegende Konfigurationsdatei einzurichten oder eine saubere SQL-Abfrage zu schreiben.
• Jedes nicht-standardisierte Problem zur Laufzeit löst Panik und Handlungsunfähigkeit aus.

Справжня експертиза (Глибинна нейронна модель):
[Проблема] ---> [Розуміння системи з першопринципів (CPU, RAM, Network)] ---> [Свідомий вибір архітектури]

Ілюзія компетентності (Крихка імітація):
[Проблема] ---> [Промпт в асистента] ---> [Отримання 200 рядків коду] ---> [Швидкий запуск]
                                                                                |
                                                                                v
                     "Я все чудово розумію!" (Самообман до першого масштабного збою)

2. Architektonische Taxonomie und mentales Modell

Die Abstufung der Wissensniveaus orientiert sich an Bloom's Taxonomy:

1. Stufe 1: Oberflächliches Erkennen (Recognition):
   • „Ich habe diesen Code schon einmal gesehen, er sieht vertraut und ordentlich aus.“
   • Das Basisniveau, auf dem die Mehrheit der Vibe-Coding-Nutzer stehen bleibt.
2. Stufe 2: Fähigkeit zur Erklärung der Mechanik (Explanation):
   • Der Ingenieur kann ohne Computer einen schrittweisen Datenfluss durch eine Funktion skizzieren.
3. Stufe 3: Eigenständige Synthese von Grund auf (Synthesis / First-Principles):
   • Die Fähigkeit, eine Architektur auf einem leeren Blatt Papier oder in einem einfachen Texteditor ohne jegliche externe Assistenten zu entwerfen und umzusetzen.
4. Stufe 4: Bewertung und kritische Analyse von Trade-offs (Evaluation):
   • Das Verständnis dafür, warum eine bestimmte Modell-Lösung für dieses spezifische System schädlich ist, selbst wenn sie in Lehrbüchern empfohlen wird.

3. Technischer Pipeline und interne Mechanik

Test auf Kompetenz-Illusion: „The Whiteboard Challenge“

Um zu überprüfen, ob Sie die Technologie tatsächlich beherrschen, führen Sie einen wöchentlichen Selbstaudit durch:

[Крок 1: Оберіть 1 критичний модуль вашого проекту]
(Наприклад: механізм автентифікації сесій)
   |
   v
[Крок 2: Закрийте всі IDE, чати з ШІ та браузер]
   |
   v
[Крок 3: Візьміть чистий аркуш паперу або планшет]
   |
   v
[Крок 4: Дайте відповіді на 4 жорстких інженерних запитання:]
1. Які структури даних використовуються в оперативній пам'яті?
2. Що станеться, якщо база даних перейде в стан Read-Only?
3. Який час життя cookie і чому прапорець SameSite встановлений саме так?
4. Яка часова складність (Big-O) головної операції пошуку?
   |
   v
[Якщо є прогалини ---> Відкрити вихідні коди та специфікацію RFC для вивчення]

Praxis „Deliberate Practice“ (Bewusstes Training)

Um der Atrophie des ingenieurtechnischen Denkens vorzubeugen, gilt folgende Regel:

• 80 % der Zeit: Arbeit mit AI-Assistenten zur Sicherstellung hoher Business-Geschwindigkeit.
• 20 % der Zeit: Eigenständige Implementierung komplexer algorithmischer Aufgaben oder Studium der Runtimes der Sprache ohne jegliche KI-Tools.

4. Praktische Ingenieursszenarien im Production-Umfeld

01. Analyse eines Produktionsdatenbank-Ausfalls unter Black-Friday-Last

Während des Kundenandrangs blockierte der Datenbankserver aufgrund der Erschöpfung des Connection Pools (Connection Starvation). Der Entwickler, der den Code über einen Agenten geschrieben hatte, warf hilflos Fehlerlogs in den Chat des Modells, das sinnlose Neustarts vorschlug. Ein Senior-Ingenieur, der das Speichermodell und Transaktionsblockierungen verstand, fand innerhalb von 2 Minuten einen Connection-Leak in einem unbehandelten Error-Block und rettete das Unternehmen vor enormen Verlusten.

02. Scheitern eines Senior-Kandidaten im technischen Interview

Ein Entwickler mit 7 Jahren Erfahrung präsentierte ein beeindruckendes Portfolio moderner Services, die mit Cursor erstellt wurden. Im praktischen Teil, bei dem es darum ging, eine einfache Rate-limited Queue ohne Internetzugang zu implementieren, konnte der Kandidat nicht einmal den Funktions-Skelett schreiben, da er unfähig war, ohne fertige Generierungen zu denken.

03. Bewusstes Eintauchen in die Protokollimplementierung

Ein Ingenieur nutzt eine Bibliothek für WebRTC. Anstatt blindlings den Code des Assistenten zu kopieren, nimmt er sich einen Arbeitstag, um die RFC-Spezifikationen für ICE, STUN und TURN zu lesen. Dies ermöglichte es ihm, eine versteckte Lücke in der NAT-Traversierungs-Konfiguration zu entdecken, die das Modell aufgrund fehlenden Kontexts zur Netzwerk-Topologie nicht erkennen konnte.

5. Fallstricke, typische Fehler und Sicherheit

1. Dunning-Kruger-Effekt auf Steroiden: Juniors oder Anfänger, die Zugang zu leistungsstarken Agenten erhalten, betrachten sich nach 2 Monaten als Lead Architects, weil sie „schnell Services bauen“. Dies erzeugt toxisches Selbstvertrauen und führt dazu, dass Ratschläge erfahrener Kollegen abgelehnt werden.
2. Blindes Vertrauen in die Sicherheit generierter Algorithmen: Das Modell kann eine schnelle Implementierung einer kryptografischen Signatur generieren, die korrekt aussieht, aber anfällig für Replay Attacks oder Timing Leaks ist. Ohne Kryptografie-Wissen wird der Ingenieur diesen Defekt niemals erkennen.
3. Vollständiger Verlust der Fähigkeit zum systemischen Denken (Cognitive Atrophy): Wenn das Gehirn nicht darin trainiert wird, komplexe logische Ketten zu halten, degradieren neuronale Pfade. Zwingen Sie sich kontinuierlich dazu, fremden komplexen Code zu lesen, Open-Source-Kernel-Bibliotheken zu studieren und den Quellcode der Runtimes (Node.js, V8, Go runtime) zu verstehen.