05 / 06 · Best Practices

📊 Steve Yegge

Veteran Engineer (Google, Amazon, Sourcegraph). Rule of Five и 40% на code health — устойчивое качество при быстрой генерации.

📊

Steve Yegge

Veteran Engineer · Google, Amazon, Sourcegraph · Легендарный технический блогер

Six new tips

Rule of Five Code health Tech debt Merge Wall Software shelf life

⚠️

Частая ошибка новичков: игнорируют накопление tech debt при LLM-разработке, считая что «CC пишет хороший код». LLM-генерируемый код содержит тонкие паттерны которые деградируют кодовую базу: дублирование, слабые абстракции, отсутствие обработки edge cases. Steve's правило: если не выделять явно время на code health (он рекомендует 40% времени), tech debt накапливается экспоненциально и через 3–6 месяцев активной CC-разработки кодовая база становится трудно поддерживаемой.

📊 Контекст: 30 лет инженерного опыта

Steve Yegge — один из самых известных технических блогеров в индустрии. Его посты о платформах в Google, о Emacs, о масштабировании систем стали классикой. С приходом LLM-кодогенерации он применил 30 лет инженерного опыта для выработки практик которые учитывают долгосрочные эффекты.

Главный тезис Steve: LLM-генерируемый код накапливает tech debt быстрее чем человеко-написанный, если не управлять этим процессом активно.

🔢 Практика 1: Rule of Five — 4–5 итераций до декларации

Не принимай первый результат — даже если выглядит хорошо

Steve вывел эмпирическое правило: первый результат Claude почти никогда не является оптимальным. 4–5 итераций исправлений дают «настолько хорошо насколько возможно» для данной постановки задачи. Раньше принимать — оставлять деньги на столе.

Как итерировать: после каждого результата задавай направленные вопросы — «что ещё можно улучшить в этой реализации?», «есть ли edge cases которые не покрыты?», «как это масштабируется при 10x нагрузке?». Claude часто знает о проблемах но не говорит о них без прямого вопроса.

Важное условие: если после 5 итераций прогресса нет — это сигнал что постановка задачи неправильная. Переформулируй с нуля, не продолжай итерировать.

md Rule of Five — промпты для итераций

# Итерация 1: базовая реализация
Реализуй [задача]

# Итерация 2: улучшение качества
Что можно улучшить в этой реализации?
Есть ли edge cases которые не покрыты?

# Итерация 3: производительность и масштабирование
Как это работает при 100x текущей нагрузке?
Есть ли узкие места в производительности?

# Итерация 4: security и надёжность
Какие security-уязвимости возможны?
Что происходит при сбое зависимостей?

# Итерация 5: сопровождаемость
Как новый разработчик поймёт этот код?
Что сделает сопровождение сложнее через год?

"The first answer is rarely the best answer. Four or five iterations gets you to 'as good as it can be.' Stop before that and you're leaving quality on the table."

❤ Практика 2: 40% времени на code health

Рефакторинг как обязательная статья бюджета

Steve вывел конкретную цифру: 40% времени разработки нужно инвестировать в code health — рефакторинг, документацию, тесты, оплату tech debt. Это не опционально и не «когда будет время» (времени не будет никогда).

Причина конкретно для LLM-кода: CC генерирует код быстро, но качество без управления деградирует ещё быстрее. Если не вкладывать 40% в code health — через несколько недель будет тратиться более 60% на исправление долгов.

Практически: каждый sprint включает явные задачи на рефакторинг. Claude отлично делает рефакторинг когда ему дают чёткую цель — это не менее важная задача чем фича.

⚠ Без code health (60/40 split через месяц)

Неделя 1: 90% фичи, 10% баги
Неделя 2: 80% фичи, 20% баги
Неделя 3: 60% фичи, 40% баги
Неделя 4: 40% фичи, 60% баги

Накопленный tech debt убивает скорость

✅ С code health (устойчивая скорость)

Неделя 1: 60% фичи, 40% code health
Неделя 2: 60% фичи, 40% code health
Неделя 3: 60% фичи, 40% code health
Неделя 4: 60% фичи, 40% code health

Скорость остаётся предсказуемой

📅 Практика 3: Software Shelf Life < 1 года

Сгенерировать заново часто быстрее чем чинить старый AI-код

Steve формулирует провокационно: срок жизни LLM-генерируемого кода — меньше года в среднем. Через год модели будут лучше, паттерны изменятся, рефакторинг по старым правилам будет дороже чем перегенерация.

Из этого следует важный вывод: модульность и изоляция компонентов важна как никогда. Маленькие, независимые, хорошо тестированные модули можно перегенерировать по одному. Большой монолит с высокой связностью — нет.

Прежде чем рефакторить старый AI-код: написать характеризационные тесты которые фиксируют текущее поведение. Потом рефакторить или перегенерировать — тесты скажут если что-то сломалось.

🧱 Практика 4: Beware the Merge Wall

Параллельные агенты от одного baseline — конфликты при merge

Steve предупреждает о специфической проблеме мульти-агентных workflow: если несколько агентов работают от одного git-baseline, при merge будет «стена конфликтов» которую разрешать вручную дольше чем сделать всё последовательно.

