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

GenAI и большие языковые модели (LLM)

Фиксация знаний

Инструменты

Методологии

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

Доклад предназначен для технических руководителей, техлидов, архитекторов, руководителей платформенных и DevEx-команд, а также инженеров, которые внедряют AI-ассистентов в процессы разработки. Особенно полезен тем, кто: - развивает инженерные практики и оценивает зрелость команд; - внедряет Claude Code, Codex, Cursor, Cline и другие AI-инструменты; - отвечает за стандартизацию разработки в большой компании; - сталкивается с ростом нагрузки на code review и увеличением объёма AI-сгенерированных изменений; - ищет способ превратить корпоративную документацию в рабочий контекст для людей и AI-агентов.

Тезисы

AI снижает стоимость генерации кода, но повышает значимость инженерного контекста, ограничений и механизмов проверки.
Чем быстрее команды создают изменения, тем быстрее масштабируются не только полезные решения, но и архитектурные ошибки, устаревшие подходы и локальные договорённости.
Одного измерения зрелости инженерных практик недостаточно: команда может видеть свои показатели, но не понимать, что конкретно изменить в ежедневной работе.
Technical Capabilities Platform помогает определить разрывы в зрелости практик и сформировать направления развития команды.
Developer Book превращает стандарты из пассивной документации в живой рабочий инструмент: гайдлайны становятся доступными разработчикам и AI-агентам непосредственно во время написания кода.
Через MCP AI-ассистент может получать стандарты конкретной команды, технологии и контекста, а не опираться только на общие знания модели.
Крупнейшие AI-модели, вероятно, продолжат лидировать, но сами модели и доступ к ним будут становиться дешевле и доступнее. Устойчивое преимущество компании будет заключаться в качестве собственного контекста и способности точно передавать агентам инженерные намерения.
MCP доставляет стандарт, но не гарантирует его выполнение. Поэтому необходим контур проверки через CI/CD, тестирование, анализаторы, code review и инженерные метрики.
Целевая модель выглядит так: измерение зрелости, рекомендация, инженерный контекст, реализация человеком или агентом, проверка, обратная связь.
Главный результат — инженерная практика перестаёт быть «пыльным документом» и становится частью реального процесса разработки.

Евгений Харченко

Райффайзен Банк

Продвигает лучшие практики в разработке и эксплуатации, делится разными мыслями и идеями с сообществом в виде артефактов.
В Райфе начинал с инженера техподдержки ServiceDesk.
После в банке работал как Engineer -> Leading Engineer.
Пять лет Senior Community Lead DevOps.
Owner/TechLead команды DevOps Enabling Team.
Два года руководитель отдела по развитию практик в разработке и эксплуатации.
Член программного комитета DevOpsConf.
Активный контрибьютор в индустрии, автор проекта по развитию инженеров — «The-Way-of-DevOps».
Создатель проекта «DevOps-Origins».