AI Dev

Как меняется
работа руководителя
под влиянием ИИ

AGENTS.md: как научить AI работать по правилам вашего проекта? 🤖

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

С AI-агентом похожая ситуация. Здесь помогает файл AGENTS.md.
Это текстовый файл с инструкциями для AI-агента. В нём можно описать, как устроен проект и какие правила необходимо соблюдать при изменении кода.

Например, для Java/Spring Boot проекта можно зафиксировать:
• использовать Java 25 и Spring Boot 4;
• придерживаться существующей архитектуры;
• бизнес-логику размещать в Service;
• для новых методов писать unit-тесты;
• перед завершением задачи запускать mvn test;
• не изменять публичные API без необходимости;
• не добавлять зависимости без обоснования.

Что это даёт?
- Не нужно повторять одинаковые инструкции в каждом запросе.
- Меньше случайных архитектурных решений.
- Код лучше соответствует стандартам команды.
- Агенту проще работать с незнакомым репозиторием.
- Новые задачи выполняются более предсказуемо.

AGENTS.md поддерживается многими AI-инструментами, включая OpenCode. При этом конкретные правила загрузки инструкций зависят от инструмента и расположения файлов.
Важно: этот файл не гарантирует идеальный результат. AI может ошибиться или нарушить инструкцию, поэтому тесты и code review по-прежнему необходимы.
Главная мысль: чем лучше вы описали правила проекта, тем меньше AI приходится додумывать самостоятельно.

Multi-Agent: зачем использовать несколько AI-агентов вместо одного? 🤖

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

Но можно пойти дальше — использовать несколько специализированных агентов, каждый из которых отвечает за свою часть работы.

Например:

1. Analyst
Изучает требования и существующий код, формирует план реализации.

2. Developer
Получает план и пишет код.

3. Code Reviewer
Независимо проверяет изменения: архитектуру, ошибки, безопасность и соответствие требованиям.

4. Tester
Запускает тесты, анализирует результаты и проверяет сценарии.

Получается цепочка:
требование → Analyst → Developer → Reviewer → Tester
Почему это может быть лучше одного универсального агента?

1. Разделение ответственности
Каждый агент концентрируется на своей задаче.

2. Независимая проверка
Reviewer может найти ошибку, которую Developer не заметил.

3. Разные модели
Для простого анализа можно использовать дешёвую модель, а для сложного программирования — более мощную.

4. Разные инструменты и права
Developer может изменять код, а Reviewer может работать только в режиме чтения.

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

6. Специализация
Можно создать отдельного агента для Java, тестов, безопасности, документации или DevOps.

7. Масштабирование
При сложных проектах можно добавлять новых агентов, не превращая одного агента в огромный набор инструкций.

В результате получается уже не просто AI-помощник, а виртуальная команда разработчиков.

И человек постепенно смещается от роли «пишу каждую строчку кода» к роли архитектора и руководителя AI-агентов.

OpenSpec: как управлять разработкой с помощью AI? 🤖

Когда AI пишет код, самая большая проблема часто не в генерации самого кода.

Проблема — правильно поставить задачу.

Если написать AI:

«Добавь авторизацию»

агент может самостоятельно выбрать архитектуру, изменить несколько классов и реализовать совсем не то, что ожидалось.

Здесь интересен подход OpenSpec.

OpenSpec предлагает сначала описать что именно должно измениться, а уже потом переходить к реализации.

Упрощённо workflow выглядит так:
требование → спецификация → план изменений → AI-код → проверка

Например, вместо:
«Добавь JWT авторизацию»
можно зафиксировать:
• какие endpoint'ы должны быть защищены;
• какие роли существуют;
• какие claims находятся в JWT;
• что происходит при отсутствии токена;
• какие ошибки возвращаются;
• какие тесты должны появиться.

После этого AI-агент получает гораздо более точные ограничения.

Например:
OpenSpec → OpenCode → Java/Spring implementation

OpenSpec отвечает на вопрос:
«Что мы должны построить?»
А OpenCode и подключённая LLM помогают ответить:
«Как это реализовать в существующем проекте?»

Особенно полезно это становится в больших проектах, где AI работает не с одним классом, а с десятками сервисов, API, БД и тестов.

Главная идея:
AI не должен каждый раз самостоятельно додумывать требования.

