Полтора месяца вайбкодинга: какую работу программиста я передал искусственному интеллекту

Последние полтора месяца я занимался вайбкодингом. Это когда кодированием за меня занимается искусственный интеллект. В частности, я использовал Codex. Сейчас хочу поделиться своим опытом: где это работает, насколько ускоряет разработку и какие проблемы возникают.

Для начала немного о том, с какой позиции я всё это оцениваю. Это важно. Двадцать лет моей жизни были посвящены IT, не считая ещё четырёх лет учёбы на программиста. Поэтому я хорошо понимаю, как работают программисты, какой у них бывает уровень квалификации, какие навыки, распространённые ошибки и проблемы.

На последней моей позиции у меня в подчинении было два программиста. В частности, они занимались разработкой на SharePoint. Кроме того, через фирму я мог заключать контракты со сторонними разработчиками. Обычно на меня (мой сектор) работали ещё примерно пять-шесть привлечённых программистов. Если брать все проекты моего сектора (в том числе моих пооектных менеджеров) то количество подрядчиков из ИТ могло переваривать сотни человек. 

На 2020 год день работы привлечённого программиста стоил порядка десяти тысяч рублей. Бывали ставки и пятнадцать -двадцать, и до тридцати пяти тысяч в день. Обычная работа примерно десять тысяч, но чаще мы привлекали более квалифицированных специалистов.

Я и сам защищал диплом как программист в НГУ, на отделении информатики физического факультета. Примерно год своей жизни работал непосредственно программистом. А за многие годы работы консультантом одним из моих рабочих инструментов был SQL. То есть программирование для меня не чужая область: я могу не только поставить задачу и принять результат, но и самостоятельно написать или исправить код.

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

Конечно, начать писать работающий код и глубоко знать технологию не одно и то же. Помимо синтаксиса, есть библиотеки, особенности среды, инструменты и типичные ошибки. 

Теперь к сути. Для сравнения приведу один из последних проектов на прежней работе.

У меня был специалист на позиции программиста. Не могу сказать, что очень опытный. На тот момент ему было тридцать пять лет. Возникла задача: перенести на SharePoint трекер учёта инцидентов по безопасности.

Всех деталей сейчас уже не помню, но условно это три связанные таблицы с визуализацией. При определённых изменениях должны были отправляться уведомления на почту. Просто уведомления. Кроме того, было подключено ещё пятнадцать-двадцать справочников. Верификация, уведомления, всё это настраивалось через SharePoint и общую инфраструктуру компании (типа штатный инструмент для мелкой автоматизации).

Сам я подобную задачу в своё время сделал за неделю. Это было в 2007 году, на Visual Studio, на C#. Причём до этого я работал с Visual Studio примерно за семь лет до того, ещё в университете. После университета на этом инструменте не программировал, а C# на тот момент не знал. То есть осваивал новый для себя инструмент по ходу работы. Тем не менее подобную задачу сделал за неделю.

Здесь задача была приоритетной: перенести надо срочно. По опыту я понимал, что разработка должна занять примерно неделю, а тестирование — ещё недели три. Но заложил хороший запас и дал два месяца. То есть на небольшую задачу с трекером выделил два месяца работы программиста.

По факту мы сдали её через три с половиной месяца. Претензии здесь, конечно, были прежде всего к моему программисту. Это не показатель скорости всех разработчиков на рынке, а конкретный случай из моей практики. Но по срокам получилось именно так.

А теперь на днях, задачу, которую я оцениваю как более сложную, я ставлю Codex. Он подключается к серверу и за пятнадцать минут делает первоначальную реализацию. Далее идут правки, тестирование, ещё несколько изменений. Через сутки у меня на руках готовое к дальнейшей работе решение. По моей оценке, сделанное более качественно.

Содержание новой задачи я намеренно не раскрываю: это часть моего коммерческого проекта, детали которого я пока не хочу выносить в публичную статью. Поэтому читатель не сможет самостоятельно сопоставить сложность двух задач. Здесь я описываю свой практический опыт и свою оценку, а не предъявляю воспроизводимый сравнительный тест.

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

Если бы этой задачей занимался программист, ему сначала пришлось бы разбираться, как её реализовывать. По моему опыту, на выбор подхода и инструментов могли бы уйти недели две. Затем ещё неделя, а скорее две или больше, на кодирование. После этого мы могли бы ещё месяца два отлаживать решение: тестировать в опытной эксплуатации и смотреть, что получается. Самый минимальный срок я бы оценил в полтора месяца.

Но здесь важно разделить факты и оценку. Три с половиной месяца на старый проект это фактический срок. Полтора месяца и больше на новую задачу силами программиста это уже мой прогноз, основанный на предыдущем опыте. Одну и ту же задачу одновременно человеку и Codex я не отдавал.

С Codex я получил работающий результат в течение одного дня с учётом доработок. Хорошо, заложим ещё три дня на тестирование и доработки ( по фактубыла одна в первый день и все). В моих конкретных задачах разница во времени получения работающего решения получается огромной, вплоть до порядков. Но переносить это соотношение на программирование вообще было бы неправильно.

Денежные расходы на использование ИИ для такой задачи, условно не больше десяти долларов. Однако называть это полной себестоимостью тоже неверно.

Есть ещё моё время: постановка задачи, проверка результата, тестирование, поиск ошибок и переделки. Считать собственное время бесплатным, а время подрядчика платным нечестное сравнение. Поэтому десять долларов это расходы на инструмент. Полная стоимость решения включает и мой труд.

