Эпохе LLM, обзоров от Gartner и вайбкодинга для MVP проектов от кодинг агентов посвящается. Вспомнил несколько случаев из своего опыта.

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

На следующий день я вышел на новое рабочее место. Первые полдня получал доступы к Bamboo, Confluence, Jira и системе контроля версий, где лежал код проекта. Каково же было мое удивление, когда я наконец увидел исходники проекта, который до меня разрабатывали почти год. Мне до сдачи проекта заказчику и найма команды оставалось меньше месяца…

Доделать за бывшей командой

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

Чтобы вы понимали объем задачи: в системе по ТЗ должно было быть три основных объекта, которые сохранялись в базе данных. Каждый такой объект в таблице базы данных и веб интерфейсе имел больше сотни колонок по ТЗ. Для некоторых полей были простые "плоские" справочники с выбором одного значения из нескольких возможных. Каждый справочник можно было редактировать. Иерархические справочники также должны позволять редактирование. При каждом редактировании объект, в котором есть ссылка на прошлую версию справочника, должен был сохранять ссылку именно на ту запись именно той старой версии справочника – что ж поделать, таковы были хотелки заказчика!

Главная заслуга совладельца компании – были куплены лицензии к чудесной версии русского фреймворка быстрой разработки приложений. Изучение по форумам того времени подсказало мне о многих удивительных архитектурных решениях: крудошлепства в нетипизированные коллекции объектов Map<Object, Object> в памяти приложения и прочую дичь.

И когда я получил доступ к системе версионирования SVN с кодом, я там увидел закомиченные мусорные артефакты типа файла проекта IDE и скомпилированных джава классов, а не скрипта сборки типа Gradle/Maven. Еще там лежали какие-то ошметки XML метаданных от закупленного компанией фреймворка Flextera, и в этих метаданных я увидел, что в объектах поликлиник есть только поля "Название" и "ID", а в карточке пациента: "Id", "Фамилия", "Имя", "Отчество" и "Дата рождения".

Их 150 требуемых полей в карточке пациента было только 5 базовых и понятных прошлой команде разработки. Обычных полей для ввода значений без использования справочников.

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

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

Доделать за LLM

Большие языковые модели – безусловно, полезный инструмент в опытных руках, повышающий производительность и расширяющий возможности синьора / тимлида при умелом применении.

Ollama – отличная оффлайн замена для StackOverflow по работе с редко используемыми функциями SQL или фреймворков, которая к тому же может быстро вам объяснить про участки кода, написанного не вами. Интеграции моделей с Open AI тулами / MCP также экономят время, если, конечно, речь не про использование этого в 7b моделях. Пока еще любая доступная LLM это технологии со своими ограничениями по автономности выполняемых задач и по качеству создаваемых решений.

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

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

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

Так обычно масштабировался бизнес, и мне посчастливилось работать на всех этапах и масштабах развития: от стартапов, далее в средних размерах организациях, до работы в энтерпрайзе. Один раз даже пришел лидом в среднего размера компанию "чуть-чуть доделать почти готовый проект" по миграции с OnPrem C# в AWS на Java, где, конечно же, до меня было почти все уже почти готово, собрал новую команду и задержался там на четыре года до превращения среднего размера организации в крупную компанию.

В добрый путь

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

Вишенкой на торте может быть то, что собственники компании вам за расчистку Авгиевых конюшен вряд ли захотят платить сильно больше, чем за подписку Claude Opus 4.1 или за доступ к GPT o3-pro. <sarkazm_on>Ведь LLM уже делают работу лучше программистов.</sarkazm_on>