Репост из: AI Product | Igor Akimov
Как перевести команду разработки на AI-агентов
Провёл сегодня тренинг для продуктовой команды (мобильное приложение, несколько миллионов установок), и после него прилетел вопрос про разработчиков, как им-то переключится и какие инструменты использовать.
Ну, мое мнение, что всякие блогерские и ютюбовские советы, а также специализированные скиллы и MCP становятся неактуальными при первом же большом обновлении моделей или оболочек, поэтому единственное, к кому стоит прислушиваться - ведущие лаборатории. Они знают, над чем работают и что будет неактуально уже в ближайший месяц и при это могут выстраивать state-of-the-art процесс с текущими моделями, чтобы быть быстрее и круче конкурентов.
Короче, что стоит изучить:
Самый содержательный текст про agent-first команду – Harness engineering от OpenAI. Люди задают архитектуру, ограничения и критерии качества, агенты исполняют. Короткий AGENTS.md (~100 строк) служит картой, а не простыней инструкций. Документация, планы и техдолг живут рядом с кодом, а их актуальность проверяют CI и отдельные «doc-gardening» агенты.
Для руководителей есть более широкий Building an AI-native engineering team – про изменения по всему SDLC и то, что ownership кода всё равно остаётся за инженерами.
У Anthropic главный практический документ – Best practices for Claude Code: CLAUDE.md, workflow «исследовать - спланировать - реализовать - проверить», subagents, hooks, worktrees. Ключевая мысль: агенту нужен исполняемый способ проверить свою работу – тест, сборка, линтер, скриншот.
Для обмена командными практиками лучший механизм – skills: повторяемые workflows типа fix-issue или review-api-change лежат в репозитории и работают у всех одинаково. У OpenAI это описано в Customization, а почему нельзя просто свалить все знания команды в один гигантский промпт – объясняет Effective context engineering.
По параллельной разработке рекомендации совпадают у обоих:
– начинать с независимых read-heavy задач: ресёрч кодовой базы, анализ логов, поиск пробелов в тестах, code review, это можно делать с любой системой и любой ИИ-кой
– изолировать агентов через git worktrees – отдельный checkout на каждого
– выбор архитектуры (routing, orchestrator-workers, evaluator-optimizer) разобран в Building effective agents
– для длинных задач – журнал прогресса и проверяемое состояние для следующего агента, см. Effective harnesses for long-running agents
В общем, советы вроде банальные, но их никто не делает, все оптимизируют локальную свою работу, а в итоге даже при переходе на другую ИИ-ку, а тем более другому сотруднику уже будет плохо: короткий CLAUDE.md/AGENTS.md как карта, docs/ рядом с кодом, skills для повторяемых workflows, CI проверяет правила механически, тесты – критерий завершения работы.
Провёл сегодня тренинг для продуктовой команды (мобильное приложение, несколько миллионов установок), и после него прилетел вопрос про разработчиков, как им-то переключится и какие инструменты использовать.
Ну, мое мнение, что всякие блогерские и ютюбовские советы, а также специализированные скиллы и MCP становятся неактуальными при первом же большом обновлении моделей или оболочек, поэтому единственное, к кому стоит прислушиваться - ведущие лаборатории. Они знают, над чем работают и что будет неактуально уже в ближайший месяц и при это могут выстраивать state-of-the-art процесс с текущими моделями, чтобы быть быстрее и круче конкурентов.
Короче, что стоит изучить:
Самый содержательный текст про agent-first команду – Harness engineering от OpenAI. Люди задают архитектуру, ограничения и критерии качества, агенты исполняют. Короткий AGENTS.md (~100 строк) служит картой, а не простыней инструкций. Документация, планы и техдолг живут рядом с кодом, а их актуальность проверяют CI и отдельные «doc-gardening» агенты.
Для руководителей есть более широкий Building an AI-native engineering team – про изменения по всему SDLC и то, что ownership кода всё равно остаётся за инженерами.
У Anthropic главный практический документ – Best practices for Claude Code: CLAUDE.md, workflow «исследовать - спланировать - реализовать - проверить», subagents, hooks, worktrees. Ключевая мысль: агенту нужен исполняемый способ проверить свою работу – тест, сборка, линтер, скриншот.
Для обмена командными практиками лучший механизм – skills: повторяемые workflows типа fix-issue или review-api-change лежат в репозитории и работают у всех одинаково. У OpenAI это описано в Customization, а почему нельзя просто свалить все знания команды в один гигантский промпт – объясняет Effective context engineering.
По параллельной разработке рекомендации совпадают у обоих:
– начинать с независимых read-heavy задач: ресёрч кодовой базы, анализ логов, поиск пробелов в тестах, code review, это можно делать с любой системой и любой ИИ-кой
– изолировать агентов через git worktrees – отдельный checkout на каждого
– выбор архитектуры (routing, orchestrator-workers, evaluator-optimizer) разобран в Building effective agents
– для длинных задач – журнал прогресса и проверяемое состояние для следующего агента, см. Effective harnesses for long-running agents
В общем, советы вроде банальные, но их никто не делает, все оптимизируют локальную свою работу, а в итоге даже при переходе на другую ИИ-ку, а тем более другому сотруднику уже будет плохо: короткий CLAUDE.md/AGENTS.md как карта, docs/ рядом с кодом, skills для повторяемых workflows, CI проверяет правила механически, тесты – критерий завершения работы.