Чому я майже перестав використовувати ШІ
Мене звати Олександр, я в розробці більше 20 років. Я із «старої школи», але не луддит і не людина яка принципово проти нових інструментів. Я просто помітив що стаю гіршим спеціалістом саме через ШІ. І я зупинився.
Той тиждень
Кілька місяців тому я вивчав нову для себе річ. Не суть важливо що саме, важливо що я спробував зробити це через ШІ — питав, отримував відповіді, пробував те що він пропонує.
І ось ця петля: я кажу «я не спеціаліст в цьому, але мені здається що те як ти пропонуєш це зробити, якось надто тупо, не може бути щоб спеціалісти справді робили це саме так. Ця задача має бути типовою для сфери, не могли ж вони за стільки років, не придумати нічого кращого» — ШІ відповідає «так, твоя інтуїція абсолютно правильна, зазвичай роблять інакше...», «а якого тоді ти...», «вибачте, раніше я припустився помилки...» — і так по колу. Кожні день-два я викидував усе на смітник і починав заново, бо виявляється «так, ти абсолютно правий, робити так у 2026 нонсенс!», чи щось подібне.
І так трохи більше тижня — в смітник.
Потім я відкрив документацію. Просто доку, як робив це більше десятка років до ери ШІ. За два дні все стало на місця. І я відчув те що не відчував давно — той кайф коли щось нарешті розумієш. Не «ШІ пояснив(написав за тебе)», а саме зрозумів сам. Як новачок який вперше побачив що код працює.
Виявляється я скучив за цим відчуттям. І водночас наситився безглуздим базіканням із ШІ. А головне — це було просто ефективніше. Я більше не бачу сенсу відкривати Claude, купувати підписку чи щось подібне для таких задач. Навіщо? Щоб самоствердитись? Дякую, за декілька років існування сучасних ШІ — я вже цим наситився.
ШІ погоджується з тобою, ШІ ігнорує тебе
Архітектурна особливість. Великі мовні моделі не перевіряють істинність. Вони не запускають код. Модель просто шукає серед того, що було в датасетах.
А датасети зібрані з Stack Overflow, Reddit, репозиторіїв GitHub. Вони не передбачають відповіді «я не знаю». Якщо ти не знаєш відповідь на питання, на Stack Overflow — ти просто нічого не пишеш. ШІ цього не розуміє. У ШІ немає такого досвіду.
У моєму випадку я питав «що використати для...», а ШІ часто рекомендував застаріле — бо старих текстів просто більше. Рекомендував неіснуючі речі — або хапав щось з інших контекстів, або описував щось з інших версій. І робив це впевнено та переконливо — бо люди в коментарях Stack Overflow постійно сруться й самостверджуються, майже ніколи не визнаючи що були неправі, навіть коли для спеціаліста очевидно неправі. Саме на цьому і навчалась модель.
Отупіння
Для людини з 20 роками досвіду, «отупіння» це не абстрактна проблема.
Досвід це не знання. Знань у мідла, для конкретної задачі, може бути більше. Досвід, це коли ти дивишся на задачу і вже знаєш де буде боляче, ще до того як написав перший рядок. Це коли замовник каже що хоче одне, а ти чуєш що він просить і розумієш чим це закінчиться. Ти попереджаєш спокійно, один раз. Далі це їхні гроші і їхній вибір. Але вони запам’ятали що ти був правий. Наступного разу питають самі й зберігають гроші та репутацію.
Це і є те за що платять не як виконавцю, а як людині якій довіряють рішення. І саме цю якість я відчував що втрачаю.
В embedded і hardware особливо боляче
Я працюю в тому числі із мікроконтролерами. Тут ШІ не просто марний — він активно шкідливий.
У тренувальній вибірці застарілого коду фізично більше, ніж актуальної документації до свіжих SDK. А про нові чипи й архітектури я взагалі мовчу. ШІ статистично обирає те що зустрічав частіше. Класика коли отримуєш відповідь яка виглядає правильно, але є рішенням десятирічної давнини. А дискретні деталі він взагалі інколи часів советів рекомендує, бо діди на форумах про них колись писали. Європейскі чи американські чипи — теж дуже слабо, він не може відкрити каталог і налаштувати фільтри. Не слідкує за прес-релізами виробників. Він переважно знає лише про китайшину штибу TP4056, яку масово згадують на формуах. Про серію BQ наприклад теж знає, але це прямо треба запитувати. А щоб запитувати — треба вже знати про що питати.
Правильне питання, вже має половину відповіді. Ця істина ще більш актуальна для ШІ.
А ще ШІ не знає залізо, ні таймінги, ні обмеження по пам’яті й купу всього іншого не знає. Він часто пише синтаксично правильний код, який робить важкі операції там де їм не місце. Код скомпілюється — але краще б не компілювався. А ще він галюцинує неіснуючими регістрами, неправильними розпіновками, некоректними послідовностями ініціалізацій, і робить це капець як впевнено. А в реальності навіть між двома варіантами одного чипа — регістри можуть відрізнятись. Проте модель цього не знає.
А ще є блогери-діайвайщики — то окрема історія. Ще один капець. Embedded це непросто, але багато блогерів свідомо роблять вибір на користь простого контенту, замість правильного. Дилетанти пишуть для дилетантів, а реальні технічні статті — то надто складно, забагато букв і забагато інформації на букву. Класичний приклад знайомий багатьом: функція delay() в Arduino. Блокуюча операція. Думаю програмістам не треба пояснювати проблему яка тут виникає. Для будь-чого реального, за межами блимання світлодіодом і хоч трохи складного — непередбачена блокуюча операція це катастрофа. Це знає кожен досвідчений розробник, про це написано в офіційній документації Arduino, про це сваряться на форумах роками. Але туторіалів з delay() в інтернеті мільйони — бо так простіше розказати як блимати світлодіодом. І саме на цих туторіалах переважно навчався ШІ. Тому він і пропонує delay() — впевнено, з поясненням, як «досвідчений фахівець».
А найкращі практики embedded живуть у приватних репозиторіях, окремих профільних статтях і статтях від виробників. Їх одиниці. А ШІ переважно навчався на туторіалах від тих хто пише просто, замість того щоб писати правильно і перших спробах новачків, які на цих туторіалах виросли.
В геймдеві теж чув — дуже боляче, бо інет засраний туторіалами «як зробити гру, за пів години».
Проблема перевірки
Навіть коли ШІ правий, ти не можеш цього знати без перевірки. А перевірка в нетривіальних задачах може коштувати в рази більше зусиль, ніж коштувало б зробити самому. Ти витрачаєш час не на роботу, а на те щоб переконатись що робота зроблена правильно кимось іншим.
І навіть у шаблонних задачах, скопіювати код з аналогічного проєкту — особливої перевірки не потребує. ШІ-генерація потребує завжди. Інструмент додає крок якого раніше не існувало.
Інструмент який мав «замінити» людину, потребує додатковий, складніший етап з людиною.
А для складних задач, як рефакторинг великої кодової бази — ШІ бачить функцію, але не бачить чому вона написана саме так. Він «покращить» але зламає неписаний, але очевидний живому програмісту з досвідом конекст, підвищить ціну подальших доопрацювань. Через технічний борг виникший по причині правок роботи ШІ — уже збанкрутувала не одна компанія. Десь читав навіть звіт про рекомендації компаніям на 2026 рік, із значним впроважденям ШІ — банкрутувати продукт, поки є що банкрутувати.
А хтось довіряє ШІ навіть вести бухгалтерію...
Що я залишив
Я не відмовився від ШІ повністю. Але сильно звузив.
Як пошукова система. Як перекладач де можна додатково вказати контекст. Для роботи з чернетками текстів — це його рідна стихія, але не написання з нуля і не фінальні версії, скоріше для структування сирих думок. Як співрозмовник, але в дуже специфічному сенсі. Я не вірю тому що він каже, це більше схоже на rubber duck debugging — ти не слухаєш качечку, ти думаєш вголос поруч з нею і сам приходиш до відповіді. Я просто ігнорую більшість того що пише ШІ і продовжую говорити щось своє, розмірковуючи.
І здається все, мабуть більше нічого. Якщо щось і забув, то напевно якусь дрібницю.
А для всього де потрібне розуміння — тільки написане або принаймні перевірене людьми.
Найкращі коментарі пропустити