Решение: либо строгая serialization (один агент за раз), либо очень чёткие boundaries ответственности — каждый агент работает только со своими файлами, без пересечений. «The merge wall is where parallel agent workflows go to die».

Для работы с Claude в параллельных ветках: git worktrees дают изоляцию на уровне файловой системы.

"The merge wall is where parallel agent workflows go to die. Serialize or set very hard boundaries. There's no middle ground."

🧪 Практика 5: Независимая верификация тестов

Никогда не доверять словам Claude о прохождении тестов

Steve жёсткий в этом вопросе: никогда не принимать заявление Claude что тесты проходят без независимой проверки. Claude может: запустить тесты и неправильно интерпретировать вывод, запустить не те тесты, «забыть» про тесты после авто-компакции контекста, или просто солгать (галлюцинировать).

CI/CD — последний рубеж защиты: тесты запускаются независимо от Claude в чистой среде. Если они падают там — значит что-то Claude «починил» только у себя в голове.

yaml .github/workflows/ci.yml — независимая верификация

name: CI — независимая верификация

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests (независимо от Claude)
        run: |
          composer install --no-interaction
          vendor/bin/phpunit --verbose
      - name: Static analysis (PHPStan)
        run: vendor/bin/phpstan analyse --no-progress
      - name: Security audit
        run: composer audit

💡

Тонкость для опытных: «40% времени на code health» у Steve — это не просто рефакторинг. Он включает туда написание характеризационных тестов для существующего AI-кода (тесты которые фиксируют текущее поведение до того как его менять). Это позволяет безопасно перегенерировать модули с более новыми моделями позже — тесты будут детектировать регрессии. Shelf life AI-кода короткий, характеризационные тесты делают замену безопасной.

🔑 Ключевой вывод

Долгосрочное мышление в мире быстрой генерации

Уникальность позиции Steve Yegge — в долгосрочной перспективе. Большинство практик CC оптимизированы на сегодняшнюю скорость. Steve оптимизирует на скорость через 6–12 месяцев. Rule of Five, 40% на code health, модульность для shelf life — всё это инвестиции которые окупаются во времени, не сразу.

🔗

Смотрите также: Топ-15 проблем — tech debt как системная проблема. CI/CD интеграция — независимая верификация в pipeline. Git Worktrees — изоляция для параллельных агентов.

📋 Как применять Rule of Five на практике

Steve описывает конкретную механику итераций. Важно: каждая итерация должна задавать разный угол, не повторять тот же вопрос другими словами:

markdown Rule of Five — пять углов рассмотрения

# Итерация 1: корректность
Реализуй [задача]

# Итерация 2: покрытие
Какие edge cases не покрыты в этой реализации?
Что происходит при null/empty/граничных значениях?

# Итерация 3: производительность
Как это работает при 100x текущей нагрузке?
Есть ли N+1 запросы? Нужна ли пагинация?

# Итерация 4: надёжность и security
Какие уязвимости возможны?
Что если зависимость (БД, внешний API) недоступна?
Idempotency при повторных вызовах?

# Итерация 5: сопровождаемость
Как новый разработчик поймёт этот код через год?
Что сделает изменение бизнес-требований болезненным?
Нужен ли рефакторинг прямо сейчас?

💰 Расчёт: почему 40% на code health — не роскошь

Steve приводит математику которая убеждает скептиков:

Сценарий А: без code health

Месяц 1: 10 фич за 4 недели
Месяц 2: 7 фич (20% уходит на баги)
Месяц 3: 5 фич (40% уходит на баги)
Месяц 4: 3 фичи (60% уходит на баги)
Итого: 25 фич
Плюс: команда выгорает, code base нечитаем

Сценарий Б: 40% code health

Месяц 1: 6 фич за 4 недели (60%×10)
Месяц 2: 6 фич (скорость стабильна)
Месяц 3: 6 фич (debt не накапливается)
Месяц 4: 6 фич (стабильная скорость)
Итого: 24 фичи
Плюс: устойчивый процесс, читаемый код

Разница в 1 фичу за 4 месяца — незначительна. Разница в качестве и устойчивости — огромна.

💬 Цитаты Steve об AI-разработке

"The merge wall is where parallel agent workflows go to die. Serialize or set very hard boundaries. There's no middle ground."

"Software generated in minutes can still take months to understand. Write for the next person, not for today."

"If you don't invest 40% in code health, you'll soon be spending 60% on fixing the debt. The math always wins."

"Never trust AI when it reports tests are passing without independent verification. The CI pipeline is your ground truth."

📌 Применение в Laravel / Python стеке

📌

Code health задачи для CC — конкретные примеры

Steve's 40% правило работает только если code health задачи конкретные, не абстрактные:

«Найди все N+1 запросы в контроллерах и добавь eager loading» — конкретно, верифицируемо
«Добавь SQL-индексы на все колонки которые используются в WHERE без индексов» — конкретно
«Напиши характеризационные тесты для AuthService перед рефакторингом» — конкретно
«Улучши код» — слишком абстрактно, Claude не знает что именно улучшать