← Назад в блог

Рабочее место не-вайбкодера: как я выстроил harness для AI в PHP-студии

Вайбкодинг — это когда ты описываешь задачу, AI выдаёт код, ты смотришь «вроде работает» и деплоишь. Я так не работаю. Не потому что боюсь AI — Claude Code открыт у меня каждый рабочий день. Просто без структуры в legacy PHP-проекте это не ускорение. Это накопление долга с красивым интерфейсом.

Расскажу, как выглядит моё рабочее место. Не теория — конкретный harness для AI в разработке, с которым я работаю в Bitrix/Next.js-проектах последние полгода.

Почему вайбкодинг не работает в legacy-проекте

Вайбкодинг предполагает, что контекст прозрачен. Ты описываешь задачу, AI видит всё нужное, генерирует рабочий код.

В новом проекте на чистом стеке — возможно. В legacy Bitrix с 28 000 SKU, инфоблоками, composite-кешем и десятью годами бизнес-логики в PHP — нет. AI не знает, что у тебя инфоблок свойства PROPERTY_VENDOR_ID завязан на три микросервиса через очередь. Он не знает, что composite-кеш инвалидируется при определённых полях, а не при любых. Он сгенерирует работающий код — и создаст баг, который появится через две недели при изменении каталога.

Я проходил это. Не катастрофа — но неделя разбора причин и три часа на reverts.

Harness — это не ограничение для AI. Это граница, за которой начинается моя ответственность.

Три зоны делегирования

Я делю задачи на три зоны.

Первая — полный автопилот. Тесты (интеграционные на Bitrix REST API, unit-тесты на бизнес-логику), SQL EXPLAIN анализ, boilerplate code transforms, regex, TypeScript типы по существующему ответу API, documentation strings. Здесь я даю Claude полный контекст и принимаю результат с ревью ровно как pull request от джуна — читаю, понимаю, мержу.

Вторая — обязательное ревью. Новые PHP-функции в Bitrix-контексте, React-компоненты с бизнес-логикой, изменения в существующих API-endpoint'ах, миграции данных. AI пишет черновик — я переписываю критические части. Обычно 60% остаётся как есть, 40% я меняю.

Третья — никогда. Структура инфоблоков (добавление свойств, изменение типов), composite-архитектура страниц, маппинг Elasticsearch-индексов, логика ценообразования и скидок, обработка сессий. Здесь любое предложение AI — это повод задуматься, почему я вообще спросил.

Граница между зонами — не инструмент. Это вопрос: «Если это сломается в субботу ночью, кто будет разбираться?» Если ответ «я один» — это зона 3.

Как это работает: пример с интеграционным тестом

Задача: написать интеграционный тест для Bitrix REST API endpoint'а catalog.product.list с фильтрацией по складу.

Что я даю Claude:

  • Файл с существующими тестами (3 примера того же типа)
  • Описание endpoint'а из внутренней документации (не Bitrix-общей, а нашей с конкретными параметрами)
  • Конкретную задачу: «Напиши тест, который проверяет, что при фильтре WAREHOUSE_ID=5 возвращаются только товары с остатком > 0 на складе 5»

Что я не даю:

  • Общий контекст проекта
  • Схему базы данных
  • Список всех endpoint'ов

Почему? Потому что чем больше контекст, тем больше AI пытается «помочь» с архитектурой. Узкая задача — узкий ответ.

Claude генерирует тест. Я читаю. Исправляю одну деталь — в наших тестах namespace другой. Сохраняю. Прогоняю. Зелено.

Итог: 12 минут вместо 35. Но я прочитал каждую строку.

CLAUDE.md как harness

CLAUDE.md — это файл в корне репозитория, который Claude Code читает при каждой сессии. Это мой основной инструмент контроля.

В нём три блока.

Первый — контекст проекта. Что за проект, стек, версии PHP и Bitrix, ключевые ограничения. «Bitrix composite cache активирован — не предлагай изменения в шаблонах страниц без явного запроса.»

Второй — правила делегирования. Буквально написано: «Не предлагай изменения в структуре инфоблоков без явного запроса. Не предлагай изменения в конфигурации Elasticsearch без ревью схемы.» Claude следует этому — не идеально, но в 90% случаев.

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

CLAUDE.md я обновляю в начале каждого крупного проекта. И — важно — после каждого инцидента, где AI сделал что-то неожиданное.

Полгода с harness: что изменилось

Честные цифры: около 65% кода в последних проектах был AI-assisted. Из них примерно треть я не трогал после ревью. Остальное менял от немного до значительно.

Архитектурных решений, принятых AI, — ноль. Это не значит, что AI не предлагал. Предлагал. Несколько раз я видел, как Claude начинает рекомендовать изменить структуру инфоблока, потому что «так будет эффективнее». Я останавливал на этом месте.

Красные флаги — это когда AI:

  • Предлагает переименовать таблицу или добавить новое свойство инфоблока
  • Начинает объяснять, «почему эта архитектура неоптимальна», не получив такого вопроса
  • Генерирует код, который работает — но ты не понимаешь, почему

Последний пункт самый важный. Если я прочитал код и не понял — это не «умный AI». Это мой долг, который я ещё не осознал.

Что реально изменилось: скорость на рутинных задачах. Тесты, которые раньше откладывались («напишу потом»), теперь пишутся сразу — потому что 12 минут вместо 35 меняют психологию. Это накапливается.

Что не изменилось: время на архитектурные решения. Здесь AI не помогает — помогает опыт, документация, разговор с коллегой.

Harness не делает тебя быстрее везде. Он делает тебя быстрее там, где это безопасно.

Про конкретные правила делегирования AI — что отдавать, что держать при себе — писал подробнее в «Что нельзя давать AI». Про исходную позицию — «Я даю Claude писать тесты. Я не даю ему выбирать архитектуру».