AI Dev

Может ли AI самостоятельно исправлять ошибки в CI/CD? 🤖

Представьте: разработчик отправил изменения в GitLab, запустился pipeline, но сборка упала. Обычно нужно открыть логи, найти причину, исправить код и запустить pipeline заново.

А что, если часть этой работы поручить AI-агенту?

Например, процесс может выглядеть так:

1. Pipeline упал

Maven обнаружил ошибку компиляции или тест завершился неудачно.

2. AI анализирует логи

Агент получает сообщение об ошибке, изучает затронутые классы и ищет причину.

3. Исправляет код

Например, корректирует тест, исправляет несовместимость типов или устраняет ошибку конфигурации.

4. Запускает проверку

Агент выполняет `mvn test` или другую разрешённую команду.

5. Создаёт исправление

Если проверки прошли, агент может подготовить commit или Merge Request для разработчика.

Что это даёт?

• меньше времени на поиск типовых ошибок;
• быстрее исправляются упавшие тесты;
• разработчику не нужно вручную разбирать каждый лог;
• повторяющиеся проблемы можно автоматизировать.

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

Поэтому разумный подход — разрешить агенту анализировать ошибки и создавать MR, а слияние и релиз оставить под контролем команды.

В итоге CI/CD превращается не только в систему проверки кода, но и в среду, где AI помогает устранять проблемы.

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

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/