Появилось немного времени и наконец погрузился в вопросы агентизации SDLC.

У нас в Т есть некоторый водораздел, где за агентизацию SDE отвечает один большой департмент, а остальных профессий - другой (мой). Поэтому я долгое время не слишком погружался в вопросы автоматизации кодинга, играясь в основном с гринфилд проектами в кодексе. А в автоматизации энтерпрайза последние три года стабильно приносили эффекты только разного рода workflows. Так что это был ноубрейнер: основные усилия в ре-дизайн процессов и их последующую автоматизацию, и 20% тратим на ебаные идеи для рисеча 🥴.

Последний год все сильно поменялось: модели, за рл-енные на харнессы стали реально круто работать, и ебаные идеи стали проще заводиться и приносить больше эффектов. Так что я вижу, как естественным образом в ключевых проектах мы забрасываем workflows, и перелазим на харнесс инжениринг (даже там, где сам процесс вполне себе описывается стройной BPM схемой). А фундаментальная команда всё больше занимается тюнами под харнессы, нежели дистиллами отдельных кубиков: именно поэтому мы перестали развивать линейку general моделей T-Pro и инвестировали в развитие экспертизы по тюнам под конкретные харнессы (T-Search).

Но все, кто занимался агентизацией, знает про классическую проблему размена автономности (эффекта) на качество (риски). Делаещь фабрику кода на агентах, убираешь код ревью и умираешь от отложенных эффектов в виде инцидентов и засранной нейрослопом кодовой базы. Я, как MLE, в этом вопросе придерживаюсь простого принципа: делай сильный контроль качества с оцифровкой всех необходимых тебе свойств, и тогда ты можешь позволить себе любую автономную систему под капотом. Тюнишь ее, пока тебя не начинает устраивать цифра на дашике, или деградируешь на более простую и предсказуемую автоматизацию. Благо в массовых операционных процессах такие контроли качества все равно приходится строить: без контура контроля люди начнут страдать фигней и без всяких ллм.

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

Я не уверен на 100%, что это универсально рабочая схема, но я точно беру себе на заметку идею, что выбор точки делегирования агенту задачи - это важный фактор успеха. Если общеизвестно, что агент в чем то плох, то возможно и не нужно страдать, пытаясь оцифровать ваши ожидания, а просто найти удобный промежуточный язык оцифровки ваших ожиданий, и общаться с агентом на нем, а не заставлять агента ваши ожидания угадывать.