AI/CI/CD

Claude и Codex доказали (по крайней мере мне в этом году), что программисты в том виде, какими они были раньше, больше не нужны. Точнее, больше не обязательно самостоятельно писать каждую строчку кода. Умение программировать стало частью учебного процесса, необходимого для понимания того, как всё устроено и работает. В реальной работе всё больше нужны специалисты широкого профиля, которые умеют ставить задачи, визуализировать в голове пользовательские пути для нестандартного решения прикладных задач, проектировать архитектуру и оценивать результаты.

Моя идея заключается в том, что часть функционала развития систем можно полностью автоматизировать, отталкиваясь от клиентского (пользовательского) опыта в процессе эксплуатации систем. Причём речь не только об исправлении ошибок, но и о самостоятельном выявлении потребностей в развитии функционала. Немного конкретнее расскажу, что я имею в виду.

Правда, когда я начал изучать вопрос, оказалось, что я снова изобрёл велосипед. Ещё в 2003 году IBM предложила концепцию Autonomic Computing — самоуправляемых систем, способных анализировать собственное состояние и выполнять корректирующие действия (https://doi.org/10.1109/MC.2003.1160055). Сегодня Sentry Seer (https://sentry.io/product/seer/) уже умеет анализировать ошибки и готовить исправления программного кода. А PostHog Self-driving (https://posthog.com/self-driving), представленный в 2026 году, пошёл ещё дальше: анализирует пользовательский опыт, выявляет проблемы и при помощи AI-агентов готовит pull request. То есть значительная часть моей идеи уже реализована. Но мне кажется, что применительно к сложным корпоративным информационным системам эту концепцию можно развить значительно дальше.

Представьте себе любую учётную систему, в ней есть экранные формы, какой-то функционал и пользовательские АРМ. При помощи статистических методов мы получаем информацию о работе пользователей, смотрим на время взаимодействия пользователя с экранами, анализируем пользовательские пути, типовые ошибки и сервисные предупреждения, собираем информацию об исключениях (exceptions, непредвиденные ошибки), собираем обратную связь у пользователей в виде опросов по окончании действия — насколько было просто, оцените действие, добавьте предложения.

В ходе эксплуатации системы собираются данные о путях, ошибках, клиентском опыте и т.п., которые можно в автоматическом режиме направлять AI-агентам на доработку. Агенты категоризируют заключения, выявляют повторяющиеся проблемы, предлагают техническое решение (по сути, пишут унифицированное машиночитаемое ТЗ), которое архитектор проверяет и утверждает. При необходимости привлекается функциональный заказчик, особенно если изменение затрагивает бизнес-логику.

Здесь есть важный момент. Для качественной постановки задачи агентам недостаточно знать, куда пользователь нажимал и сколько времени потратил. Необходимо понимать предметную область: бизнес-процессы, роли, структуру данных, ограничения и правила работы системы. Например, длительное согласование финансовой операции может быть не недостатком интерфейса, а обязательной контрольной процедурой. Поэтому я предлагаю объединить эксплуатационные данные, машиночитаемое описание бизнес-процессов и инженерную информацию о самой системе. Тогда агенты смогут не просто находить неудобства, но и формировать обоснованные гипотезы развития функционала.

Утверждённые ТЗ проходят автоматический архитектурный надзор, на их основе строится программа и методика ПСИ (приёмо-сдаточных испытаний), создаются тестовые сценарии (или дорабатываются существующие), далее строится план внедрения, генерируется код, выкладывается на тестовый контур, где проходит тестовый прогон. При этом важно проверять не только новый функционал, но и сохранение существующих бизнес-правил, прав доступа и совместимости с другими модулями. После этого решение представляется архитектору и функциональному заказчику для проведения ПСИ. По результатам приёмки согласовывается релиз. Для простых исправлений часть этих процедур можно автоматизировать, для критичных изменений человеческий контроль обязателен.

Но самое интересное начинается после внедрения. Система должна самостоятельно оценить, действительно ли предложенное изменение решило первоначальную проблему. Например, раньше пользователь тратил на операцию 10 минут, теперь — 3 минуты, количество ошибок уменьшилось, удовлетворённость выросла. Значит, гипотеза, вероятно, подтвердилась. Если нет — агент анализирует причины и предлагает следующее решение. Таким образом, мы замыкаем цикл: эксплуатация → анализ → постановка задачи → разработка → испытания → внедрение → оценка результата → новое развитие.

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

Очевидно, что бесконтрольно разрешать AI-агентам менять собственный программный код системы нельзя. Поэтому необходимо разграничение полномочий, независимые проверки, архитектурные ограничения и возможность отката. Но ведь и сегодня CI/CD не означает отсутствие контроля. Моя идея заключается в том, чтобы автоматизировать не только написание и доставку программного кода, но и сам процесс возникновения, обоснования и реализации изменений.