Comments 24
Одна из крупнейших проблем вайбкодинга - у программиста в голове не появляется схемы работы продукта.
Вайбромист занят созданием обёртки для LLM
Это большая проблема. Но хуже, когда ты пишешь продуманный код, а другой через агентов вайбкодит и полностью меняет твой код под свою задумку, и этот код не читаемый.
У меня так на днях было, сделал развертывание архитектуры в докерах. Все прозрачно, продумано, читаемо. Другой решил сделать более универсально через GitLab сборку. Скормил агентам, те переписали, работает. Но я открыл, что ему сетка сделала и у меня глаз потек. Совершенно не читаемо, вся прозрачность улетучилась, в коде появились жёсткие пути типа ../python/3.11.5/.. и прочее. И при этом человек топит за "понятный и прозрачный код" и одновременно допускает такой дикий "вайбкодинг". Разница в том, что за прозрачный код он топит там, где силен в разработке, а не читаемый вайбкодинг ему нормально в той области где он вероятно не силен.
Поэтому я подозреваю, что за полный вайбкодинг без полного код ревью топят те, кто не понимает, что им написала сетка или не планируют потом это поддерживать (я написал, а вы сами разберитесь и поддерживайте это легаси).
Я с этим пытаюсь бороться, разделяя кодовую базу фронтенд-приложения на рукописное ядро, которое запрещено трогать агентами, и UI-экраны, которые верстает AI. Но всё равно слабо помогает, особенно, если работаешь над приложением не один. AI пишет файлы на сотни строк с кучей условий, хуков, функций, а у меня 0 понимания, что там вообще происходит. В голове просто нет карты кода, абстракций, их взаимодействия.
Вы, по-моему, ближе всех к решению. Дело именно в том, что нужен другой уровень контроля — не построчный и не «запретить агентам трогать файлы», а уровнем выше, над архитектурой и абстракциями. Направление правильное; весь вопрос в том, каким инструментом этот уровень держать, и это уже отдельная большая тема.
Тут, по-моему, важный поворот: код-ревью здесь — не решение. Сам по себе полный код-ревью — операция когнитивно тяжёлая, и в полном объёме она практически сводит на нет выигрыш от агентов. К тому же откровенный мусор современная топовая LLM уже не напишет — на уровне строк всё чаще выглядит прилично.
Проблема глубже. Архитектурные решения приняты ещё на этапе генерации — и проверять надо не код, а получившуюся архитектуру. А как вы её оцените, если она для вас непостижима в силу тех самых человеческих ограничений? Замкнутый круг: чтобы пройти ревью, архитектуру надо удержать в голове — а именно это и не выходит.
Пути решения есть, но они не в код-ревью, а в том, чтобы иначе строить сам контроль над архитектурой. Над этим, собственно, и думаю — это тема продолжения.
Статья в общем не про то что код нечитаем, а про то что структура кода нечитаема. Каждая отдельная функция идеальны, а вот их сочетание уже нет.
Проблема не в LLM, а в automation bias на ревью: сгенерированный код смотрят менее критично. Плюс модель не знает локальных конвенций команды и архитектурного контекста. У нас AI-код проходит те же тесты и линтеры, что и ручной — это снимает половину вопросов.
это фундаментальная ошибка строить то не знаю чего .... самый главный вопрос а кто для человека ИИ ? если принять что ИИ — зеркало, отражение личности пользователя, пассивный инструмент расширения памяти тогда будет одна пуст и сложная но рабочая комбинация
Датасет личности (теги, веса, отказы)
Локальный инспектор правил (детерминированный, не LLM)
Двухслойная комбинация агентов:
Личный секретарь (заточен на твоём датасете, переводит поток в задания)
Агенты-исполнители (решают конкретные задачи, не имея доступа к личности)
а если нужен друг детства то это другая архитектура ... коуч или кодер третья ...я провел замеры причем самые суровые на самом деле когда работаешь над проектом от идеи до конечного результата то доля человека составляет 70-80 % а ИИ набирает лишь на коде на систематизации данных и т д ... вот этот показатель меня реально поразил и я полностью пересмотрел архитектуру работы с агентами .
Важный момент: зачастую программист и сам не видит готового решения — оно рождается итерациями, в процессе написания кода и рефакторинга. С агентами этого цикла нет. И тогда человек вынужден ставить задачу, инвариантную по решениям, причём инвариантность глубоко вложенная — а так задачу почти невозможно сформулировать заранее. Как только агент сам принимает решения по всему дереву вопросов, контроль теряется мгновенно. Поэтому ваш вывод про пересмотр архитектуры работы с агентами мне близок — замеры это только подсвечивают.
Но всё же тезис про у LLM нет памяти слишком сильный. Контекст это тоже форма рабочей памяти, просто ограниченная по времени
Справедливое уточнение, но я бы развёл два уровня. У голой модели памяти в прямом смысле нет: веса на инференсе не меняются, а контекст — это вход, подаваемый заново на каждом проходе, а не то, что модель в себе хранит. Память появляется уровнем выше — в харнесе (обвязке вокруг модели: retrieval, состояние, внешние хранилища). Понятие харнеса сейчас как раз набирает популярность, и именно там эта память так или иначе реализуется. Я, к слову, и работаю над этой асимметрией со стороны харнеса.
Фундаментальная проблема не понимать, что можно и нужно строить через подробные спецификации, прекрасно понимая, что именно и как получается. СПЕЦИФИКАЦИИ, а не код. Вот это новая реальность.
Детальная спецификация частично решает проблему — но, по-моему, только для проекта среднего размера и только пока вы его не начали развивать. Несколько практических оговорок. Если у вас уже есть готовое решение или его часть, проще сказать агенту изучить нужный кусок и сделать так же, но «без крыльев», чем писать спеку. Само написание спецификации по трудоёмкости сопоставимо с написанием кода — и заранее её часто не напишешь: многие проблемы и решения становятся видны только в процессе. А при развитии проекта придётся постоянно держать спецификацию и код в соответствии — и это отдельная боль. Плюс спецификация и код вместе уже не влезают в контекст, и начинается фрагментарная работа. Так что как направление — да, но «спецификации вместо кода» проблему не закрывают, а во многом переносят её на стык спеки и кода.
Что значит проще? Какая разница, в какой текст ЛЛМу перегонять существующий код, в другой код или в тескт, его описывающий (md+тесты) и потом уже на их базе перегонять на другую платформу? Именно так легаси и переписываются и абсолютно успешно, сейчас каждая вторая команда с ЛЛМами этим занимается. А с нуля разработка ЛЮБОГО проекта ведется именно итеративно и через спецификации. Это база, позволяющая достигать результата, иначе будет именно вот так, как принято тут рассуждать об ЛЛМках.
Запомним формулу: у человека — узкие, многочисленные акты мышления с накоплением.
Это очень ограниченнное представление. Вряд ли на него можно ориентироваться. Самые сложные задачи не требуют логического накопления, требуют выявления и понимания систематизации данных, классический пример - таблица Менделеева. И решение приходит, обычно, когда мы отвлекаемся от, собственно, решения задачи, то есть убираем фокус с задачи, например спать ложимся. Я сам многократно это замечал, решение приходит когда ты почти отчаялся его найти и переключился на бытовые проблемы, например, это кстати, очень популярный штамп в разных детективах, но это именно так работает для сложных задач.
Вывод какой? Любое напряженное размышление-анализ-поиск решения/системы запускают как бы фоновый процесс в мозгу. Пока этот процесс в фокусе, а человек в напряжении, этот процесс идет как по контролируемым рельсам, по кругу и не приносит решения. Когда мы убираем с него фокус мозг не отключает этот процесс, он как бы уходит в фон, но без контроля и напряжения он начинает флуктуировать и в один прекрасный момент вы обнаруживаете решение, которое выпало с очередной флуктуацией. Иногда даже можно различить какая аналогия из повседневной жизни вызвала флуктуацию фонового процесса анализа и подтолкнула вас к решению.
Это как раз то, что вижу с Claude Code в продакшене. Агент без ограничений стягивает зависимости из 15-20 файлов в одну функцию: технически работает, но человеку потом надо держать в голове весь этот граф, чтобы что-то изменить. Вышел из ситуации через CLAUDE.md: явные границы модулей, правило не больше 3 зависимостей в методе, запрет на импорт через 2 уровня. Когда добавил эти ограничения, читаемость выросла, а агент не потерял скорость. Ограничение контекста как компенсация когнитивной асимметрии.
зачем человеку руками что-то менять в этом коде? почему к работе с клодом относятся как к чему-то одноразовому? из-за одноразовых аккаунтов под санкциями? ЛЛМы никуда не уйдут уже, это новая реальность. И тот же клод на раз проводит рефакторинг созранных самим же простыней, когда в свежей сессии видит контектс, что получилось. Ровно так же, как делает рефакторинг человек. Редкий проект с нуля пишется сразу в финальной структуре.
Тут не про одноразовость, агент правда отлично рефакторит свои же простыни в свежей сессии, согласен. Но дешевле это когда у кода есть границы. Функция с 20 зависимостями дорого рефакторится и человеком, и агентом, в контекст надо затащить пол проекта чтобы ничего не сломать. Ограничения ставлю не чтобы защитить человека от агента, а чтобы каждая следующая правка, в том числе агентом, стоила меньше контекста.
,
Спасибо за статью! Читал с огромным удовольствием — одна из редких вещей в последнее время. Поднимаемые проблемы моделей стали заметны и мне самому, так что жду продолжения про инструменты.
Интересно, на каком шаге модель захочет убивать человеков, получив промпт “переписывай до тех пор, пока не станет идеально”?
LLM написала, человек одобрил, никто не понял: откуда на самом деле берётся нечитаемый код