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

1. Огляд концепції та системна проблема

До появи потужних мовних моделей інженерний досвід здобувався через подолання опору: читання офіційної документації, багатогодинне покрокове трасування під дебаггером, вивчення дампів пам'яті та ручне виправлення помилок сегментації. Цей дискомфорт був обов'язковою умовою нейропластичності — формування стійких ментальних моделей у мозку.

З появою інтелектуальних агентів виник феномен Illusion of Competence (Ілюзія компетентності). Розробник здатний за кілька годин розгорнути повнофункціональний додаток із WebSocket, аутентифікацією OAuth та базою даних PostgreSQL, майже не розуміючи, як працює протокол TCP, що таке індекс B-Tree або як валідується підпис JWT.

Виникає небезпечний розрив між зовнішніми артефактами (працюючий проект) та внутрішнім когнітивним капіталом інженера:

• Розробник почувається сеньйором, бо "швидко закриває задачі".
• Але він стає повністю залежним від інтерфейсу моделі: без генеративного автодоповнення він не здатний налаштувати базовий конфігураційний файл або написати чистий SQL-запит.
• Будь-яка нестандартна проблема в рантаймі викликає паніку та ступор.

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

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

2. Архітектурна таксономія та ментальна модель

Градація рівнів знання за концепцією Bloom's Taxonomy:

1. Рівень 1: Поверхневе розпізнавання (Recognition):
   • "Я бачив цей код раніше, він виглядає знайомим і акуратним".
   • Базовий рівень, на якому застрягає більшість користувачів вайбкодингу.
2. Рівень 2: Здатність пояснити механіку (Explanation):
   • Інженер може без комп'ютера намалювати покрокову схему руху даних через функцію.
3. Рівень 3: Самостійний синтез з нуля (Synthesis / First-Principles):
   • Здатність спроектувати та реалізувати архітектуру на чистому аркуші паперу або у простому текстовому редакторі без жодних сторонніх асистентів.
4. Рівень 4: Оцінка та критичний аналіз компромісів (Evaluation):
   • Розуміння того, чому конкретне рішення моделі є шкідливим для цієї конкретної системи, навіть якщо воно рекомендоване в підручниках.

3. Технічний пайплайн та внутрішня механіка

Тест на ілюзію компетентності: "The Whiteboard Challenge"

Щоб перевірити, чи володієте ви технологією насправді, проведіть щотижневий самоаудит:

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

Практика "Deliberate Practice" (Усвідомлене тренування)

Для запобігання атрофії інженерного мислення встановлюється правило:

• 80% часу: Робота з AI-асистентом для забезпечення високої бізнес-швидкості.
• 20% часу: Самостійна реалізація складних алгоритмічних завдань або вивчення нутрощів рантайму мови без жодних ШІ-інструментів.

4. Практичні інженерні сценарії в продакшені

01. Розбір падіння продакшен-бази під навантаженням Black Friday

Під час напливу покупців сервер баз даних заблокувався через вичерпання пулу з'єднань (Connection Starvation). Розробник, який написав код через агента, безпорадно кидав логи помилок у чат моделі, яка пропонувала безглузді перезапуски. Старший інженер, який розумів модель пам'яті та транзакційні блокування, за 2 хвилини знайшов витік з'єднань у необробленому блоці помилок і врятував бізнес від колосальних збитків.

02. Провал сеньйор-кандидата на технічному інтерв'ю

Розробник із 7-річним досвідом продемонстрував вражаюче портфоліо сучасних сервісів, написаних за допомогою Cursor. Проте під час практичної секції, де потрібно було реалізувати просту чергу завдань (Rate-limited Queue) без доступу до інтернету, кандидат не зміг написати навіть скелет функції через нездатність мислити без готових генерацій.

03. Свідоме занурення в реалізацію протоколу

Інженер використовує бібліотеку для роботи з WebRTC. Замість сліпого копіювання коду асистента він бере один робочий день на те, щоб прочитати RFC специфікацію протоколу ICE, STUN та TURN. Це дозволило виявити приховану діру в конфігурації NAT-траверсу, яку модель не могла побачити через відсутність контексту мережевої топології.

5. Підводні камені, типові помилки та безпека

1. Ефект Даннінга-Крюгера на стероїдах: Джуніор або початківець, отримавши доступ до потужних агентів, починає вважати себе Lead Architect за 2 місяці, оскільки "швидко будує сервіси". Це створює токсичну самовпевненість і призводить до відкидання порад досвідчених колег.
2. Сліпа віра в безпеку згенерованих алгоритмів: Модель може згенерувати швидку реалізацію криптографічного підпису, яка здається правильною, але містить вразливість до атак повторного відтворення (Replay Attack) або витоку через часові характеристики (Timing Leak). Без знання криптографії інженер ніколи не виявить цей дефект.
3. Повна втрата здатності до системного мислення (Cognitive Atrophy): Якщо мозок не тренувати в утриманні складних логічних ланцюжків, нейронні шляхи деградують. Постійно змушуйте себе читати чужий складний код, вивчати відкриті бібліотеки ядра та розуміти вихідний код рантаймів (Node.js, V8, Go runtime).