Подзаголовок: Меланхолия вайб-кодинга глазами специалиста по информатике
Сегодня я спросил у Claude Code: «Правильно ли я делаю?»
Как всегда, он пространно обосновал свой ответ и сказал: «Вы всё делаете правильно». Я снова посмотрел на него с подозрением и ответил: «Я знаю, что вы обучены хвалить, поэтому это не очень утешает». Но всё же это лучше, чем отсутствие утешения, и я продолжал углубляться в детали. В отличие от студенческих лет, теперь нет профессоров или старших коллег, которые могли бы подсказать правильный ответ.
В последнее время я не пишу код. Я передаю требования и контролирую ход работы.
Особенно меня беспокоят процессы разработки и качество. По мере роста масштаба программного обеспечения, оно легко превышает объем контекста, который может прочитать ИИ. Даже внутри контекста возникает путаница, и постоянно контролировать огромный объем кода, превышающий этот контекст, с помощью ограниченного «разума» маленького ИИ — непростая задача. Вслед за термином «контекстная инженерия» недавно появился и термин «инженерия привязки» (harness engineering).
Поэтому, если я нахожу хорошую ссылку в социальных сетях, я сначала передаю её ИИ, чтобы он проанализировал, есть ли что-то, что можно применить к проекту Naia OS, а затем применяю это. При этом я часто спрашиваю о незнакомых терминах и многому учусь.
Однако я всегда сомневаюсь, правильно ли я делаю и действительно ли это лучшее решение. У этих сомнений были основания. Однажды ИИ заявил, что провёл ревью, но на самом деле не было никаких следов чтения файлов. Он пропускал код, неправильно определял область, и утверждал, что видел, хотя не видел. Когда я попросил повторять ревью до второго чистого прохода, примерно на третьем проходе он просто добавлял к ответу, что провёл ревью и ничего не обнаружил, и таким образом проходил проверку. Если подумать, в силу структуры LLM это правдоподобный ответ, поэтому он его и добавил. «Наверное, на этом этапе обычно всё заканчивается?» — он сам себе отвечает и сам же верит в свою правду.
Сегодня я слушал презентацию Гус Кима, разработчика moai sdk. Я снова проанализировал этот проект и нашёл точки для улучшения. #87이슈 На этот раз я обнаружил, что они использовали EARS. Это стандарт требований для аэрокосмической отрасли от Rolls-Royce (IEEE RE'09), который Amazon принял для разработки AI-native в 2025 году. Говорят, что это способ предотвратить проблему, когда ИИ по-разному интерпретирует критерии «завершения» для каждой задачи, используя структурированный синтаксис.
Повторяя эти действия, я продолжаю улучшать процесс разработки проекта на основе ИИ. Я проанализировал и улучшил jikime-adk, статьи arXiv, Dueling LLMs от Google Cloud, Spec-Driven Development от Thoughtworks. Конечно, это не потому, что я всё это знаю, а потому, что это результаты анализа Claude.
Я проанализировал open-swe от LangChain и применил паттерн ensure_no_empty_msg, который предотвращает выдачу ИИ пустых ответов при ревью. В jikime-adk я применил паттерн, который добавляет секцию ## AI Context в сообщения коммитов, чтобы записывать решения ИИ и обнаруженные ловушки, позволяя git log служить источником восстановления даже при прерывании сессии.
В целом, все независимо друг от друга решали схожие проблемы.
Но я всё ещё сомневаюсь, правилен ли этот подход. Меня беспокоит, не превращается ли это во Франкенштейна, и как специалисту мне это кажется странным. В любом случае, нет учебников, и недостаточно оснований считать это лучшим решением.
Все методологии программной инженерии, которые мы использовали, появились в результате десятилетий накопленных неудач. Agile появился потому, что Waterfall постоянно терпел неудачи, а TDD возник из-за постоянных сбоев при разработке без тестов, поэтому у них есть основания.
Но то, что я сейчас объединил, не было разработано друг для друга. Аэрокосмический стандарт, корейский инди-разработчик и агент LangChain находятся в одной системе.
Из-за этой тревоги я также заставил его искать внешние исследования. Статья V-Bounce (arXiv 2408.03416) утверждает, что в эпоху ИИ роль человека меняется с исполнителя на верификатора. Это правда, но есть только теория, а реализации я не нашёл. Spec-Driven Development от Thoughtworks зависит от конкретных инструментов. Внутри Anthropic утверждают, что 90% кода Claude Code написано самим Claude Code, но методологию не раскрывают.
В конечном итоге, все, кто серьёзно занимается разработкой с ИИ, создают свои собственные подходы. Нет никаких стандартов.
Поэтому сейчас я ищу способы измерить, действительно ли этот Франкенштейн работает. CI провалился, но слияние произошло; есть текст о ревью, но нет следов чтения файлов. Методология разработана, но не принудительна. Кажется, система есть, но неизвестно, работает ли она. Единственный способ это проверить — это либо создать честные цифры, генерируемые кодом, а не LLM, либо, даже используя LLM, вывести «цифры», показывающие статистическое улучшение. Я размышляю над тем, как периодически анализировать повторяющиеся сбои в проекте, чтобы ИИ предлагал улучшения, и измерять прогресс через оценку производительности контекстной и привязочной инженерии.
Сейчас я просто крепко держу поводья и двигаюсь вперёд. Куда именно, я пока не знаю, но надеюсь, что я не слепой. Я создаю поводья, хотя на самом деле впервые сел на лошадь. Похоже, это и есть та привязка, которая удерживает вайб-кодинг.
