Чуть более полугода назад у нас с Валерой был стрим про высказывание CEO Anthropic, мол, через 6 месяцев модели будут писать 90% кода. На стриме, как мне кажется, я очень хорошо описал некоторые из важных оговорок при оценке подобного рода высказываний: — есть разница «могут» и «делают» — это может быть применимо к определённым языкам программирования, а не всем — часть подходов к разработке придётся пересмотреть, чтобы было проще интегрировать ИИ-инструменты — это может быть применимо к свежим проектам, а не 15+ годичной давности — это может быть применимо к проектам до определённого размера, а не кодовой базе всего Фейсбука, например Сами Anthropic сейчас говорят, что Claude Code написан их же моделями на 90%. Но большинство подобных заявлений исходит от разработчиков моделей / продавцов ИИ-инструментов, поэтому многие (не я) их отметают. Aider, АИ-ассистент для программирования с открытым исходным кодом, который я как раз упоминал на стриме, от релиза к релизу то и дело перешагивает планки 75-80% — уже солидный показатель. И вот наткнулся на блог Armin Ronacher, создателя Flask, Jinja, Click и других крупных популярных проектов. Цитаты из поста (но рекомендую прочитать оригинал целиком): — Что касается инфраструктурного компонента, который я начал разрабатывать в своей новой компании, то, пожалуй, больше 90% моего кода написано с помощью ИИ. Я не хочу вас убеждать — просто поделюсь тем, что узнал. Отчасти потому, что я подошел к этому проекту иначе, чем в своих первых экспериментах. — Сервис написан на Go с небольшим количеством зависимостей. Сейчас в нём около 40 000 строк, включая Go, YAML, Pulumi и несколько специальных SDK-прослоек. — Я установил высокую планку, особенно в плане надёжности работы. Я уже работал с подобными системами и знал, чего хочу. — Я уделяю пристальное внимание основам архитектуры системы, структуре кода и взаимодействию с базами данных. Я невероятно самоуверен. Поэтому есть вещи, которые я не позволяю ИИ делать. Я начинал проект традиционным способом: проектирование системы, схема, архитектура. На этом этапе я не позволяю ИИ писать с нуля, а просто включаю его в свой цикл рассуждений. Это помогает мне видеть типовые ошибки, даже если я не доверяю LLM. — Для кода, сгенерированного и поддерживаемого ИИ, я теперь получаю стек, который выглядит примерно так, как мне часто хотелось, но было слишком сложно сделать вручную. — Не могу не подчеркнуть, насколько плохим может быть код агентов, если не быть осторожным. Хотя они понимают архитектуру системы и то, как что-то построить, они не могут смотреть на всю картину целиком. Вам постоянно нужно вносить правильную информацию в контекст. — Легко создавать системы, которые кажутся правильными, но при использовании ведут себя неправильно. Вот пример: я попросил его создать ограничитель лимитов. Он «работал», но не имел джиттера и использовал неудачные решения по хранению данных. Легко исправить, если знаешь ограничители лимитов, но опасно, если не знаешь. — Для меня это дошло до того, что я уже не представляю, как можно работать по-другому. Да, я, вероятно, смог бы обойтись без ИИ. Но я бы построил другую систему, потому что мне пришлось бы идти на другие компромиссы. Такой подход открывает возможности, которые я обычно пропускаю или откладываю. — Исследование + разработка вместо «исследование, а разработка потом»: на некоторые вещи, на понимание которых у меня ушел бы день или два, теперь уходит 10–15 минут. — Пишет ли ИИ 90% кода? Не знаю. Знаю только, что для меня в этом проекте ответ уже точно «да». В то же время, для меня ИИ не владеет кодом. Я всё равно проверяю каждую строчку, формирую архитектуру и несу ответственность за то, как всё это работает. === (обратите внимание, что ни о каком вайб-кодинге речи не идёт: только вдумчивая работа, где, как мне кажется, по сравнению с обычным процессом мозги приходится напрягать даже больше — пока LLM работает, ты думаешь)