9 привычек ужасного программиста: как не надо писать код

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

Действительно ли вайб-кодинг так прост, как о нём говорят? Возьмём, к примеру, дворецкого — аналог ИИ в реальном мире. Есть школы, которые специализируются на обучении новых дворецких таким навыкам, как сервировка завтрака или приготовление идеального мартини. Но знаете ли вы, что в этих же школах параллельно обучают богатых людей тому, как ладить со своим дворецким? Да, богатые люди учатся правильно держать чашку, чтобы дворецкий мог изящно наполнить её чаем. Они даже узнают, какие запросы уместны, а какие нет. Этому нельзя научиться за две минуты просмотра видео в TikTok.

Видео от DGL.RU

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

То же самое касается vibe-кодирования. О, конечно, удивительно, на что способны искусственный интеллект и генеративный ИИ. Хороший ИИ-помощник по кодированию может собрать рабочий код, который делает почти всё, что нужно разработчику, зачастую на основе всего нескольких набросков и случайных указаний (иначе говоря инженерия подсказок). Иногда достаточно ввести несколько строк, и ИИ за считаные минуты сделает то, на что в противном случае ушли бы часы или дни. Но это в лучшем случае. Ограничения кода, сгенерированного ИИ, могут быть неочевидными, но они всегда присутствуют. И что ещё хуже, мы не знаем точно, в чём они заключаются. Мы все только учимся — и люди, и машины.

Вот девять ошибок, которые разработчики программного обеспечения могут допустить при использовании vibe-кодирования.

Доверяя магистру права

Сегодня утром я попросил ИИ составить список URL-адресов. Он ответил через несколько секунд, предоставив мне удобный список в нужном формате, который выглядел корректно. Но когда я проверил, все они выдавали ошибку 404. Все до единого не работали.

Когда я сообщил об этом ИИ, он ответил: «Вы правы, приношу свои извинения! Ссылки на веб-сайты могут часто меняться, и, похоже, моя предыдущая информация была устаревшей. Я перепроверил каждую запись и обновил список правильными, работающими URL-адресами». Но ни один из URL-адресов в новом списке не работал.

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

Первая и самая серьёзная ошибка при написании кода — это доверие к языковой модели.

Предполагая, что все модели одинаковы

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

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

Количество параметров LLM также является приблизительным показателем того, какой объём знаний содержится в модели. Чем больше параметров, тем лучше — за исключением случаев, когда это не так, и иногда это можно понять только опытным путём.

LLM также обучаются на разных наборах данных, и состав обучающего набора часто остается загадкой. Ваш магистр права изучал JavaScript, взятый из открытого Интернета, или хорошо документированный код из рабочего репозитория? Достаточно ли он проглотил COBOL по пути, чтобы быть полезным при обработке вашего старого устаревшего кода?

Иногда единственный способ что-то выяснить — доверить решение проблемы с кодом машине.

Обращайтесь с LLM как с мусорным баком

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

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

Коммерческие модели, как правило, взимают плату за ввод и вывод токенов, поэтому длительные «рыбалки» могут быть более медленными и дорогостоящими. Обработка всех этих фрагментов кода требует определённых затрат.

Большое количество кода также может отвлекать ИИ и даже сбивать его с толку. Языковая модель может сосредоточиться на фрагменте кода, который не имеет отношения к тому, чего вы пытаетесь достичь. Несмотря на то, что они зачастую достаточно умны, чтобы вникать в детали, передача огромной кодовой базы вашему ИИ-помощнику по программированию может привести к обратному результату.

Если предположить, что ИИ мыслит так же, как мы

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

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

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

Создание лоскутного одеяла из кода

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

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

Игнорирование программных ошибок LLM

Все мы слышали, что ИИ хорош ровно настолько, насколько хорош набор данных, на котором он обучался. Все, что попадает в LLM, в конечном счете влияет на результат. У многих разработчиков есть истории о том, как небольшая ошибка приводила к серьезным последствиям в коде. Некоторые говорят о «предвзятости новизны», которая проявляется, когда программисты просто снова и снова используют один и тот же шаблон проектирования. Другие говорят о предвзятости «не здесь это придумали», когда команды склоняются к своим любимым разработкам. В обучающих наборах данных есть десятки предубеждений, и все они так или иначе повлияют на результат работы LLM.

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

Игнорирование затрат

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

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

Передать бразды правления

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

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

Гоняясь за галлюцинациями искусственного интеллекта

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

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

Когда я указывал на проблему, ИИ просто рассыпался в извинениях с наигранной искренностью: «Мне очень жаль. Вы правы», — говорил он. Затем он генерировал ещё более некорректный и непригодный для использования код, который был таким же неправильным, только с другой стороны.

Иногда проще написать код самостоятельно.

О боже, брандмауэр Microsoft Windows жалуется на… код Microsoft?