"Перевод" на человеческий

Продолжаю обзор восторженных статей на тему использования БЯМ (LLM) и замены программистов

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

Начнем по списку.

Рутинные задачи, написание бойлерплейта, стандартных функций — всё это автоматизируется

Перевод: приемлемый код генерируется только для обвязки и рутинного кода, однако не упоминается, что существует много детерминированных инструментов класса "разработка по моделям" -- MDA/MDD/Software factory, также умеющих генерировать код из метаописаний.

Писать же "стандартные функции" не требуется вовсе, нужно учиться использовать библиотечные функции и классы, в том числе -- внутренние, уже написанные "старшими товарищами".

надо давать точное техническое задание

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

Отступление: вспоминаю случай из жизни, когда ученик ознакомился с содержанием романа "Война и мир" по 20-страничной выжимке и пытался спорить с преподавателем о характерах персонажей. Есть даже выражение: "Там где ты учился, он преподавал"

меняется отношение к коду. Он становится расходным материалом, а не домашним питомцем

Перевод: код начинает восприниматься, как "черный ящик". Соответственно, в разы возрастают затраты на тестирование, которое теперь только по методу "черного ящика". И если тесты внешних API вы еще можете контролировать при наличии подробно описанных контрактов (см. выше ТЗ), то внутренние API пересматриваются постоянно за исключением случая архитектуры "большой комок грязи".

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

Про многоуровневое тестирование софта, думаю, вы в курсе.

часто проще откатиться, доработать промпт и сгенерировать заново (иногда и 10 раз), чем пытаться исправить сложный баг в машинном коде

Перевод: поскольку вместо исправления ошибки в одной строчке авторам "легче" откатиться и перегенировать всё заново, тесты "черных ящиков" тоже придется массивно менять (см. предыдущий пункт). Архитектура "большой комок грязи" рискует стать тотальной при таком подходе. И еще вспоминаю (по-доброму, конечно) коллегу, который пытался устранить утечки памяти в Си++ программе методом смены компилятора.

тяжело ограничить место изменений

Перевод: вместо локальных исправлений потенциально затрагивается вся кодовая база.

Возвращаясь к тестам, как жить, ведь "прозрачный ящик" исчезает? Если еще и тесты генерировать из БЯМ, то остается кропить святой водой сервера перед запуском!

Для Go-проектов и ряда других LLM уже применимы на уровне мидлов

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

Ценность навыка написания кода снижается в пользу навыка чтения чужого кода

Как было сказано выше: "Проще сгенерировать заново". То есть "чужой код" будет меняться чуть ли не ежедневно. Соответственно, ежедневно нужно будет в него "въезжать" по новой. Великолепная перспектива... Утром сажаем картошку, вечером выкапываем.

Как мы теперь нанимаем... Про джунов есть опасения

Перевод: юниоры рассматриваются, как "плохие генераторы кода", а не коллеги и будущая смена -- это приведет к вымиранию команд, описанных в статье в среднесрочной перспективе

И в заключении не могу не процитировать классику

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

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