Вы все еще пишете промпты? Тогда мы идем к вам!
Если вы думаете, что главный навык будущего - составление правильных запросов нейронке, буду рад позлорадствовать - поезда уже не видно, в нем уехали агенты.
В 2026-м вопрос "как правильно спросить" уже не стоит. Теперь все крутится вокруг трех вещей, это память, делегирование и оркестрация. Коротко расскажу про новшества, которые увидел в этих ваших интернетах.
1. Память у агента - как у золотой рыбки
Мы все знаем, что агенты каждый раз нас встречают с улыбкой и как в первый: "Привет! Чем могу помочь?". Памяти - ноль. Я так в институте учился, после сессии в голове было только перекати-поле.
Вы все еще пишете промпты? Тогда мы идем к вам!
Так вот, в целом, это не норма. Когда мы работаем с проектом, у нас есть куски памяти, это файлы AGENTS.md / CLAUDE.md, какие-то версионируемые правила, "банк памяти". Называется это context engineering, без подобных практик нормально поработать со своим проектом не получится, так как придется LLM прочесывать много материала, чтобы при каждой новой задаче с нуля разбираться с проектом.
В репозитории необходимо хранить AGENTS.md, где будет структура проекта, конвенции, почему код именно такой. Это как README, только его прочитает ваш ИИ-коллега.
2. Асинхронность. Назначил issue - гуляй смело
Второе что заметил - фоновые агенты. Люди не хотят работать, хотят просто кинуть агенту issue в трекере или алерт из Sentry, и пусть он сам склонирует репозиторий в облаке, сделает работу, откроет PR. А вы в это время… можно посмотреть что-нибудь интересное ;)
Роль разработчика немного меняется, из "человека, который пишет код" - в "человека, который раздает задачи и ревьюит". Теперь все мы староста в своей личной группе агентов. Только эта группа может еще работать по ночам и не устает.
3. Параллельность с git worktree
Просто так запустить несколько агентов в одной папке не получится. Вчера на стриме про это немного поговорили, если так сделать, то мы просто получим конфликт. Решение этого уже есть - используем один git worktree на агента, изолированные порты и своя ветка базы у каждого.
Если заглядывать дальше, то можно подумать про паттерн "оркестратор", когда главный агент держит общую картину и раздает задачи субагентам. То есть нужен один дирижер и много музыкантов, а не когда каждый играет свою мелодию и называет это джазом.
4. SDD живее всех живых
Spec-Driven Development (сначала спецификация — потом код) в 2026-м уже мейнстрим. Посмотрел количество фреймворков, уже штук 15 можно насчитать: OpenSpec, GSD, Spec-Kit, BMAD, Tessl… Кого только нет.
Суть сейчас в том что нужно не просто написать спеку, а нужно как-то управлять ее жизненным циклом - валидировать, актуализировать, не давать протухнуть, чтоб не пришлось потом переписывать с нуля или мучиться с тем что LLM не понимает того, с чем она вообще работает.
Встречал статьи, где писали что можно и вовсе не тащить фреймворк, некоторые просто используют обычный Plan Mode в агентной среде и он им закрывает большую часть тех же задач.
TL;DR - что делать?
- Завести AGENTS.md в проекте - общая память для вас и агентов.
- Учиться формулировать задачи как issue - что, зачем, критерии готовности.
- Освоить git worktree для запуска агентов параллельно.
- Спека перед кодом экономит много нервов.
Мораль сей басни такова: эпоха "один промпт - одна сессия" закончилась. Да здравствует очередь задач, память проекта и восемь агентов в восьми worktree.
Если вы думаете, что главный навык будущего - составление правильных запросов нейронке, буду рад позлорадствовать - поезда уже не видно, в нем уехали агенты.
В 2026-м вопрос "как правильно спросить" уже не стоит. Теперь все крутится вокруг трех вещей, это память, делегирование и оркестрация. Коротко расскажу про новшества, которые увидел в этих ваших интернетах.
1. Память у агента - как у золотой рыбки
Мы все знаем, что агенты каждый раз нас встречают с улыбкой и как в первый: "Привет! Чем могу помочь?". Памяти - ноль. Я так в институте учился, после сессии в голове было только перекати-поле.
Вы все еще пишете промпты? Тогда мы идем к вам!
Так вот, в целом, это не норма. Когда мы работаем с проектом, у нас есть куски памяти, это файлы AGENTS.md / CLAUDE.md, какие-то версионируемые правила, "банк памяти". Называется это context engineering, без подобных практик нормально поработать со своим проектом не получится, так как придется LLM прочесывать много материала, чтобы при каждой новой задаче с нуля разбираться с проектом.
В репозитории необходимо хранить AGENTS.md, где будет структура проекта, конвенции, почему код именно такой. Это как README, только его прочитает ваш ИИ-коллега.
2. Асинхронность. Назначил issue - гуляй смело
Второе что заметил - фоновые агенты. Люди не хотят работать, хотят просто кинуть агенту issue в трекере или алерт из Sentry, и пусть он сам склонирует репозиторий в облаке, сделает работу, откроет PR. А вы в это время… можно посмотреть что-нибудь интересное ;)
Роль разработчика немного меняется, из "человека, который пишет код" - в "человека, который раздает задачи и ревьюит". Теперь все мы староста в своей личной группе агентов. Только эта группа может еще работать по ночам и не устает.
3. Параллельность с git worktree
Просто так запустить несколько агентов в одной папке не получится. Вчера на стриме про это немного поговорили, если так сделать, то мы просто получим конфликт. Решение этого уже есть - используем один git worktree на агента, изолированные порты и своя ветка базы у каждого.
Если заглядывать дальше, то можно подумать про паттерн "оркестратор", когда главный агент держит общую картину и раздает задачи субагентам. То есть нужен один дирижер и много музыкантов, а не когда каждый играет свою мелодию и называет это джазом.
4. SDD живее всех живых
Spec-Driven Development (сначала спецификация — потом код) в 2026-м уже мейнстрим. Посмотрел количество фреймворков, уже штук 15 можно насчитать: OpenSpec, GSD, Spec-Kit, BMAD, Tessl… Кого только нет.
Суть сейчас в том что нужно не просто написать спеку, а нужно как-то управлять ее жизненным циклом - валидировать, актуализировать, не давать протухнуть, чтоб не пришлось потом переписывать с нуля или мучиться с тем что LLM не понимает того, с чем она вообще работает.
Встречал статьи, где писали что можно и вовсе не тащить фреймворк, некоторые просто используют обычный Plan Mode в агентной среде и он им закрывает большую часть тех же задач.
TL;DR - что делать?
- Завести AGENTS.md в проекте - общая память для вас и агентов.
- Учиться формулировать задачи как issue - что, зачем, критерии готовности.
- Освоить git worktree для запуска агентов параллельно.
- Спека перед кодом экономит много нервов.
Мораль сей басни такова: эпоха "один промпт - одна сессия" закончилась. Да здравствует очередь задач, память проекта и восемь агентов в восьми worktree.