Навичка без персони — це наказ без командира. Ви можете наповнити файл визначень обмеженнями, форматами виводу та правилами стилю, але якщо ви ніколи не скажете ШІ, ким він має бути, ви просите талановитого, але безцільного працівника вгадати назву своєї посади. Результат буде саме таким, як і очікувалося: шаблонні відповіді, що змінюють тон, рівень експертності, який різко коливається від запуску до запуску, і процес налагодження, що нагадує спроби впіймати дим.
Це важливо, тому що сучасні робочі процеси програмування з ШІ — це вже не одноразові промпти. Це модульні системи, побудовані з багатьох маленьких навичок, з'єднаних у ланцюг. Коли кожній навичці бракує чіткої ідентичності, страждає весь пайплайн.
Чому відсутність персон руйнує ваш робочий процес
Коли ви пропускаєте оголошення ролі, ви змушуєте модель самостійно імпровізувати свій авторитет. Одну хвилину вона пише код як обережний стажер, що намагається не зламати білд. Наступної — проєктує розподілену систему як провідний інженер, який бачив кожен граничний випадок. Така непослідовність не просто дратує. Вона робить ваш робочий процес ненадійним.
Проблеми накопичуються швидко. ШІ обирає випадковий голос, тому ваша кодова база починає виглядати так, ніби її написав комітет, який ніколи не зустрічався. Результати змінюються щоразу, коли ви запускаєте навичку, а це означає, що ви не можете довіряти автоматизованим тестам або перегляду diff-ів. Аудит стає неможливим, бо ви не знаєте, з якої перспективи було отримано результат. Чи був це згенерований інженером, орієнтованим на безпеку, чи продуктовим універсалом? Якщо відповідь — «як заманеться моделі», у вас немає можливості перевірити логіку.
Ланцюжки навичок погіршують ситуацію. Уявіть одну навичку, яка генерує API-контракти, і іншу, яка пише реалізацію. Якщо перша діє як прискіпливий старший архітектор, що вимагає суворої валідації, а друга поводиться як молодший розробник, який ігнорує обробку помилок, ваша інтеграція розвалиться. Ланцюг тримається лише тоді, коли кожен ланцюг знає свою ідентичність. Без цього відповідальність зникає. Коли щось ламається, ви не можете вказати на те «лінзу», яка підвела, бо жодна лінза не була визначена.
Як це виправити
Рішення просте, але конкретне. Додайте оголошення ролі як найпершу інструкцію у вашому файлі навички. Не ховайте його під правилами форматування чи схемами виводу. Починайте з ідентичності.
Використовуйте чітку структуру: «Ви — [роль] з експертизою в [сфера]». Додайте після цього одне або два речення про те, що саме ця роль робить у контексті завдання. Наприклад: «Ви — старший backend-інженер з досвідом у розподілених системах. Ваше завдання — переглядати pull requests на предмет ризиків паралелізму та проблем узгодженості даних. Ви ставите під сумнів припущення щодо управління станом і відмовляєтеся схвалювати код, у якому відсутня належна обробка помилок».
Цього достатньо. Максимум три речення. Довші біографії лише створюють шум. Моделі не потрібна історія дитинства чи список хобі. Їй потрібен професійний якір, який формує її судження.
Дотримуйтесь реальних професійних ролей. Staff software engineer або технічний письменник дають моделі зрозумілу структуру обов'язків. Пропозиція поводитися як Шерлок Холмс або середньовічний чарівник може здатися креативною, але це вносить непередбачувані асоціації, які не мають нічого спільного з вашим процесом перегляду коду. Реальні ролі несуть реальні обмеження.
Що змінюється, коли ви робите все правильно
Щойно кожна навичка отримує власну персону, весь ваш пайплайн стабілізується.
Перша винагорода — це передбачуваність. ШІ перестає вгадувати свій рівень кваліфікації. Персона старшого фахівця ставитиме складніші запитання. Вона буде ставити під сумнів розмиті вимоги, вказувати на відсутні граничні випадки та вимагати контексту, який дефолтний або молодший голос міг би проігнорувати. Визначаючи роль, ви визначаєте стандарт.
Перегляди стають швидшими. Коли колега читає результат, позначений чіткою персоною, він розуміє перспективу, що стоїть за кожною пропозицією. Він знає, чи сприймати відгук як жорстку архітектурну вимогу, чи як м'яку стилістичну перевагу. Контекст стає явним, а не неявним.
Ланцюжки навичок нарешті працюють так, як задумано. Кожна