Сейчас много работаю с AI-агентами и постепенно ИИ-визирую всю свою предпринимательскую и управленческую деятельность. По-моему, произошла технологическая революция по силе не меньшая, чем появление персональных компьютеров.
Как-нибудь позже хочу написать своё видение того, как протекает ИИ-переход, как он повлияет на работников интеллектуального труда, предпринимательство, медицину, ИТ-сферу и вендоров программного обеспечения. Но сейчас не об этом.
У меня нет законченной методологии работы с агентами. Какие-то принципы уже стали устойчивыми, какие-то я продолжаю проверять. Здесь хочу собрать свои текущие выводы.
1. Проектная документация должна храниться на моём компьютере
Я принципиально храню существенные факты, решения, задачи, ограничения и состояние проекта в обычных файлах на своём компьютере, а не внутри облачного сервиса или истории чата.
Для меня это вопрос независимости от поставщика модели.
Codex, Claude или Kimi могут перестать работать в любой момент по множеству причин. Но если документация по проектам, правила работы агентов, их навыки и вся история находятся в моей файловой системе, я могу подключить другого агента и продолжить работу.
Сегодня это Codex + Claude + Kimi, завтра DeepSeek, GigaChat, YandexGPT или любая другая система.
Агент заменяемый. Проектная память остаётся моей
Прим.: последние 3 недели я работаю через git-репозиторий, но об этом в другой раз
2. Агенту нужно объяснить в какой роли он выступает
Обозначаю на старте сессии. Я часто использую: в одной сессии - эксперт - руководитель процессом (chatgpt или claude), в другой сессии - исполнитель (codex или cloude code), а я владелец-согласователь Когда я игнорировал этот принцип в сложных задачах то обычно совершал ошибки и задача в итоге вставала. Самые сложные свои ошибки, архитектурные и технические долги решаю таким разделением ролей.
Если вопрос требует специфическую экспертность то описываю ее. Например: ты эксперт мирового уровня по организационному развитию с опытом 20 лет и т.д.
3. Новая задача должна начинаться в новой сессии
Для каждой новой содержательной задачи я стараюсь создавать отдельную сессию.
Если смешивать несколько задач в одном чате, контекст постепенно разрастается. Агент и я начинаем путаться, какая задача сейчас главная, какие решения продолжают действовать и что именно должно получиться в результате. Кроме того некоторые решения в старой сессии могут быть уже неактуальны, а агент по прежнему будет опираться на них при решениях.
Отдельная задача, отдельная сессия. Для меня это сейчас базовый принцип.
Каждую задачу по проекту - в отдельную сессию
4. Разные этапы могут выполнять разные агенты и модели
Необязательно поручать всю задачу одному агенту.
Один агент может помочь сформулировать задачу. Другой выполнить её. Третий перепроверить результат и найти слабые места.
Особенно важна такая проверка при сложных архитектурных изменениях и сквозных настройках, которые могут повлиять на всё рабочее пространство.
Сложные и неоднозначные задачи, в которых я сам сомневаюсь или не имею достаточной компетенции, я дополнительно проверяю с помощью сильных моделей Chatgpt, Claude и Kimi.
Для меня важен не конкретный список моделей. Он будет меняться. Важен сам принцип: сложное решение не должно считаться правильным только потому, что его предложил один сильный агент.
Последнее решение всё равно остаётся за мной.
5. Модель и агента нужно подбирать под конкретную задачу
Если всю работу отдаёшь самой сильной модели, то:
Во-первых, чаще всего получаешь увеличение времени на задачи, которые можно решить быстро.
Во-вторых, можешь получить ненужное усложнение и избыточные предложения от агента с деталями, которые в ближайшем будущем, возможно, не важны.
В-третьих, быстрее расходуешь лимиты токенов на обработку. И это критично при ограниченных ресурсах.
Поэтому сильную модель я чаще использую:
- для формулирования сложного задания;
- для сложных архитектурных задач, где много взаимозависимостей и рисков;
- когда нужно разобраться в неоднозначности, найти противоречия и ошибки, безопасно снять настораживающие блокеры или перепроверить решение.
Когда задача хорошо описана, её реализацию передаю более экономной модели
Примечания:
Сейчас я чаще всего экспериментирую с такой схемой: формулирую подробное задание в ChatGPT с моделью 5.6 Sol High или Claude Opus 5 High, а реализацию запускаю в отдельной сессии Codex с моделью среднего уровня Sol или Terra.
Еще в эксперименте у меня навык - Роутер моделей - который перед выполнением задания оценивает его сложность и либо предлагает снизить уровень (бывает редко), либо предлагает повысить уровень "размышления" модели (это случается регулярно).
6. Когда работаю одновременно с несколькими задачами - работаю на разных рабочих столах
Получается для каждой задачи - отдельное рабочее пространство с диалоговыми окнами агентов и открытыми вкладками браузера под конкретную задачу.
Переключаюсь между рабочими столами быстрым сочетанием (на маке это ctrl <- -> ) Это кратно усилило мою собранность и повысило производительность.
Примечание: Для этого нужен мощный комп с большим объемом оперативной памяти - у меня сейчас 48 gb
7. Агенту нужны инструменты, но доступ должен иметь понятные границы
Доступ к файлам, системам и другим инструментам очень сильно повышает эффективность агента.
Но вместе с возможностями появляются риски. Поэтому особое внимание уделяю определению:
- что агент может читать;
- что может менять;
- какие действия должен согласовать со мной;
- какие действия ему запрещены.
Самая простая отправная точка для меня: режим только для чтения. Затем можно постепенно передавать агенту отдельные функции под конкретную задачу.
Чем больше агент может сделать самостоятельно, тем важнее становятся границы его полномочий и протоколирование всех действий.
Сейчас я управляю этим через стандарты внутри инженерного пространства, чтобы не повторять типовые допуски и ограничения каждый раз при постановке задачи.
8. Пароли, логины, секреты, токены должны храниться вне проектной документации
Я использую защищенные хранилища Связку ключей на маке и программу Bitwarden
Для корпоративного использования хочу написать свой сервис с основой типа Bitwarden
9. В задании должно быть описано Что хотим и Зачем
Описание целевого состояния проектной задачи (результат, зачем он нужен и способ его проверки) - это наверно самая важная часть работы с агентами!
Ошибки и пробелы этого этапа пожирают максимум времени и других моих ресурсов.
Современные агенты способны самостоятельно находить решения и затем решать сложные задачи до результата. Что они не могут - знать что я хочу. Они могут предположить по контексту, но своими предположениями могут увести в сторону.
Поэтому самое важное что требуется от меня - максимально четко понимать что я хочу, зачем и описать это агенту, а затем уже совместно довести задание до подробного структурированного ТЗ.
Если раньше я говорил помощнику как делать, то сейчас почти всегда агент говорит как наилучшим способом получить результат, а я задаю какой результат нужен.
При формировании ТЗ важно передать какие ресурсы готов предоставить и в каких ограничениях должно быть решение.
Я стараюсь заранее указывать, что является результатом задачи и как агент должен проверить, что он этого результата достиг.
Если агент изменил систему, он должен проверить её работу. Если подготовил документ, должен сверить его с требованиями. Если исправил ошибку, должен убедиться, что она действительно исчезла.
Задача не заканчивается в тот момент, когда агент перестал что-то писать или менять. Он должен сам себя проверить и принести проверенный результат соответствующий критериям приемки.
Что хочу и Зачем - самая важная часть работы с агентами
10. Большую задачу нужно уметь остановить и передать дальше
Большие задачи не всегда разумно выполнять в одной сессии до самого конца.
Я стремлюсь к тому чтобы даже в случае внезапной остановки, потери интернета, VPN, ошибки компьютера и т.д. я мог "бесшовно" продолжить любую задачу. Такая передача возможна только тогда, когда существенные факты сохраняются в файловой системе.
Если все решения остались внутри предыдущего диалога, новая сессия начинает почти с нуля. Если у проекта есть нормальная документация, агент может восстановить состояние и продолжить работу с понятного места.
Тем не менее у меня еще не все "идеально" - иногда я прошу агента остановиться, собрать всю важную информацию о сделанном в отдельный документ handoff. После этого я могу продолжить работу в другой сессии, с другим агентом или на следующий день.
Я тестирую ещё такой вариант: агент-исполнитель фиксирует ход выполнения задачи в отдельный файл (дублирует свой ход сессии в чате), а агент-руководитель считывает с этого файла, что происходит. И таким образом сохраняется файл, в котором фиксируется всё по задаче плюс агент, руководитель может быть из другой системы и не имея прямого доступа к исполнителю при этом владеть всей необходимой информацией. Информация при этом не теряется при внезапном зависании задачи.
11. Использовать принцип разворачивающегося контекста
Я стараюсь не нагружать задание большим количеством контекста сразу.
По возможности даю агенту только необходимый минимум и выстраиваю работу так, чтобы по мере выполнения задачи он сам погружался в нужные детали и обращался к дополнительным файлам и инструкциям только тогда, когда они действительно нужны.
Так уменьшается количество лишней информации, а агенту проще удерживать в фокусе текущую задачу.
12. Нужно разделять состояния результата
Подготовлено, опубликовано, объединено с основной версией, развёрнуто и реально работает - это разные состояния.
Работа с кодом имеет этапы - и мне не Айтишнику пока трудно удерживать во внимании их различия.
Например сам факт того, что агент закончил работу по публикации кода или даже слиянию и прошли автоматические проверки, ещё не означает, что изменение работает в реальной системе и принято пользователями.
Я стараюсь точно называть текущее состояние результата, пишу рукописные заметки, рисую схемы иногда. Важно не перескакивать через промежуточные этапы "у себя в голове".
13. Перед существенным действием нужно заново проверять факты
Даже если состояние проекта уже записано в документации, перед важным действием я стараюсь получить свежие данные.
Нужно проверить актуальную версию, состояние системы, действующие ограничения и убедиться, что исходные предпосылки задачи всё ещё верны.
Документация помогает восстановить контекст, но она не должна заменять проверку фактического состояния. Все же у меня неидеальная система и реальное содержание проектов может по множеству причин стать отличным от содержимого документов несмотря на строгий процесс работы с репозиторием.
14. Неопределённость нужно считать отдельным состоянием
Если агент не смог подтвердить результат, это не означает, что всё прошло успешно. Но это также не всегда означает, что произошла ошибка.
«Неизвестно» - отдельное состояние, которое требует дополнительной проверки.
В рискованных действиях неопределённость должна останавливать дальнейшее движение, а не автоматически трактоваться в удобную сторону.
15. Изменения по возможности должны быть обратимыми
Я стараюсь сохранять предыдущие версии, ветки, документы и принятые решения так, чтобы работу можно было восстановить или откатить.
Особенно это важно, когда задача выполняется несколькими агентами или затрагивает рабочую систему.
Новый агент не должен исправлять конфликт уничтожением или перезаписью чужой работы.
16. Нужно разделять факт, предположение, рекомендацию и решение
Агент может обнаружить факт, сделать из него вывод, предложить вариант действий и рекомендовать один из вариантов. Но это четыре разных уровня.
Рекомендация агента не становится автоматически моим решением. Точно так же техническая готовность не означает разрешения на запуск.
Последнее решение и ответственность за него остаются за человеком.
Какие ошибки я замечаю в своей работе
1. Я пытался решать слишком много задач в одной сессии
Когда работа шла хорошо и агент уже знал контекст, мне было удобно сразу передать ему ещё одну задачу. Потом ещё одну.
Постепенно задачи смешивались, а сессия становилась перегруженной.
2. Я полагался на память чата
Пока одна сессия продолжалась, казалось, что вся необходимая информация уже есть.
Но при переходе в новую сессию часть контекста приходилось восстанавливать заново. Поэтому сейчас я сохраняю проектную документацию у себя на компьютере.
3. Иногда я слишком рано усложняю систему
Я могу начать создавать правила, реестры, статусы и дополнительные контрольные контуры ещё до того, как проверил практическую ценность самого решения.
В результате часть времени преждевременно уходит не на работу над задачей, а на обслуживание системы управления этой работой.
4. Иногда я слишком сильно дроблю связанную работу
Принцип «новая задача - новая сессия» мне по-прежнему кажется правильным. Но здесь тоже можно зайти слишком далеко.
Если разделить тесно связанные части работы между большим количеством сессий, приходится постоянно передавать контекст и восстанавливать связи между решениями. Иногда расходы на такую передачу становятся больше, чем польза от разделения. И иногда приходится искать ту самую сессию в которой было какое-то значимое действие и продолжать работу в ней, "закрывая хвосты"
5. Я не всегда достаточно чётко разделяю обсуждение и разрешение на действие
Согласиться с идеей, принять план и разрешить его реализацию - это разные решения.
Особенно важно отдельно согласовывать публикацию, объединение изменений, запуск в рабочей системе и другие действия, которые трудно отменить.
Формулировки вроде «хорошо» или «продолжай» могут оказаться слишком неоднозначными.
6. Иногда я начинаю проектировать решение до проверки текущего состояния
Документация, предыдущая сессия или память агента могут описывать уже устаревшее состояние проекта.
Я могу потратить время на подробное решение, а затем обнаружить, что изменилась версия, ветка, конфигурация или сама проблема.
Поэтому перед существенной работой нужно сначала заново проверить фактическое состояние системы. Чем больше времени прошло от последнего изменения в проекте - тем более глубокий аудит провожу и привлекаю разных агентов в разных сессиях для этого.
7. Иногда я переоцениваю независимость проверки разными агентами
Несколько агентов могут прийти к одному выводу не потому, что он правильный, а потому, что они получили одинаковый контекст и повторили одну и ту же исходную ошибку.
Поэтому независимая проверка - это не просто передать результат ещё одному агенту. Желательно менять способ проверки, источники информации или критерии оценки.
А в некоторых случаях окончательная проверка всё равно должна происходить в реальной системе и с участием меня.
Что я понял в итоге
Именно из первых двух ошибок появились мои два основных правила:
- Новая задача начинается в новой сессии.
- Проектная память хранится в моей файловой системе.
Остальные принципы постепенно выстраиваются вокруг них: подобрать подходящую модель, дать агенту необходимые, но ограниченные права, заранее описать результат, получить свежие факты, сохранить обратимость и обязательно проверить сложные решения.
При этом сами правила тоже нельзя доводить до крайности. Можно слишком рано усложнить систему, чрезмерно раздробить связанную работу или принять повторение одного вывода несколькими агентами за независимую проверку.
Это мои текущие выводы. Продолжение следует
19 сентября 2026