И начать свой доклад я хотел бы с одной достаточно показательной истории. Когда
-то я делал большую фичу. Это там была пересборка шифрования. Она делалась.
И я в эту же сессию отправил, что вообще было бы неплохо ускорить тесты и
попутно убрать одну кнопочку в UI.
Отправил. Агент пошел делать. Через какое -то время я прихожу и вижу, что
примерно 60 файлов изменено. Бизнес -задача, смена шифрования, решена, все
хорошо, тесты реально ускорены почти в три раза, кнопки в UI нету, а еще
на проекте, где основная база — это Postgres, больше нету Postgres. То есть
агент выпилил все коннекторы, выпилил все упоминания и посчитал, что это как бы
окей, вот так выглядит хорошо сделанная работа. Как же так вышло?
Если попробовать сделать ретро, то огромная бизнес -задача забила контекст,
после чего тесты было принято ускорять тем самым, что сменить Postgres на
SQLite. А раз я попросил убрать кнопку, за которой стоит самый тяжелый SQL на
проекте, то как будто бы можно и вообще весь Postgres убрать, и все очень
ускорить, и все будет хорошо. Конечно, этот код никуда не поехал, но вот как
бы кодинг с агентами, он ставит вот этот вечный вопрос. На самом деле
этой истории уже больше года и, скорее всего, текущие модели и харнесы такую
грубую ошибку не сделают. Но вот этот вопрос, а как же так? Он на самом деле
никуда не ушел. И, получается,
мы задаем два вопроса. С одной стороны, у нас есть супер крутая технология,
которая, с одной стороны, пишет сложные алгоритмы, делает целые проекты целиком
автономно, а с другой стороны, она постоянно делает очень глупые ошибки,
игнорирует наши инструкции. И вот это работает у всех моделей. И самое
удивительное, что это работает одновременно.
И вот этот вопрос, а как же так? Он на самом деле не пройдет, потому что он
архитектурный,
и корни этого вопроса, они не в том, как пишется код, а в том, что
происходит до того, как этот код вообще начинает писаться. И чтобы попытаться
разобраться в этом вопросе, предлагаю посмотреть, а что же вообще делает
кодинговый агент. Здесь надо сделать небольшое отступление, что модель вообще не
видит наш код и не знает про него ничего. И LM -ка это вообще стейтлес
компонент, который работает только с тем, что мы ей передали.
И когда мы пытаемся написать какой -то код, то вот все то, что мы насобирали и
передали, то есть контекст, оно каким -то образом надёргивается из нашей кодовой
базы. Вот у нас есть огромная кодовая база, нам как -то нужно из неё что -то
набрать, это всё сформировать, и вот всё, что мы наформировали, передать в
компонент, который стейтлес. И здесь есть важный шаг,
находить наш код лучше, делать его более проверяемым и оптимизироваться
под то понимание того, что у нас теперь траектория поиска.
Агент, он, конечно, на каждом из шагов принимает решения сам, но вот эту
политику и то пространство, в котором он принимает эти решения, мы на них можем
влиять.
Пройдемся по двум частям. Первая, она достаточно простая в том смысле, что, если
вы слышали про спектривен девелопмент, про написание спек и вообще, как бы,
правильное тз, то это вот сюда. То есть, у нас на старте любой задачи, есть
огромное количество траекторий, когда мы можем пойти не туда. Вот если мы опишем
все более правильно,
то гораздо вероятнее, что мы свернем,
пойдем правильно, и тем самым часть вот этих вариантов, куда мы не должны вообще
априори изначально идти, мы уберем просто хорошо подготовив саму задачу. Здесь
очень важно писать, что должно измениться, что не должно измениться, какие -то
сложности. И вот, в общем,
вся история про спейки, она неплохо работает, и она ровно вот работает по этому,
потому что это сужает пространство слева. С другой стороны, мы должны постоянно
посматривать и оптимизироваться под этот поиск. Самый простой вариант — это хотя
бы периодически посматривать, а что же сейчас происходит с каждой фичой. То
есть просто включать трейсинг и смотреть, что сейчас модель начинает искать и
почему. И если на это отсматривать это все, то в какие -то моменты можно
понять, почему и когда вот что -то идет не так. Задуматься, порефлексировать и
пойти подоптимизировать. Это стоит поделать хотя бы глазами, но в идеале
телеметрии. Она на самом деле достаточно легко строится и вообще часто ее можно
просто включить.
С точки зрения подготовки репозитория, есть такой сейчас уже очень важный файлик
для всех кодовых агентов это agents .md и он включается каждый
старт агента точнее каждую сессию и у него есть
некоторая своя философия что этот файлик он на самом деле должен быть индексом
положить весь свагер всю документацию в этот файлик и считать что вот сейчас как
бы мы очень сильно помогли модели нет не помогли потому что этот файлик он
включается каждый раз если мы добавили то, что не нужно, конкретной задачи, вот
сюда, то это будет влиять на все принимаемые решения. Поэтому к этому файлу
нужно относиться как к индексу.
То есть указывать там, где, что находится, из чего состоит наша система. Вот мой
пример про разные смысловые выражения в разных отделах, он на самом деле вот
сюда. То есть, если правильно подготовить этот файлик, то, в принципе, наверное,
той проблемы могло и не