50 функций Claude рухнули. Вот почему.

Разработчик Шив Бхосале (Shiv Bhosale) приступил к амбициозному семимесячному проекту по созданию K10s, GPU-aware Kubernetes dashboard, полностью с помощью Claude. Эти интенсивные усилия по "vibe coding" привели к созданию 50 различных features, каждая из которых, казалось, чисто вписывалась в одну сессию разработки. Быстрая генерация отдельных компонентов создавала опьяняющее чувство прогресса, предвещая будущее, где сложные приложения могли бы материализоваться с беспрецедентной скоростью.

Этот подход культивировал соблазнительную привлекательность 10x velocity, когда разработчики чувствовали себя вправе создавать прототипы и внедрять новые возможности с удивительной легкостью. Эффективный, основанный на сессиях вывод Claude укреплял представление о том, что каждая feature была самостоятельным успехом, требующим минимальных усилий по интеграции. Это создавало ложное ощущение архитектурной надежности, маскируя основные проблемы за счет чистой скорости генерации.

Однако иллюзия катастрофически разрушилась, когда Бхосале наконец попытался объединить 50 features в единое приложение. Вся система рухнула, выявив фундаментальные архитектурные несоответствия: переключение представлений отображало устаревшие данные, ранее заполненные таблицы необъяснимо оказывались пустыми, а критически важные ключевые функции выполняли три разных, непредсказуемых действия в зависимости от активного экрана. Этот полный сбой, вызванный отсутствием архитектурного предвидения со стороны AI, вынудил Бхосале отказаться от семи месяцев работы, архивировать всю кодовую базу и перезапустить проект с нуля.

Фундаментальный недостаток AI быстро проявился: он превосходно генерирует изолированные features, а не целостные архитектуры. Каждый prompt функционирует как изолированная директива, совершенно не подозревая о 49 других features, совместно использующих state в проекте K10s Шива Бхосале. Claude поставлял отдельные компоненты, но, что критически важно, ему не хватало понимания того, как эти части должны взаимодействовать как единая система.

Этот фрагментированный подход неизбежно привел к хрупкой, трудноподдерживаемой codebase. Когда Бхосале попытался использовать все вместе, вся структура рухнула. Переключение views показывало stale data, ранее заполненные tables оказывались пустыми, а одна клавиша выполняла три разных действия в зависимости от экрана. Отдельные features, чистые в изоляции, просто не работали вместе.

Решение Бхосале было ясным: разработчик должен вернуть себе роль architect. Он вручную спроектировал архитектуру системы, тщательно задокументировав ее в файле `Claude MD`. Только после этого он использовал Claude для «скучных задач» — реализации конкретных функциональностей строго в рамках заранее определенного, написанного вручную структурного blueprint. Этот сдвиг превратил AI из автономного строителя в мощный, управляемый implementation tool.

Подход AI по умолчанию — это антипаттерн god object, заключающийся в запихивании всей logic в единую, массивную data structure, чтобы найти кратчайший path к working feature. Кодовая база K10s Шива Бхосале ярко продемонстрировала это, содержав единый struct, занимающий поразительные 1690 lines. Этот монолитный object содержал 500-строковый `Update()` method и 110 switch cases, что является явным свидетельством его неуправляемого scope.

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

Исправление этого требует четких инструкций для LLM. Разработчики должны заставить Claude разделять задачи, разбивая логику на отдельные представления, компоненты и структуры данных. Это архитектурное руководство активно предотвращает использование AI монолитных структур по умолчанию, способствуя созданию более модульной и поддерживаемой кодовой базы. Для получения дополнительной информации о проекте Бхосале и его эволюции изучите репозиторий K10s на GitHub: shvbsle (Shiv Bhosale) / k10s - GitHub.

Воспринимаемая «бесплатность» кода, сгенерированного AI, оказывается опасно обманчивой, что напрямую приводит к безудержному разрастанию объема работ. Когда Claude, казалось бы, может создать 50 функций за столько же изолированных сессий, импульс постоянно добавлять новые становится непреодолимым. Эта высокая скорость, хотя поначалу и воодушевляет, маскирует растущий технический долг и заманивает разработчиков во все расширяющийся проект.

Каждая новая функция, независимо от того, насколько тривиально ее создание, влечет за собой значительные скрытые затраты: - долгосрочная поддержка - всесторонняя документация - обработка непредвиденных граничных случаев - увеличение когнитивной нагрузки пользователя Проект K10s Бхосале, с его 50 свернутыми функциями, ярко иллюстрирует эту ловушку; обман скорости маскировал истинное бремя неархитектурного разрастания.

Чтобы бороться с этим коварным расширением, разработчики должны установить жесткие границы. Shiv Bhosale явно определил, для кого он *не* строит, установив отрицательные ограничения. Затем он кодифицировал эти явные ограничения объема работ непосредственно в файле контекста `Claude MD`, не позволяя AI перестраивать существующие функции или выходить за рамки проекта. Это проактивное ограничение гарантирует, что скорость AI служит точно определенной цели, а не создает неуправляемое разрастание функций.

Что такое «vibe coding» с AI?

Это стиль быстрой разработки, при котором программист использует LLM, такой как Claude, для генерации функций на основе высокоуровневых подсказок или «vibes», часто без строгого, заранее определенного архитектурного плана.

Почему AI создает «god objects»?

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

Как разработчики могут избежать ловушек AI-кодирования?

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

Кто такой Shiv Bhosale и что такое K10s?

Shiv Bhosale — разработчик, поделившийся этим опытом. K10s — это его проект, GPU-aware Kubernetes dashboard, который он успешно перестроил после того, как первоначальная версия, сгенерированная AI, потерпела неудачу из-за архитектурных проблем.