И здесь находится важная часть всей истории: Codex работает не сам по себе. С ним работает человек с двадцатилетним опытом в IT, который понимает процессы, формулирует требования, принимает результат и при необходимости способен самостоятельно поправить код.

Фактически я сравниваю две связки: «я как постановщик задачи плюс программист» и «я как постановщик задачи плюс искусственный интеллект». На описанных задачах вторая оказалась значительно быстрее. Но это не означает, что человек без подготовки автоматически получит такой же результат. Часть квалификации, которую раньше приносил программист, в этой схеме приношу я сам.

Теперь о проблемах. На более крупной задаче я столкнулся с ошибкой, которая хорошо показывает границы такого подхода.

В какой-то момент Codex вносил исправления и заменил сопоставление текста с помощью модели искусственного интеллекта Qwen на обычный алгоритм на Python. То есть изменил сам принцип решения задачи.

Дело здесь не в том, что Python плох. Qwen и Python вообще не альтернативы одного уровня: модель можно вызывать из программы на Python. Проблема в том, что вместо смыслового сопоставления с помощью модели появился обычный алгоритм, который не справлялся с нужной задачей.

Работало это дерьмово. Подмену я заметил не сразу. Несколько раз переделывал саму архитектуру, пытаясь понять, в чём проблема. А в итоге выяснилось: в какой-то момент Codex изменил подход, и именно в этой замене была причина.

Это была не просто ошибка в отдельной строчке кода. Программа могла запускаться и формально работать, но делать не то, что требовалось. И часть моего времени на дальнейшие переделки оказалась потрачена впустую. Он мне наверное птспл о подмене, но я не понял суть.

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

Подобные архитектурные ошибки Codex в моём опыте замечает плохо. Он может выполнить локальное поручение, но при этом нарушить исходный замысел. Поэтому задача должна быть поставлена достаточно точно. Причём нужно описать не только желаемый результат, но и ограничения: что можно менять, что нельзя и какие ранее принятые решения необходимо сохранить.

На одной из конференций по использованию искусственного интеллекта руководитель одного из отделов сказал мне: «Если ты автоматизируешь хаос, у тебя получится автоматизированный хаос».

Ключевое в вайбкодинге, это именно постановка задач. У тебя сам процесс должен быть разложен по полочкам. Если говорить про медиа, по моим наблюдениям, такое встречается достаточно редко.

При этом искусственному интеллекту можно и нужно ставить задачу на саму постановку задачи для программирования. Перед тем как поручить разработку, можно поручить ему помочь подготовить техническое задание: разобрать процесс, сформулировать требования, выявить неоднозначности и определить, как проверять результат.

Но принять эту постановку всё равно должен человек. Иначе непонятый процесс просто превратится в аккуратно оформленное техническое задание с теми же проблемами внутри.

В обычной работе происходит то же самое. Техническое задание, это отдельная часть проекта, которая тоже стоит денег. По моему опыту передачи работ сторонним организациям, его подготовка обычно составляла порядка пяти-десяти процентов стоимости всех работ. Конечно, от случая к случаю всё отличается, это не универсальное правило. Но порядок примерно такой.

Ещё один существенный минус ИИ: он не всегда удерживает весь набор условий проекта. Архитектор должен учитывать требования, ограничения, зависимости и уже принятые решения. Искусственному интеллекту всё это приходится явно прописывать и проверять, что он действительно это учитывает.

Предполагать, что, работая над проектом, он автоматически будет помнить всё, что сам же до этого сделал, — ошибка. Он может забыть предыдущий объём работ, прежние задачи и требования. Может затереть ранее принятые решения.

Поэтому недостаточно один раз хорошо объяснить задачу. Требования и архитектурные решения нужно фиксировать, а после изменений проверять не только новую функцию, но и то, что уже работало. Иначе ускорение написания кода можно частично потерять на поиске последствий очередного исправления.

Я неоднократно встречал сообщения о том, что отдельные крупные компании отказывались от использования ИИ при программировании из-за проблем с большими проектами. Для этой статьи мне достаточно собственного случая: проблема сохранения общего замысла и предыдущих требований у меня возникла на практике.

При всех этих ограничениях возможности впечатляют. ИИ позволяет быстро получать код на разных языках и пробовать разные технические подходы. Внутри n8n сервера срвмещены разные технологий и для конечного потребителя (меня) это круто и удобно.  Он не привязан к одному привычному инструменту так, как часто бывает привязан конкретный разработчик.

Но способность сгенерировать код на языке не означает одинаково глубокого владения всеми технологиями. Это относится и к человеку, и к искусственному интеллекту. Работоспособность, качество и соответствие задаче всё равно нужно проверять.

По моему опыту, значительную часть задач начинающего программиста и программиста среднего уровня Codex уже способен выполнять. На моих задачах он позволил обойтись без отдельного программиста, потому что постановку задачи, контроль архитектуры и приёмку результата я взял на себя.

А вот выполняет ли он часть работы специалиста или полностью заменяет человека на позиции — это разные вопросы. В моей схеме ответственность за результат никуда не исчезла. Она осталась у меня.

Поэтому утверждать, что ИИ уже заменяет любого среднего программиста, я бы не стал. Тем более мой опыт не даёт оснований говорить о полной замене архитекторов и разработчиков высокого класса.

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