AMA-сессия про AI-Assisted Engineering

Первый вопрос прилетел из LinkedIn: собственные гайды по работе с AI приходится переписывать почти каждую неделю, меняется до 70% текста. Литвинов считает такую долю симптомом того, что в одном инструментарии лежат вещи с разным сроком жизни, и предлагает три теста на долговечность: смена инструмента (если знание стареет от смены модели, слой волатильный), срок жизни (промпт живёт один запрос, контекст — фичу или репозиторий, принципы — годы) и переносимость (работает ли правило вне AI, при делегировании людям). Дольше всего живут намерение, инварианты и критерии приёмки — вроде инварианта, что при списании всех денег ни одна операция не проходит и любой экран показывает ноль. Средний слой — спецификации, правила проекта, AGENTS.md. Волатильное — ручки моделей, поведение кэшей, конкретный harness, codex.toml, частота чистки контекста. Не устаревает и цикл обратной связи: модели нужен не только feedforward, но и feedback.

Александр смотрит на тот же вопрос со стороны большой компании, где команды строят собственных агентов на отдельные этапы SDLC — ревью, генерацию тестов, работу с требованиями — и невольно соревнуются с generic harness. Коллеги делали агента для генерации тестов и бились за качество промптов, а потом приехали новые модели, и тесты начали генерироваться из коробки; так же было с ревью, которое условные Cursor, Claude и Codex делают без всякого know-how. Отсюда его гипотеза про период полураспада harness в полгода: при проверке значимо менялись не 50%, а около 40%. По просьбе Александра Литвинов расшифровывает само слово: harness — обвязка, дающая модели агентный цикл, инструменты, планирование, песочницу, сабагентов и автокомпакцию контекста. Она закрывает слабые места модели, но чем модель сильнее, тем сильнее мешает — как аппарат Илизарова, который не сняли после выздоровления. Сам Александр предлагает вкладываться в то, что переживёт смену модели: спецификации, верификацию и телеметрию.

Второй вопрос — как менять майндсет людей. Александр делит их на тех, кто настроен на рост и становится early adopters и чемпионами, и тех, кому важно двигаться по накатанной: мандат сверху первых подхлестнёт, а вторые начнут его неявно отрицать. Убеждает сосед по проекту, который показывает, что задачу теперь делает агент, потому что вокруг есть тесты и обвязка для безболезненного деливери. Из чата приходит третий тип — саботажники, уверенные, что AI создан всех уволить; тут участники советуют понять причину и, если не выходит, расстаться. Зрители уточняют: саботажники остаются, а двигатели выгорают. Литвинов видит проблему руководства, которое не замечает эмерджентных сообществ, и приводит антипаттерн: компания зовёт на трансформацию и жалуется на ребят, уже строящих свою платформу. Его ответ — объединяться, потому что внедрение идёт с двух сторон: Enterprise SDLC, AI-платформа и self-service сверху, чемпионы и их комьюнити снизу.

Следом разбирают вопрос про бизнес, который требует X5 пользы, раз операция стала занимать пятую часть времени. Литвинов отвечает «и да, и нет»: домены оптимизируются по-разному. В R&D ускорение, по его ощущению, бывает в сотни раз — сто агентов параллельно проверяют сто гипотез, и ограничением становится время человека на разбор результатов; а старая контейнерная база Oracle с сотнями таблиц, куда пускают только через UI, так не ускорится. Директорам, которые просят X10, он предлагает сначала разобрать этапы работы и понять, что вообще можно схлопнуть. Александр добавляет системный взгляд: сгенерированный фронтенд бесполезен, если блокер сидит в бэкенде, бизнес-процессе или бизнес-постановках. Пример Литвинова — правила юристов, бренда и контент-политики: пока их экспертиза не вынесена в политики и гейты, проверяемые без людей, цепочка правок не схлопнется. Middle management он называет самой загруженной и незащищённой группой этой волны.

Третий вопрос — как снять с инженеров эйфорию от собственных скоростей и не демотивировать их. Литвинов эйфорию убирать не предлагает: менять надо определение результата — не «применил Opus 5» и не количество строк, а изменившееся поведение продукта. Александр рассказывает, как в пет-проектах набрал с агентами столько детерминированных проверок, сколько никогда не писал в обычных, и признаётся, что новое ограничение, удерживающее замысел, радует его больше выката фичи. Четвёртый вопрос — как трансформироваться обычному бэкендеру или фронтендеру. Александр видит движение в сторону forward-deployed engineer, термина Palantir: работа с агентом похожа на менеджерскую — внятная постановка, критерии готовности, приёмка в духе BDD и Cucumber. Расти стоит в понимание домена и проектирование, чтобы чувствовать неладное, когда агент предлагает взять сразу все кубики. Литвинов называет следующую ступень эволюции ролей AI-assisted engineer, а Александр добавляет про насмотренность: без набитой руки любой ответ агента звучит нормально.

Пятый вопрос — роадмап верификации работы кодинг-агентов. Литвинов начинает с того, что верификация — это не тесты после агента: генерацию можно раздать двадцати агентам, а понимание на двадцать не делится, поэтому строить надо более дешёвое принятие одного решения. Нулевой шаг — измеримая база: время человека на принятие изменения, доля переделок, метрики DORA и логирование того, какая модель, какой провайдер и какой стек промптов работали. Дальше идут намерение и приёмка, спецификации и инварианты в AGENTS.md, механические правила в хуках, классификация по blast radius и evidence-based pull request с пакетом доказательств, причём проверять изменение должен не тот агент, который его сделал. Последний вопрос — можно ли строить бизнес на коде без личного авторства. Александр отвечает через bus factor и конвейер: качество колбасы даёт не ручное перемешивание, а процесс, сертифицированный по ISO 9000. Литвинов настаивает, что именованный ответственный остаётся всегда — как и за подключённую чужую библиотеку.