ШІ не прибере overengineering. Він його пришвидшить

Overengineering це коли ви розв'язуєте просте завдання складним способом: лендінг на мікросервісах, Kubernetes для десяти користувачів, архітектура під мільйон запитів за невеликого трафіку. Ви платите грошима й часом за рішення, яке незрівнянно складніше за саме завдання.

Так влаштовані стимули. Складне рішення читається як професійне, просте як недороблене. Нікого не звільняли за те, що він узяв Kubernetes. Звільняли за те, що не подумав про масштабування. За такої асиметрії раціонально перестраховуватися, і розробники перестраховуються.

ШІ навчався на відкритому коді та статтях, а там переважають рішення великих компаній: вони пишуть блоги, викладають фреймворки, задають моду. Завдання в них інші: мільйони користувачів, сотні розробників, вимоги регуляторів.

На запит «напиши автентифікацію» модель видає те, що найчастіше зустрічала: шарувату структуру з абстракціями, інтерфейсами й обробкою сценаріїв, яких у вас не буде. Це коректна відповідь на усереднений запит з інтернету. Ваш проєкт у це середнє не потрапляє.

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

Зараз ті самі п'ять шарів генеруються за хвилину. Код читається, тести проходять, функція працює, на вигляд усе гаразд. Але основна ціна складності припадає не на написання, а на підтримку. За півроку в цьому коді знадобиться щось змінити, і рахунок прийде тоді. Це технічний борг, узятий миттєво й без свідомого рішення.

Єдине природне гальмо overengineering'у зникло. Річ не в якості генерації: код може бути чудовим. Річ у тому, що він став надто дешевим.

Використовувати ШІ як редактора

Поширений сценарій виглядає інакше: розробник просить згенерувати модуль з нуля, отримує 500 рядків і вставляє їх у проєкт. З'ясовувати, що тут зайве, ніхто не стане, код працює. Так overengineering і потрапляє в проєкт за одну генерацію.

Зворотний порядок дає інший результат:

1. Спершу пишете самі. Тридцять рядків, простий JWT, одна функція перевірки. Зате ви розумієте кожен рядок.
2. Потім віддаєте ШІ на спрощення. «Ось код. Прибери все, без чого він працюватиме далі. Покажи, що можна викинути.»
3. Розбираєте пропозиції. Частина буде мимо, але в цьому режимі модель працює краще: знаходити зайве їй вдається точніше, ніж вигадувати потрібне.

Під час редагування є точка відліку це ваш код і ваше розуміння завдання. Під час генерації точки відліку немає, і модель підставляє усереднену.

Ще два прийоми:

• Обмеження в промпті. Якщо генеруєте з нуля, задайте рамку явно: «Найпростіше рішення, яке працює. Без фреймворків, без шарів абстракції. SQLite, один файл.»
• Контекст проєкту. Фраза «у мене 100 користувачів і сервер за десять доларів» змінює відповідь сильніше, ніж будь-які уточнення формулювання.

Компанії, які впровадили ШІ-агентів найглибше, навколо генерації вибудували цілий шар обмежень.

Stripe, за публічними описами, пропускає через ШІ понад тисячу pull requests на тиждень. Завдання для агентів формулюються вузько: не «зроби фічу», а строго обмежена зміна. Інструменти, доступні агентові, відібрані вручну. Кожен результат проходить перевірку. Компанія свідомо пожертвувала масштабом завдання заради передбачуваності результату.

У Google, Shopify та Airbnb архітектури відрізняються, єдиного стандарту в індустрії немає, кожен будує під свої ризики. Спільне в тому, що агентів вбудовують в наявні процеси (GitHub, Slack, Linear) і обкладають перевірками.

Ніхто з них не бере результат генерації «як є». Цінність з'являється від рамок навколо генерації.

ШІ підсилює те, що вже є в голові в розробника. Схильність ускладнювати він реалізує за секунди, звичку різати зайве, теж.

Рішення про те, що цей код надто складний для цього завдання, як і раніше ухвалює людина. ШІ лише виконує його швидше.