Эпохе 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 4 Opus или за доступ к GPT o3-pro. Ведь LLM уже делают работу лучше программистов.
Автор: igor_suhorukov
