В качестве первого поста расскажу, чем сейчас занимаюсь в рабочее время.

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

Изначально идея заключалась в том, чтобы придерживаться так называемого Spec Driven Development (SDD). Чтобы агент написал хороший код, ему нужна чёткая инструкция — спецификация, в которой указаны все требования, технологический стек, структура проекта и другие важные продуктовые детали. Такая спецификация за один присест не пишется: в больших компаниях она проходит несколько итеративных циклов — дизайн, обсуждение с продуктом и только потом техническая реализация.

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

И у нас до какой-то степени получилось! Мечта вайб-кодера-инженера начала постепенно приобретать форму: просто сидишь, редактируешь спеки, а агент всё выполняет.

Но всплыло довольно много ограничений:

• это плохо работает с уже существующими проектами, а таких большинство. Внедрить подход SDD в легаси-код непросто
• процесс медленный: писать много спецификаций трудно, даже с автоматизацией, и на практике инженеры не особо хотят этим заниматься
• агенты не так уж хорошо справляются с тем, что их просят. Даже по суперточным, тщательно проверенным инженерами спецификациям они умудрялись сделать не то, что нужно. IDE ориентированная на SDD, Kiro, сейчас страдает от этого, люди уходят с нее, потому что не видят пользы.

Наконец, самая суровая реальность в том, что разработчики пока просто не готовы к инструментам такого рода (Прям как говорил Вова Адидас).

Энтерпрайзы только-только адаптируют Cursor (и очень редко Claude Code) и учатся измерять эффективность работы с ними.

Большая головная боль всех VP of Engineering, которые пытаются внедрить AI-инструменты в компании, сводится к тому, что:

• они не могут понять, используются ли эти инструменты вообще, потому что фидбек очень шумный
• если используются, то непонятно, насколько часто и в каких сценариях
• сгенерированный код часто очень низкого качества и его постоянно приходится править

Вот на этих пунктах мы и решили сосредоточиться. Я взял последний и провел небольшой ресёрч, чтобы проверить гипотезу. Мы спроектировали эксперимент, который показал: у агентов действительно есть проблемы с тем, чтобы писать идиоматически корректный код. Вместо того чтобы использовать готовые API библиотек, они часто переизобретают решения.

Простой пример (модели уровня Opus 4.5 или Sonnet 4.5 справляются, а маленькие могут облажаться). Допустим, вы просите агента реализовать self-attention в PyTorch. Он идёт и вручную пишет функцию со всеми умножениями q, k, v матриц, в духе собеседований. А вот «умный» агент знает, что начиная с версии 2.x в торче существует `F.scaled_dot_product_attention`, который делает всё в одну строку.

Такой примеры и показывают, что у агентов есть проблемы с идиоматичным использованием фреймворков. Мы собрали датасет из 270 популярных репозиториев и сделали бенчмарк, который оценивает именно этот аспетк: всё действительно плохо, особенно с очень старыми или очень новыми библиотеками, то есть теми, которые почти не представлены в претрейне языковых моделей.

Полный текст блога можно почитать здесь. Если есть вопросы на эту или смежные темы — буду рад ответить :)