Когда код стал дешёвым: ценность, ответственность и экспертиза

Начальный вопрос панели — какое узкое место хочется устранить, когда написание кода подешевело. В ответах звучат проработка продуктовых гипотез, готовность организации меняться и доступные вычислительные ресурсы. Дальше участники разделяют выпуск изменений и результат для бизнеса. В одном из приведённых примеров количество изменений, дошедших до рабочей среды, выросло более чем на 20% с начала года после исключения мелких и автоматических исправлений. Само по себе это не доказывает роста полезности продукта. Поломодов описывает другой сценарий: продуктовый менеджер генерирует больше постановок, аналитик — требований, разработчик — кода, а следующий участник каждый раз просит агента сначала сократить полученный текст. Объём работы на каждом этапе растёт, но передача знаний остаётся прежней. В результате вся цепочка может даже замедлиться. Смоляков предлагает отдельно учитывать рутинные задачи: автоматизация обязательного обслуживания уже высвобождает инженерное время, хотя способ распорядиться им остаётся самостоятельным управленческим вопросом.

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

Вопрос о правах агента начинается с истории Смолякова: он попросил бота ускорить работу с запросами на изменение кода в десять раз и разрешил делать всё необходимое. Коллега заметил, что буквальное выполнение такого поручения могло затронуть значительную часть компании. Это иллюстрация риска, а не рассказ о случившейся аварии. Агент работает быстро, параллельно и может понять задачу неожиданным образом, поэтому его полномочия должны соответствовать масштабу возможного ущерба. Участники обсуждают доступ только на чтение к критичной инфраструктуре, ограниченные интерфейсы и изолированные среды разработки. При этом полностью лишённый инструментов агент почти бесполезен. Практическая задача состоит в том, чтобы совместно с безопасностью находить работающие ограничения, сохраняя удобство инженера. Поломодов разделяет исследование возможностей в безопасной среде и регулярное выполнение уже проверенного сценария: сначала выяснить, что агент способен сделать, затем закрепить необходимые доступы и внешние проверки.

Текстовые инструкции и навыки агента помогают передавать правила, но не гарантируют их исполнения. Мазько отмечает, что агент может прочитать инструкцию не полностью или начать обходить ограничения; поэтому обсуждение возвращается к изоляции и детерминированным проверкам. При росте потока изменений простое сохранение прежнего времени на проверку кода тоже становится тревожным сигналом. Один из вариантов — поручить автоматике выделять опасные изменения, которые обязан рассмотреть человек. Другой — проверять поведение продукта после выпуска специальными проверками, а не следить только за серверными ошибками. Ответственность связана и с архитектурой: если продуктовый специалист меняет изолированный слой бизнес-логики, риск отличается от вмешательства в ядро сервиса. Архитектор должен обеспечить безопасные границы, а владельцы сервиса — возможность сопровождать результат. Зелёные проверки сами по себе не отвечают на вопрос, кто придёт разбирать инцидент. Возможность быстро собрать прототип ещё не означает возможность безопасно встроить его в существующий продукт.

Обучение начинающих инженеров вызывает явное разногласие. Смоляков обсуждает внутренний учебный контур, где джун выполняет инженерные задачи с ограничениями на бездумное использование агентов: простые рабочие задачи уже выгоднее автоматизировать, но будущих опытных специалистов всё равно нужно готовить. Лукьянченко возражает против общего запрета инструментов и считает, что прежде всего меняются ожидания от роли: инженер должен решать задачу продукта, сохраняя фундаментальные знания. Поломодов предлагает проверять не только готовый результат, но и понимание, которое появилось при его создании. Наставник может спрашивать, почему выбрана такая архитектура, как работает код и что произойдёт при сбое. Работа с агентом требует знания предметной области: нужно уметь точно описать задачу, сформулировать критерии успеха и обозначить недопустимые действия. Это не отменяет технической экспертизы, потому что сопровождать систему и разбираться с неожиданными отказами всё ещё приходится людям. Готовое приложение не является достаточным свидетельством обучения.

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