Більшість мого робочого дня тепер виглядає так: я пишу prompt, описуючи те, що мені потрібно. Агент створює diff. Я переглядаю його, схвалюю або прошу доопрацювати. І так десятки разів, поки фіча не буде готова.
Питання про те, чи робить це нас «prompt engineers» — хибне. Написання промптів — це поверхнева навичка, якої можна навчитися за день. Насправді після двадцяти семи років написання коду «по-старому» змінилося те, куди спрямована ваша увага. Тепер ви менше пишете, але значно більше рев’юїте — причому в обсягах і темпах, до яких кар'єра мене не готувала.
Цикл, як він є
Якщо відкинути маркетинг, агентна розробка — це цикл рев’ю. Ви описуєте результат, агент пропонує імплементацію. Ви звіряєте її зі своєю ментальною моделлю того, що означає «правильно» для цієї архітектури, конкретного edge case чи кодової бази, і або приймаєте її, або надаєте більше контексту.
Це не нова діяльність. Це звичайне code review, хіба що автор на іншому боці ніколи не втомлюється, не сперечається і за секунди видає правдоподібний diff — незалежно від того, правильний він чи ні. Обсяги змінюють усе. Коли вузьким місцем стає не написання коду, а його перевірка, центр тяжіння професії зміщується.
Інший вид втоми
Старий підхід був стресовим лише епізодично. Ви могли витратити пів дня на баг, відчуваючи розпач через stack trace, який відмовлявся мати сенс. Це виснажувало, але темп залежав від вас. Написання коду — повільний процес, дебагінг змушує робити паузи. Хочете ви того чи ні, у ритмі завжди було «повітря».
Агентна розробка прибирає цей простір. Агент не підлаштовується під вашу концентрацію. Він просто генерує diff за diff-ом, швидше, ніж ви встигли б їх написати. Для якісного рев’ю потрібна тривала фокусована увага на рівні, який раніше вмикався лише у найскладніші моменти. Мозок не має природних пауз для перезавантаження, бо генерація ніколи не зупиняється. Цілий день у такому режимі втомлює інакше, ніж боротьба з одним впертим багом. Після двадцяти семи років звичного ритму це досі іноді вибиває мене з колії.
«Prompt engineer» — невдала назва
Ключова навичка тут — не формулювання промптів. Це розуміння того, як має виглядати результат ще до того, як ви побачите diff: чому запиту потрібен index, чому migration небезпечна при паралельному записі, чому «робоча» абстракція вилізе боком через пів року. Це судження не з'являється з практики промптингу. Воно походить із досвіду створення та виправлення власних помилок.
Найбільше користі від агентних інструментів отримують не ті, хто пише найхитріші промпти. А ті, хто може миттєво помітити одну ледь помітну помилку в згенерованому коді, бо самі колись її допускали. Prompting — це лише інтерфейс. Інженерне судження залишається головною роботою.
Що буде через п'ять років
Мені здаються ймовірними три речі:
Рев’ю стане ключовою навичкою, а не додатковим обов’язком. Більшість із нас вчилися рев’юїти як допоміжній справі. Якщо формулювання завдань та оцінка результату стають основним циклом, ми маємо свідомо вдосконалювати вміння рев’юїти якісно та швидко — так само як колись вдосконалювали знання алгоритмів.
Ми почнемо проєктувати процеси з огляду на втому рев’юера, а не лише швидкість генерації. Зараз інструменти оптимізують швидкість, з якою агент видає diff. Але справжнє обмеження — це час, протягом якого людина може тримати концентрацію. Я очікую на появу менших чекпойнтів, кращих summary змін і свідомого уповільнення темпу. Вигорання рев’юера — ось справжнє вузьке місце.
Прірва між хорошими та поганими інженерами зростатиме. Агентні інструменти — це множник. Інженер із глибоким досвідом рев’юїть швидше і помічає більше. Інженер без досвіду схвалює баги швидше, ніж раніше. Поріг для «створення робочого коду» знижується, але цінність того, кому можна довірити реліз, тільки зростає.
У чому я не впевнений
Мене непокоїть не сам цикл розробки, а те, чи збережеться професійне судження, якщо менше людей будуть роками напрацьовувати його важким шляхом. Рев’ю настільки хороше, наскільки хороша ваша внутрішня модель ідеального коду. Раніше вона будувалася через написання тисяч рядків і їх виправлення. Якщо наступне покоління почне з рев’ю, не пишучи код самостійно, я не знаю, чи сформуються у них такі ж інстинкти.
Тож ні, я не думаю, що ми стаємо prompt-інженерами. Ми стаємо головними редакторами власного коду. А якісне редагування — це окреме мистецтво, якому більшість із нас досі вчиться на ходу.