О ежедневном

Сел за комп, запустил клод... А всё ли хорошо?

Councillor Hamann: ...I can’t help thinking that in a way, we are plugged into them.
Neo: But we control these machines, they don’t control us.

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

По ссылке, в канале Антона -- ежедневная рутина AI-assisted разработчика, во многом совпадающая и с моей. Но вайбкодерам, уверенным, что под капот заглядывать не надо, а тесты могут писать те, кто пишет код, замкнув круг и ограничившись поглядыванием на индикаторы, возможно, пора задуматься.

Страна советов и граблей

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

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

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

Авторежим "всё сделаю сам" лучше отключать сразу. TQM -- Total Quality Management, из глубин 1960-70-х годов учит нас, что высокого качества продукта за оптимальное время можно добиться лишь постоянным контролем на всех этапах производства, а не только приёмкой на выходе.

Поэтому необходимо контролировать "нейроболванчиков" на всех этапах. Код генерируется небольшими фрагментами, которые можно быстро оценить и подтвердить. Нужны частые архивации (commits) практически на каждый микро-этап.

Вместо пространных разъяснений, почему это "не то", просто идешь в редактор и пишешь сам, после чего тыкаешь в это место агента, чтобы делал так.

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

Нужно привыкнуть к тому, что нейроболванчики "парсят" код регулярными выражениями, поэтому ошибки делаемых на этой основе выводов случаются. И то, что полчаса назад считалось "dead code", внезапно оказывается не совсем dead. Кстати, а ты в курсе, почему регулярными выражениями нельзя, например, корректно "распарсить" твой любимый Питон?

Все, даже небольшие, изменения начинаем с создания плана. Если изменения простые "удалить неиспользуемое API и таблицу под ним", то можно просто руками это сделать за 15 минут после вычитки примерно страницы текста и внесения небольших коррективов, пошагово контролируем выполнение и прогоняем тесты.

Для более сложных изменений "не используем глобальный кэш в этом модуле, а исправляем N+1 локальными предзагрузками объектов" требуется фиксировать план в отдельном документе и по мере его выполнения корректировать методы достижения. Часто конечный план меняется радикально по мере открытия новых зависимостей, неявных, прежде всего.

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

Есть ли польза?

Разумеется, есть, как и в любом инструменте, применяемом в нужном месте и по делу.

Повышения производительности можно достичь на операциях:

• создания прототипов, только не забудьте потом их выбрасывать, а не пытаться сдать заказчику
• рефакторинга, здесь нужен максимальный контроль и минимальные инкременты
• общей ревизии кода: специалист может быстро увидеть взаимоблокировку транзакций, но упустить неинициализированную или повторно используемую переменную
• вхождения в неизвестный код, особенно наследуемый (legacy), получить короткое резюме по 1М строк за 15 минут имеет смысл
• поиск или генерация типовых примеров по документации. Персонализированный stackoverflow

Остальное под вопросом, который надо рассматривать и решать в ракурсе очевидного "программирование -- не кодирование".

О чём нужно задуматься вайбкодерам

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

Год не заглядывать "под капот" означает "я больше не программист". Навыки быстро деградируют, и даже в вайбкодинге начинаются косяки и вера в магию, которых не было изначально. Человек по сути переходит в другую профессию "как-бы-управленца". Но в отличие от карьеры реального бригадира, не развиваются навыки управления людьми и взаимодействия с вышестоящими менеджерами. По сути человек -- просто посредник по покупке токенов между заказчиком продукта и владельцами БЯМов. Рынок для такого рода работы не устоялся, и, возможно, в ближней перспективе он будет пересыщен "войтишниками", которые сейчас массово стали "выйтишниками", но уже не в ИТ, а в вайб.

И не забывайте, что любой софт становится legacy через пару-тройку лет сопровождения.

В качестве эпилога

В качестве эпилога, негативный опыт вайбкодинга в простом проекте

Небольшое GUI-приложение, взаимодействующее с буфером обмена, распознаванием текста с экрана и внешним AI-сервисом. Грубо говоря, нажал в приложении кнопку, курсор меняется на крестик, выделил кусок на экране, локальный фреймворк распознаёт текст и помещает его в текстовый контрол (TextBox). Далее, можно немного подредактировать и, нажав другую кнопку, отправить БЯМу на обработку. Полученный ответ попадает в другой TextBox, и по нажатию третьей кнопки его можно скопировать в буфер или эмулировать печать, если буфер не поддерживается.

Сценарий немного похож на "помощника" по прохождению "технических тестов", да? Слава создателю, сейчас предложение пройти онлайн такой тест говорит о не полной вменяемости компании.

Всё шло хорошо, пока не понадобилось добавить третий TextBox для ведения истории. Программа начала падать с ошибкой core dump.

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

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