# Я оркестрирую coding-агентов, а не печатаю код

Короткая заметка о том, что меняется, когда слой реализации — это агент. Что остаётся прежним, что исчезает и где появляется новое узкое место.

- **Author:** Фёдор Чищин
- **Published:** 2026-05-15
- **Updated:** 2026-10-16
- **Tags:** agents, methodology, ai-native
- **Source:** https://fedorthinks.com/ru/blog/directing-not-typing

---

Я больше не пишу код. Я оркестрирую coding-агентов — сейчас это Claude
Code на Opus — и отвечаю за архитектуру, спецификацию и ревью. Вот что
изменилось.

## Что исчезло

**Нажатия клавиш.** Раньше день senior-инженера был 30% чтения кода,
20% написания кода, 50% всего остального. Линия «написание» падает
до примерно 5% — ручные патчи для того, до чего агент пока не дотягивается,
или для изменений слишком маленьких, чтобы тратить промпт.

**Усталость от boilerplate.** Новый endpoint с auth, валидацией, тестами
и миграцией был раньше двухчасовой задачей. Сейчас это пятиминутный
промпт и десятиминутное ревью. Мысль «надо написать тест на этот edge
case» исчезает — конечно, тест есть, агент его написал.

**IDE.** Больше половины времени я в инструменте, похожем на терминал. IDE
появляется, когда нужно прочитать что-то, о чём агент рассуждал, но не
показал, или когда я ревьюю diff перед merge. В остальном цикл: промпт
→ diff → коммент → следующий.

## Что осталось ровно таким же

**Архитектура.** Что должно быть построено, где границы, какая модель
данных, какие failure modes. Ничего из этого не делегируется. Coding-
агент с удовольствием построит всё, что ты опишешь. Вся работа — в
описании правильной вещи.

**Проверка.** Я не читаю каждую строку, которую пишет агент, — это не
масштабируется, и ошибки ловятся не там. Я доказываю, что код работает:
unit-, интеграционные и end-to-end тесты, которые агент обязан держать
зелёными, строгие проверки (типы, линтер, покрытие) на каждом коммите,
логи и трейсы в продакшене. Агент быстрый, но не безошибочный — он
пропускает ассерты, переусложняет control flow, иногда придумывает
вызовы API. Тесты и проверки ловят это каждый раз и не устают.

**Production-суждение.** Интуиция, что конкретная абстракция протечёт,
что конкретный индекс пропадёт, что конкретная async-граница уйдёт в
deadlock под нагрузкой — ничего из этого нет в обучающих данных любого
агента. Это в двадцати годах починки.

## Куда сместилось узкое место

Новое узкое место — **качество спецификации**. Если я пишу промпт
неоднозначно про error path, агент выбирает одну интерпретацию
и реализует её. Если пишу полно, но неверно расставляю приоритеты, агент
правильно делает не то. Снаружи оба случая выглядят как сбои агента; оба —
сбои спецификации.

Дисциплина которая раньше шла в «написать правильный код» теперь идёт
в «написать правильную спецификацию и доказать, что код правильный». Произведение
_потраченного времени_ на _плотность мысли_ примерно сохраняется —
просто сдвигается раньше по пайплайну.

Мне работа интереснее. Я читаю больше, пишу больше прозы, переписываю
один и тот же параграф три раза перед отправкой агенту, и заканчиваю
день, выпустив примерно в пять раз больше, чем два года назад. Размен
хороший.