Сначала фиксируем спецификацию, затем позволяем агенту реализовать её.

Это делает AI-разработку более предсказуемой, проверяемой и пригодной для командной разработки.

«Среда и изменение процессов важнее модели»: почему 2026-й станет закатом эпохи Copilot’ов

Коллеги, погрузился в свежий AI-Disrupt PDLC от команды Кирилла Меньшова (Сбер). Это не просто очередная методология. Это смена инженерного кода - переход от точечных подсказок к архитектуре неизбежного будущего.

Главная мысль, которую сегодня ошибочно пропускают:

Ваше конкурентное преимущество рождается не внутри LLM. Оно создаётся детерминированной средой исполнения модели (Harness) и тотальной перестройкой процессов. Модели устаревают за 3–6 месяцев — они как топливо. А платформа (IDP) работает годами, как двигатель.

📉 Те, кто остановились на AI Copilot’е и выдохнули, уже в 2027 году потеряют 25% скорости.
📈 Те, кто строят среду для автономных агентов, получат кратный рост.

Что меняет рынок? Ключевые сдвиги AI-Disrupt PDLC:

1. Двухконтурная модель (Two-Loop)
Люди формируют намерение (Intent). Агенты занимаются реализацией (Implementation). Точкой сборки становится не код, а машиночитаемая спецификация (SDD).
2. От просто кода — к «исходному коду» новой эры
Код перестал быть главным активом. Им стал контекст и спецификация, понятная и машине, и человеку.
3. Управляющая сетка (Governance Mesh)
Контроль больше не финальные ворота перед релизом. Контроль встроен в платформу через Policy as Code. Иначе AI-инциденты съедят всю экономию быстрее, чем вы успеете её посчитать.

📌 Рекомендация Кирилла Меньшова (автора подхода):

«Не пытайтесь натянуть AI-агентов на старые Jira-процессы и ручные гейты. Это всё равно что поставить реактивный двигатель на телегу. Начните с перепроектирования жизненного цикла требования — от идеи до спецификации. Сделайте машиночитаемый контекст первичным. И только потом добавляйте агентов. Иначе Copilot так и останется дорогим автодополнением, а не драйвером роста».

Прогноз на 2028 год:
Победят не те, кто просто добавил AI-ассистентов к старым процессам. Победят те, кто осмелился переосмыслить весь жизненный цикл разработки с нуля. Остальные будут догонять с потерей 25% скорости и пачкой неконтролируемых инцидентов. Выбор за вами.

DeepSeek выпустила убийцу Claude Code — десктопного агента с открытым исходным кодом

— Агент работает с файлами, кодом и терминалом прямо на компьютере;
— Вся система построена на плагинах — недостающие возможности можно добавлять самостоятельно;
— Агент умеет искать информацию в интернете, генерировать тексты и писать код;
— Поддерживает Windows и macOS.

Агент доступен бесплатно — тут:
deepseek.com/en/harness/

Что такое MCP и зачем он нужен AI? 🤖

Представьте, что AI умеет писать код, но не умеет напрямую работать с вашей базой данных, GitHub, Jira или файловой системой.

Для каждой системы можно написать отдельную интеграцию.

Но возникает проблема: у каждого AI-инструмента свой способ подключения.

И здесь появился MCP — Model Context Protocol.

MCP — это стандарт, который позволяет AI-модели работать с внешними инструментами и данными через единый интерфейс.

Условно:

AI → MCP → внешний инструмент

Например, MCP-сервер может предоставить AI такие инструменты:

• search_documents — поиск по документации;
• get_user — получение пользователя из системы;
• execute_sql — выполнение SQL;
• create_issue — создание задачи в Jira;
• get_pull_request — получение информации о PR.

AI не обязательно должен знать внутреннее устройство Jira или вашей базы.

Он видит доступные инструменты, понимает их назначение и может использовать их в процессе выполнения задачи.

Например, в OpenCode можно подключить MCP-сервер для GitHub.

Тогда агент сможет не только написать код, но и получить информацию о PR, посмотреть issue или выполнить другие доступные действия.

Поэтому MCP часто сравнивают с USB для AI:

один стандарт → множество инструментов → разные AI-клиенты.

И это одна из технологий, которая превращает AI из обычного чат-бота в настоящего рабочего помощника.