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