Кто здесь главный

роли человека и ИИ, и что бывает, когда они путаются

Что это

У работы с ИИ есть устройство, которое стоит проговорить вслух, потому что по умолчанию оно размывается.

Ты — архитектор и ревьюер. ИИ — исполнитель.

Ты решаешь, что должно получиться и подходит ли то, что получилось. ИИ предлагает, как это сделать, и делает. Решение остаётся за тобой — не потому, что ИИ глуп, а потому, что отвечать за результат будешь ты.

Что это значит на практике

Архитектор решает, что строить

Какую задачу вообще решаем. Какие части у проекта. Где хранятся данные. Что важнее — скорость или простота. Это решения, которые нельзя делегировать: у ИИ нет ни твоих ограничений, ни твоих планов, ни знания, зачем всё это затевалось.

Ревьюер решает, что принять

Код не становится твоим от того, что он появился в твоём файле. Он становится твоим, когда ты его прочитал и согласился. До этого момента в проекте лежит чужое решение, которое ты не проверял.

Исполнитель делает и предлагает

ИИ хорошо пишет код, подсказывает варианты, объясняет чужие решения и замечает то, что ты пропустил. Он может — и должен — спорить и предлагать лучше (статья 3.11). Но последнее слово не за ним.

Что бывает, когда роли путаются

Две крайности, и обе встречаются постоянно.

Ты становишься исполнителем

Выглядит так: получил код, не понял, вставил, запустил. Не заработало — попросил исправить. Опять не понял. Повторил.

Это та самая петля без чтения из статьи 1.2. Формально работа идёт, но решения принимает не тот, кто за них отвечает. Через месяц в проекте код, который никто не читал, и баг, который некому найти.

Признак: ты не можешь объяснить, что делает файл, который лежит в твоём проекте.

ИИ становится архитектором

Выглядит иначе: задача ставится общо — «сделай бота для напоминаний», — и ИИ принимает за тебя все решения. Какая база, какая структура, какие библиотеки, как хранятся данные. Всё это зафиксируется в проекте, и менять потом будет дорого.

Проблема не в том, что решения плохие. Обычно они нормальные — средние по индустрии. Проблема в том, что они не твои, а ты узнаешь о них через месяц, когда понадобится что-то поменять.

Признак: в проекте есть библиотека, о которой ты не знаешь, зачем она.

Как сказать ИИ

Роли задаются не настройками, а тем, как ставится задача. Архитектор говорит, что строить:

Хранить будем в SQLite, не в JSON — записей будет много
и нужны выборки по дате. ORM не используем, запросы
пишем руками, их немного.

Исполнителю оставляется то, в чём он силён:

Предложи структуру таблицы для подписок. Нужны user_id,
город и дата создания. Скажи, какие индексы стоит добавить
и почему.

И отдельный приём — попросить вернуть тебе роль, если чувствуешь, что решения принимаются без тебя:

Какие решения ты принял за меня в этом коде?
Перечисли списком, с вариантами, которые были.

На что смотреть

Ты давно не спорил с ИИ. Если все предложения принимаются, скорее всего, они не читаются. Нормальная работа — это несколько «нет, давай иначе» на сессию.

Ты не знаешь, почему в проекте такое решение. Любая часть, про которую нельзя сказать «я выбрал это, потому что…», — чужая.

Задачи формулируются как «сделай хорошо». Так говорит заказчик, а не архитектор. Архитектор называет ограничения.

Правки принимаются без чтения диффа. Самый надёжный признак, что роль ревьюера вакантна (статья 2.13).

Шпаргалка