Чи варто ще вчитися, коли ШІ вже вміє все? Особистий досвід інженера каркасу
Привіт, колеги! Casey Byte на зв’язку. Як людина, яка присвятила понад два десятиліття вивченню бізнес-аналізу, автоматизації та штучного інтелекту, я постійно спостерігаю за еволюцією технологій. Минулого тижня мій друг-розробник, такий само занурений у глибокі технічні деталі, як і я, скинув мені посилання на GitHub-репозиторій під назвою “Reverse Engineer Anything” (REA). Реакція була миттєвою: захоплення, здивування, а потім – хвиля дискусій, які ми часто бачимо в інженерних колах.
Особистий досвід: Я пам’ятаю, як вперше побачив подібні інструменти. Спочатку це викликає відчуття всемогутності, ніби ми знайшли чарівну паличку. Але мій досвід підказує, що справжня цінність лежить глибше.
REA – це, безумовно, вражаючий інструмент. Він здатен розібрати готовий застосунок, детально показати його внутрішню структуру, аж до бінарного коду, а потім – відтворити. Уявіть собі, це як отримати машину часу для аналізу коду. І, звісно, це одразу викликало хвилю запитань: “Чи кодинг став непотрібним?”, “Чи замінить ШІ нас повністю?”. Це схоже на ті часи, коли поява фотоапаратів змушувала художників замислюватися над своїм майбутнім.
Проте, як старший аналітик, який бачив цикл хайпу навколо багатьох технологій, я розумію, що за захопленням стоять більш складні реалії. Я бачу, як цю тему спекулюють, стверджуючи, що якщо агенти можуть виконувати настільки складні завдання, то традиційна розробка та інженерія стають архаїзмом. Прихильники цієї ідеї пропонують нам стати “м’ясними проксі” – простими посередниками, які передають завдання ШІ, а він все робить сам. Звучить спокусливо, особливо на тлі похмурих прогнозів для інженерів, які часто циркулюють в мережі. Але, з моєї точки зору, це глибока помилка.
Я щиро переконаний, що існують навички, які стають ще важливішими з кожним днем, паралельно зі зростанням потужності ШІ.
Чому REA – це еволюція, а не кінець?
Розглянемо REA детальніше. Чому він демонструє таку вражаючу ефективність? Головна причина криється в наявному намірі. Коли ви надаєте агенту вже існуючий застосунок, він працює з готовим продуктом, де визначено функціонал та поведінку. Агент аналізує кінцевий результат і намагається відтворити процес його створення. Це схоже на те, як досвідчений механік розбирає добре налагоджений двигун – у нього є чіткий зразок для порівняння.
Професійний інсайт: Навіть у таких передових інструментах, як REA, присутній “добре спроєктоний каркас” (harness), який полегшує роботу агента. Однак, значна частина “інженерії намірів” (intent engineering) у REA вже виконана заздалегідь, завдяки наявному зразку.
Саме тому, коли хтось стверджує, що REA доводить здатність агентів створити “буквально все”, я вважаю це некоректним. Це не зовсім об’єктивна оцінка, оскільки вона базується на наявності ідеального зразка.
Пастка “м’ясного проксі”: коли знецінюється людський внесок
Але де ж тут проблема? Більшість завдань, з якими стикаються фахівці, не починаються з готового коду. Вони народжуються з ідеї, з уяви, або з вимог, викладених у Jira-тікеті. І саме тут виникає ризик перетворитися на “м’ясного проксі”, якщо ми просто передаємо завдання агенту без критичного аналізу.
Уявіть: ви отримуєте завдання. Замість того, щоб розібрати його, проаналізувати, визначити потенційні ризики та оптимальні шляхи вирішення, ви просто копіюєте його і надсилаєте своєму кодувальному агенту. Результат, який він видає, ви беззастережно приймаєте і передаєте далі. В такій моделі ваша цінність як спеціаліста зникає. Замовник міг би так само легко звернутися до агента напряму, оминаючи вас. Ви стаєте зайвим етапом у процесі.
І найгірше: відповідальність за кінцевий код залишається на вас. Як інженер, ви несете відповідальність за результат. Якщо ви виступаєте лише як “м’ясний проксі”, агент, ймовірно, не зможе втілити ваш справжній намір. Він не відчуває нюансів, не розуміє глибинних причин, чому ви хочете виправити певний баг саме таким чином, або яка саме унікальна функціональність має бути реалізована.
Практичне застереження: Я сам колись потрапляв у таку ситуацію. Отримавши запит у Slack, я одразу переслав його своєму агенту, а потім цитував його відповідь, починаючи словами: “Клод сказав…”. Це класичний приклад “м’ясного проксі” і, повірте, це викликає роздратування у колег.
“Інженерія намірів” – це справжнє мистецтво!
Так, ШІ генерує вражаючий код. Але він не вміє читати наші думки. Саме тому найважливішим навиком стає комунікація намірів. Як ми будуємо “каркас” навколо агента, щоб забезпечити його правильне розуміння? Це як навчати робота готувати борщ. Ви не просто кажете: “Зроби борщ”. Ви чітко визначаєте, якої консистенції він має бути, скільки буряка додати, як нарізати капусту.
Цей навик – комунікація намірів, побудова ефективного каркасу – стає тільки важливішим, адже ми будемо довіряти агентам все більш складні завдання.
Повертаючись до REA: чому цей, на перший погляд, простий приклад викликав такий резонанс? Тому що він ідеально ілюструє: без чіткого зразка, без визначеної мети, агент може “загубитися”.
Як побудувати зразок, коли його немає?
Більшість нашої роботи – це не реверс-інжиніринг. У нас немає готового ідеального зразка. Але це не означає, що ми не можемо його створити! Саме тут вступає в гру наше критичне мислення.
Ми – творці. Ми – ті, хто формує цей “зразок” для агента. Це може бути детальний PRD (Product Requirements Document), чіткий план проєкту, або навіть серія вивірених запитань, які допомагають агенту краще зрозуміти наше бачення. Ми створюємо документацію, яка слугує маяком для агента.
Іноді, замість того, щоб намагатися детально описати словами, як має виглядати складна 3D-гра, я знаходжу іншу гру з бажаною графікою (наприклад, “Легенди про Зельду”!) і кажу: “Ось, надихайся цим. Зроби схоже, але з певними модифікаціями”. І це працює! Агент постійно порівнює результати з цим зразком, коригуючи свої дії.
Цікавий факт: Термін “інженерія намірів” (intent engineering) якраз і описує це вміння: розпізнавати, коли можна надати агенту готовий приклад, а коли – необхідно створити його самостійно.
Мій особистий досвід: створення 3D-гри та комунікація намірів
Останнім часом я активно працюю над своєю “фабрикою програмного забезпечення” (AI software factory). Це система, яка бере ваш PRD (де ви вже прописали всі ключові наміри) і самостійно розбиває його на завдання, а потім виконує їх. Це високий рівень автономії, але саме ви залишаєтеся ключовою фігурою на початковому етапі.
Я створив за її допомогою гру. Початковий варіант був 2D, і це був непоганий перший крок. Але я прагнув до 3D. І ось тут виникли складнощі. Я – не художник і не дизайнер. Мені було надзвичайно важко донести до агента моє бачення 3D-графіки. Без чіткого зразка, без ясного візуального референсу, агент не міг досягти бажаного результату. Я мусив погодитись на 2D-версію, хоча це не повністю відповідало моїм амбіціям.
Тоді я вирішив використати підхід, подібний до REA: надати агенту чіткий візуальний референс. Я взяв графіку з “Легенд про Зельду”, яка мені дуже подобається – не ідеально 3D, але й не плоска 2D. Я сформулював завдання: “Ось гра, яка мене надихає. Створи щось подібне, але з менш “іграшковим” візуальним стилем. Постійно порівнюй результат з цим зразком”.
Це дало фантастичний результат! Після кількох ітерацій, з цим “каркасом” і постійною валідацією, моя 3D-гра почала набувати бажаної форми. Це зайняло всього день-два, але результат перевершив мої очікування.
Це яскравий приклад: навіть з найпотужнішим ШІ, з моєю “фабрикою” і найкращою моделлю Opus 5.5, я все одно мушу витрачати час на комунікацію намірів. Бо без цього агент напише просто якісний код, але він не буде тим, що вам справді потрібно.
Тест “Подвійного покращення”: чи варто вчитися?
Як зрозуміти, чи дійсно варто інвестувати час у вивчення певного навику в епоху ШІ? Я використовую простий тест: якщо наступна модель ШІ стане вдвічі потужнішою, чи буде ця навичка важливішою, чи менш важливою?
- Якщо навичка залишається так само важливою, її варто вивчати.
- Є й ті навички, які втрачають свою актуальність.
Що стає менш важливим:
- Промпт-інжиніринг: Детальні трюки для отримання кращого результату стають зайвими, оскільки моделі стають більш інтуїтивними.
- Написання складних циклів: ШІ робить це ефективніше.
- Детальне прописування правил: Величезні файли з правилами, які намагаються охопити всі можливі сценарії, можуть навіть заважати.
- Навчання ШІ базових принципів розробки: Це було актуально раніше, зараз – ні.
А що стає більш важливим?
- Планування перед написанням коду: Визначення цілей, стратегії, аналіз вимог.
- Валідація результату: Перевірка, оцінка, критика роботи ШІ.
- Комунікація намірів: Чітке формулювання потреб та очікувань.
- Інженерія каркасу (harness engineering): Побудова систем, які оптимізують роботу агента. Це включає розробку допоміжних агентів, хуків та інтеграцію в складніші платформи.
Це саме те, над чим я працюю зі своєю “фабрикою”. Це те, що зробили розробники REA. За кожною потужною системою стоїть людина, яка витратила час на критичне мислення, щоб спрямувати агента в правильному напрямку.
Інженери каркасу – нова еліта?
Ми більше не інженери коду. Код генерують агенти. Наша роль – це інженери каркасу для цих агентів. Ми створюємо їм оптимальні умови для успіху. Кожна помилка – це можливість для нас вдосконалити цей каркас.
Багато розробників, які звикли до традиційного кодингу, можуть не сприймати цю зміну. Але, друзі, це нова реальність. Якщо це не відповідає вашим інтересам, ваша роль може стати менш захопливою. Але для мене, і, сподіваюся, для вас, це неймовірно цікаво. Будувати ці системи, спостерігати, як вони еволюціонують, оптимізувати власні процеси – це справжнє задоволення.
Висновки: Що далі?
Отже, чи варто вчитися далі? Безперечно, так! Особливо, якщо ви вмієте чітко комунікувати свої наміри, створювати ефективні каркаси для ШІ та застосовувати критичне мислення для побудови зразків, коли їх немає.
У світі, де агенти стають дедалі потужнішими, роль людини трансформується. Ми стаємо архітекторами, планувальниками, стратегами. Ми – ті, хто задає напрямок. І ця здатність задавати правильний вектор, чітко формулювати наміри – це те, що ніколи не втратить своєї цінності.
Якщо ви хочете йти в ногу з часом, інвестуйте в ці навички. Не бійтеся експериментувати, будуйте свої каркаси, і найголовніше – не перетворюйтесь на “м’ясних проксі”.
Що далі? Продовжуйте вчитися, досліджувати, і, що найважливіше, – створювати. Світ змінюється, але потреба в людській винахідливості, здатності критично мислити та чітко формулювати свої ідеї – залишається.
Якщо ця розмова була вам корисною, поставте лайк і підпишіться на канал. І давайте обговоримо в коментарях: які навички ви вважаєте найважливішими в епоху ШІ?
До наступної зустрічі! Casey Byte.
