Інженери на старті кар'єри: пишіть код самі, поки це не зробив AI
Нещодавно я за кілька тижнів побудував нативні застосунки для iOS та Android, перевіряючи кожен рядок, написаний AI, і тримаючи агента в жорстких рамках. Обидва застосунки досі працюють, хоча жоден із них ще не вийшов у продакшн. А ось реального володіння цими платформами я так і не здобув.
Саме на цьому розриві тримається вся ця стаття, і стосується вона передусім інженерів на старті кар'єри. Агент видасть вам робочий результат швидше, ніж ви побудували б його самі. Проблема не в швидкості. Проблема в тому, що ви пропускаєте дорогою.
Я перевірив кожен рядок. Платформи я так і не вивчив
Це був не мій перший мобільний проєкт. Роками раніше я випускав застосунки для Windows Phone, а близько 2015-го працював із Xamarin, Ionic та React Native. Утім, нічого з цього не було нативним для iOS чи Android, і від цього мене відділяло ціле десятиліття, за яке інструментарій пройшов через SwiftUI, Jetpack Compose і модель async/await у Swift. Коли нещодавній проєкт вимагав нативних застосунків на обох платформах за кілька тижнів, я знав, що цей розрив закриє переважно AI-агент для написання коду.
Я підійшов до цього не безтурботно. Я знав, чим ризикує кодова база, коли агента відпускають у вільне плавання. Тож я переглядав кожен diff рядок за рядком і побудував жорсткі обмеження, щоб тримати під контролем і його зону відповідальності, і результат. Це спрацювало: обидва застосунки досягли робочого стану й робили те, що мали робити.
Те, чого я насправді навчився, чітко розділилося надвоє. Там, де агент правильно застосовував API з першої чи другої спроби, я переглядав код, розумів, що він робить, і рухався далі, а сам API так і не ставав моїм. Там, де агент застрягав, я сам відкривав документацію платформи й розв'язував проблему по-старому. Таких викликів, які не виправляв жоден промпт, набралося кілька. Ці API я тепер знаю напам'ять. Решту я досі можу пояснити, але не зміг би відтворити з пам'яті.
Потім у проєкт долучився розробник, який роками писав продакшн-код на Swift. Майже одразу він почав ставити добрі питання, саме ті, які перегляд коду сам собою не виявляє:
- який патерн був ідіоматичним, а не просто робочим
- де виклик непомітно коштував продуктивності
- що платформа мала на увазі, а код ніколи не проговорював
За кілька днів він покращив продуктивність більше, ніж мій процес перегляду коду за тижні.
Це й був доказ: перегляд коду загострює судження, але лише практична боротьба формує впевнене володіння, і впевненим я став лише в тих небагатьох місцях, де агент не міг мене врятувати. У решті випадків я був компетентним рецензентом. Це реальний результат, лише не той, що формує знання платформи.
Розуміння закріплюється через боротьбу
Цей поділ збігається з тим, що я спостерігав понад десять років, керуючи інженерними командами: люди навчаються в той момент, коли щось перестає бути легким, а не раніше. Те, що я знаю як інженер, я знаю тому, що виборов це, а не тому, що воно прийшло готовим. Кожен сильний інженер, з яким я працював, пройшов той самий шлях: вдарився об стіну, зазнав невдачі і лише тоді зрозумів, чому стіна мала саме таку форму.
Когнітивний психолог Роберт Бйорк має для цього назву: бажана складність. Його дослідження показали, що легкі умови навчання (швидкі відповіді, гладкі шляхи, відсутність тертя) часто дають найслабше довгострокове засвоєння. Саме боротьба за те, щоб самому знайти чи побудувати відповідь, закріплює її. А відповідь, яку просто вручили, випаровується вже до четверга.
AI-агент прибирає саме це тертя. Попросіть його написати функцію, пояснити трасування стека чи скаффолдити цілу фічу, і він це зробить: чисто, з першої спроби, здебільшого. Для того, хто вже є сеньйором у сфері, де працює агент, це переважно економить час: судження вже сформоване, тож усе просто виконується швидше. Для того, хто ще тільки формує це судження в цій сфері, та сама легкість прибирає єдиний механізм, який міг би його сформувати. На цьому проєкті, скільки б років я не напрацював деінде, я був людиною другого типу.
Робочий код не доводить, що ви його розумієте
Це не аргумент проти використання AI заради швидкості. Застосунки, які я побудував, працюють. Проєкт отримав те, що йому було потрібно, у той строк, який був потрібен, навіть попри те, що запуск ще попереду. Агент зробив це можливим за тижні, а не за той час, який пішов би в мене на те, щоб спершу вручну вивчити дві мобільні платформи. Якщо єдина мета — постачання результату, AI вартий кожної вкладеної в нього хвилини.
Але постачання результату й майстерність — це різні валюти, і AI платить лише в першій. Усюди, де він не провалюється відверто, він приховує складність замість того, щоб їй навчати. Чи є патерн ідіоматичним, чи просто робочим, чи один виклик непомітно коштує дорожче за інший: усе це вирішується всередині моделі, поза вашим полем зору, і ніколи не стає вашим. Це та сама сліпа зона, через яку агент здатний згенерувати чисту заміну, яку сам не може пояснити, для коду, якого він від початку не розумів.
У всього цього є справедливе заперечення: вміло промптити агента — окрема навичка, і джуніори, можливо, мають кращі стартові позиції для її розвитку, ніж сеньйори. Вони не витратили роки на формування поглядів про те, як має виглядати кодова база, тож новий інструмент зустрічає з їхнього боку менше опору, ніж з боку людини, яка відучується від старих звичок. Це реальний фактор, і це причина давати агентів джуніорам, а не тримати ці інструменти подалі від них.
Але це й інша навичка, ніж та, про яку йдеться в цій статті. Вміле промптування швидко дає робочий результат. Воно не пояснює, чому один виклик коштує дорожче за інший, чи який патерн платформа насправді очікує, так, як той розробник на Swift міг пояснити за кілька днів. Джуніорам, які швидко освоюють інструмент, усе одно потрібна та друга навичка, і швидкість в освоєнні інструмента її не наблизить.
Якщо ви вже настільки любите цю справу, що готові забруднити руки попри все, AI помножує те, що ви здатні побудувати. Якщо ж ви тягнетеся до нього, бо альтернатива здається надто важкою, ви обираєте шлях, який гарантовано не зробить вас кращими в роботі, за яку вам платять.
Що замість цього робити інженеру на старті кар'єри?
Ніщо з цього не означає уникати AI чи видавати його порціями за якоюсь довільною квотою на боротьбу. Це означає не робити його першим кроком. Працюють три речі, і найсильніший результат дає їх поєднання.
- Спершу проговоріть проблему з AI, який лише ставить питання, а не відповідає на них, поки не стануть видимі прогалини у вашому власному мисленні.
- Поставте собі задачу ще до того, як відкрити асистента: спробуйте розв'язати її самостійно, на час, і залучайте AI лише тоді, коли досягнете межі своїх можливостей.
- Або просто відкрийте редактор і почніть писати код, погано, ще до того, як щось запитаєте. Боротьба з порожнім файлом — не втрачений час. Це і є тренування.
Нічого складного. Важливий лише порядок: спершу боротьба, потім агент, а не навпаки. Просіть відповідь тоді, коли вже провели з проблемою достатньо часу, щоб впізнати правильну відповідь, коли побачите її.
Індустрії все ще потрібні джуніори, які стають сеньйорами
Це більше, ніж крива зростання окремого інженера. За останні кілька років я бачив, як менеджери з найму жорстко скорочували джуніорські позиції, виходячи з теорії, що сеньйори плюс AI покриють цю прогалину. Тепер індустрія заново засвоює просту істину: частина сьогоднішніх найкращих сеньйорів роками заробляла цей статус саме через таку боротьбу. Якщо зараз цю роботу не виконує ніхто, за ними просто не буде майбутнього сеньйора.
Якщо AI вже здатний за тижні виробити те, на що раніше йшли роки, щоб навчитися робити це вручну, продовжуйте ним користуватися. Просто переконайтеся, що частину того, що ви постачаєте, ви також побудували важким шляхом. У джуніорів тут уже є перевага: менше усталених поглядів, швидше освоєння нового інструмента. Та сама відкритість однаково добре працює й на новій платформі, коли в полі для промптів закінчуються відповіді. Витратьте частину цієї відкритості на редактор так само, як на агента, і через десять років ви все ще зможете робити цю роботу без нього.