Agentic-инженерия по версии бывшего L8 из Meta

Введение

Это перевод и пересказ гостевого поста Kun Chen для ByteByteGo. Kun — бывший L8 principal engineer в Meta, Microsoft и Atlassian, где он руководил разработкой Rovo Dev (AI SDLC продукт Atlassian). Уйдя из большой технологической компании, он перешёл на соло-разработку и построил workflow, в котором основную часть кода пишут агенты. По его словам, то, что раньше было 30+ качественными PR в месяц, теперь — медленный день.

В посте он пошагово разбирает свой сетап на примере реальной фичи в собственном проекте «Hi Bit» — AI-тьюторе для его сына, который учит ребёнка agentic-инженерии. Вся цепочка — от идеи до мёрджа PR для функции вставки изображений в чат.

Терминал-первый подход

Kun начинал кодить почти 30 лет назад и с тех пор строил мышечную память вокруг терминала. Он пробовал разные GUI (Visual Basic, Visual Studio, Atom, Codex app), но возвращался к терминалу по одной причине: руки не отрываются от клавиатуры, и флоу не прерывается.

Эмулятор терминала

Долгие годы он использует WezTerm — единственный терминал, который работает одинаково быстро и настраиваемо на любой ОС, включая Windows. Запускается как одно frameless-окно: без табов, заголовка и статусной строки — буквально ничего лишнего.

Agent-харнессы

Для Anthropic-моделей — Claude Code, для всего остального — OpenCode. CLI-харнессы сейчас commodity: что бы вы ни выбрали, сильно не промахнётесь. Главное — намеренно избегать «фишек», которые привязывают к конкретному вендору. Например, auto-managed memory в большинстве случаев нужен не вам, а вендору, чтобы вы не могли легко переключиться на другую модель. Kun держит весь workflow агент-агностичным, чтобы иметь нулевую стоимость переключения.

Neovim

Neovim остаётся основным редактором: нужен для быстрого просмотра файловой системы, ревью diff и мелких правок. Ключевые плагины:

• oil.nvim — навигация и редактирование ФС как буфер
• neogit — быстрый обзор git-статуса и diff
• snacks.nvim — пикер для поиска файлов и grep

Tmux

Все сессии, окна, табы и панели живут в tmux, а не в эмуляторе. Это даёт сразу четыре вещи:

• разделение окна на панели как удобно
• управление всем терминалом с клавиатуры
• персистентность сессий и их layout
• доступ к одной и той же сессии с других устройств

Стандартный layout — split слева для агента, split справа для Neovim. Разные задачи — в разные табы.

Базовый промптинг

Агент ждёт инструкций. Промпт кажется простым делом, но именно от него зависят и скорость, и качество результата.

Голосовой ввод

Десятилетиями Kun набирал текст руками. Сейчас основной input — голос. Локально на Mac крутится Whisper (turbo v3 large) через OpenSuperWhisper — полностью бесплатно. Говорить быстрее, чем печатать: этот пост тоже написан в основном голосом. Хоткей запускает запись, и голос работает везде, где раньше нужен был ввод.

Делегирование как у менеджера

Самая частая ошибка в работе с агентами — та же, что у новичков-тимлидов: не делегировать правильно. Три типовых провала:

1. Просить действие, а не результат.
2. Не объяснять «почему».
3. Забирать контроль на себя.

Пример плохого промпта: «переименуй эту переменную». Агент закончит за пару секунд и снова ждёт вас — экономии почти нет. Нет и «почему»: вы делаете это ради читаемости, ради конвенции команды, ради будущего плана? Без контекста агенту нечем крыть, и в следующий раз он сделает так же плохо.

Хороший промпт: «давай проведём аудит этой части кодовой базы и убедимся, что именование переменных соответствует нашему соглашению <ссылка на документ>». Есть результат, есть контекст, есть «почему». Агент работает дольше, делает больше, согласуется с вашей целью и применяет соглашение до конца сессии.

Третий провал — забрать контроль. Когда агент ошибается, новички сразу делают сами. Это ловушка масштабирования: в моменте быстрее, но вы снова становитесь bottleneck. Правильный путь — дать обратную связь. С агентами это проще, чем с людьми: можно прямо записать поучение в файл памяти агента (CLAUDE.md или AGENTS.md), либо попросить агента самого проанализировать ошибку и обновить этот файл, чтобы та же ошибка не повторилась.

Планирование сложной работы

Фича, которую сейчас делает Kun в Hi Bit — ввод изображений. Чат должен принимать вставленную картинку из буфера, открывать file picker или камеру. Это сложнее, чем one-shot, и в начале непонятно, куда ставить кнопку и как должны выглядеть прикреплённые изображения.

В таких случаях — новый проект с нуля, большой рефакторинг, крупная фича — он сначала пишет план вместе с агентом.

Альтернативная школа agentic-сообщества говорит «просто разговаривай с агентом». Kun идёт другим путём. Когда вы «просто разговариваете», приходится сидеть в интерактивной сессии, постоянно отвлекаться, через несколько раундов теряется понимание, какой план в итоге. Длинная стена текста в терминале парсится плохо, и дать точечный фидбек почти невозможно.

Вместо этого он тратит концентрированный кусок времени в начале, доводит план до уверенного состояния, а потом отдаёт его в полностью автономную реализацию — до самого финала не вмешиваясь. Это ещё и то, что позволяет запускать другие задачи параллельно без постоянного контекстного переключения.

Долгое время он просил агента писать proposal в markdown-файле, а потом опрашивал и итерировал. Сейчас есть инструмент получше. Под впечатлением от статьи про использование HTML как интерактивных артефактов он собрал Lavish Editor для совместной работы с агентом над чем угодно сложным.

Вместо «draft a technical plan in a markdown file» он говорит «draft a technical plan using npx lavish-axi». Lavish заставляет агента рендерить план как интерактивную HTML-страницу и открывать её в браузере. Инструмент даже побуждает агента матчить look-and-feel проекта: план UI-фичи выглядит визуально консистентно с реальным приложением, и варианты оценивать гораздо проще.

Через несколько минут агент открывает план в браузере. Начинается с цели и контекста, флагаются решения, которые нужно принять, и раскладываются три UI-варианта — меню под «+», всегда видимая тройка кнопок, умная плитка для paste — каждый с плюсами, минусами и собственной рекомендацией агента.

Главный выигрыш — интерактивный back-and-forth. Kun понравился маленький покой Option A, но не понравилось, что меню выпадает вниз и растягивает чат. Вместо абзаца про «тот элемент» он просто кликает на этот элемент в странице и аннотирует прямо: «Can we make it a floating overlay above the + button instead?»

Агент почти моментально возвращает нужную ревизию, и оставшиеся решения Kun финализирует кликами по кнопкам. Возможность так плотно взаимодействовать с планом вместо правки markdown-файла оказалась большим бустом — и не только для планирования. Сейчас он использует Lavish для брейншторма, ревью изменений, data-отчётов и всего, что выигрывает от визуального артефакта и плотного диалога. Game-changer.

Реализация

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

Стоит упомянуть одно: для каждого проекта Kun вкладывается в то, чтобы агент мог сам валидировать свои изменения end-to-end. В Hi Bit в AGENTS.md явно описано, как прогонять приложение, чтобы изменения типа свежей кнопки проверялись агентом до возврата результата. Часто можно наблюдать в реальном времени, как агент сам тестирует свою работу: запускает приложение, прикладывает картинку, проверяет поведение новой кнопки.

Иногда задача настолько большая, что не помещается в одно контекстное окно. Если просто позволить агенту молотить, оно заполнится, отправятся огромные запросы, в какой-то момент сработает compaction и важный контекст потеряется. Новый /goal в Codex и Claude Code помогает немного, но Kun использует кое-что получше задолго до того, как /goal появился.

Он называет это good night, have fun (сокращённо gnhf). Это простой долгоиграющий оркестратор для больших задач на ночь: запускается как gnhf <your objective>.

Под капотом работает похоже на Ralph Loop и Autoresearch: задача разбивается на маленькие шаги, каждый шаг запускается в свежем контекстном окне, в которое посеян общий базовый контекст плюс learnings предыдущих шагов. Неудачные попытки автоматически откатываются, и следующая учитывает провал. Можно задать бюджет токенов, чтобы утром не проснуться банкротом. Возвращаешься — на руках ветка с аккуратными коммитами и notes.md с резюме сделанного.

Kun использует gnhf в трёх случаях:

• Реализация большого плана: gnhf "fully implement this plan..."
• Улучшение измеримой метрики: сокращение LOC, рост test coverage, снижение стартапа или page load: gnhf "improve <metric> while keeping product functionality unchanged"
• Массовые офлайн-эксперименты, когда есть evaluator, способный скорить каждую попытку. В одном проекте он генерил игровую карту, прогнав 50+ layout-экспериментов и скорив каждый через геймплей-симуляцию. Руками это заняло бы недели.

Валидация

Возвращаясь к задаче с изображениями: агент сделал работу, выкатил большой change. Что дальше? Это узкое место для многих — code review. Кода слишком много, читать его не хочется.

Kun всё больше убеждается, что работа с агентами — это роль engineering manager. Большинство менеджеров не ревьюят код напрямую: они заставляют команду ревьюить работу друг друга, а перед мерджем требуют доказательств, что оно реально работает. С AI то же самое: разработчик — менеджер, агенты — команда. Нужно научиться использовать агентов, чтобы те проверяли код агентов, заставлять их само-корректироваться и заставлять их производить артефакты, демонстрирующие, что фича реально работает.

Несколько вещей, которые оказались критичны:

• Запускать reviewer-агента в свежем контекстном окне. Если ревьюить в той же сессии, где писался код, агент предвзят собственным намерением и считает, что так и задумано. Это как просить человека проверить собственную работу: что-то поймает, но гораздо слабее настоящего peer review.
• Эскалировать неоднозначные продуктовые решения человеку. Ревьюеры тоже ошибаются. Если позволить агенту авто-фиксить каждое замечание как валидное, он уйдёт в кроличью нору мимо того, что вам реально нужно. Держать такие решения за человеком — значит держать контроль над неоднозначностью.
• Требовать end-to-end доказательств. Современные frontier-модели сильно опираются на unit-тесты — вероятно, из-за тренинга. Но Kun видел сотни случаев, когда каждый unit-тест зелёный, а продукт всё равно баговый. Нужно заставить агента доказать, что change работает E2E.

Всё это он упаковал в open-source-инструмент no-mistakes, который запускает на изменении с изображениями. Сначала плагин neogit — быстрый скан diff, проверка, что change примерно соответствует запросу. Иногда агент идёт в совершенно неверном направлении — это видно глазом.

Если выглядит разумно, Kun запускает no-mistakes -y, и дальше инструмент делает всё сам: коммит с conventional message в ветку с описательным именем, rebase на свежий main с разрешением конфликтов, спавн агентов для peer-review и авто-коррекции очевидных багов, E2E-тест change с генерацией доказательств, закрытие пробелов в документации, фикс линтинга, push, открытие структурированного PR и бабситтинг CI до зелёного.

Всё автономно, кроме решений, которые инструмент намеренно эскалирует.

Этот validation pipeline стал одним из самых критичных кусков всего workflow. Собственная статистика Kun показывает, что 68% изменений, пропущенных через no-mistakes, содержали баги. Без этого инструмента он не представляет, в каком состоянии была бы кодовая база.

Параллелизация

Когда implement-and-validate pipeline полностью автономный, одна задача может идти долго — и это хорошо, потому что освобождает время для параллельной работы.

Статус агентов

В tmux это означает новое окно. Terminal-табы дают ту же параллельность. Важно держать табы видимыми и показывать статус каждого агента в заголовке. Claude Code и Codex это делают из коробки; для харнессов, которые не умеют, Kun написал маленькие плагины и сделал так, чтобы no-mistakes репортил статус в custom-title.

Эта мелочь и есть то, что позволяет запускать много сессий, не сходя с ума. В любой момент видно, какие агенты бегут, какие закончили, какие ждут ввода. Пара tmux-хоткеев — и вы на нужном табе.

Worktrees

Другая проблема параллельной работы — агенты наступают друг другу на ноги, когда делят одну директорию.

Git worktrees решают это: worktree — эффективный клон того же репо в другой директории, где можно работать параллельно. Но они тащат много когнитивной нагрузки: куда их класть, как называть, создавать новый или переиспользовать, какие заняты, какие с установленными зависимостями, готовы ли env-файлы. Kun хочет думать о работе, а не о том, где её делать.

Поэтому он собрал ещё один open-source-инструмент — treehouse. Вы в репо, хотите запустить параллельную задачу, запускаете treehouse — и попадаете в готовый worktree. Под капотом: пул worktree, трекинг свободных, переиспользование idle (зависимости, build-артефакты и env-файлы уже на месте), синк со свежим main перед drop-in. Kun не думает ни о чём из этого. Запустил treehouse — и работаешь.

Обычно он держит 5–10 задач одновременно. Контекст свитчится мало, потому что большинство задач идёт прямо в чистый PR без его участия. Изредка no-mistakes эскалирует решение, но большую часть времени Kun думает и пишет следующую инструкцию.

Удалённый доступ

Каждые пару недель он отвозит сына на день рождения и оказывается бесполезен пару часов. Ребёнок отлично проводит время с друзьями, а Kun сидит где-нибудь без Wi-Fi, скучает по агентам и гадает, не заблокированы ли они в ожидании его решения.

Это закончилось, когда он настроил remote control. Встроенные remote-фичи Claude Code и Codex он не использует по нескольким причинам:

• Хочется один консистентный workflow для всех агентов, а не отдельные приложения с одним и тем же функционалом, изолированные вендорами.
• Нужен реальный полноценный терминальный доступ — не agent-only view — чтобы запускать treehouse, no-mistakes, gnhf.
• Нужна идеальная непрерывность между phone, laptop, PC. Сын нетерпелив: если сказал «пора», Kun встаёт и идёт. Если он напечатал полфразы на телефоне, должен закончить её позже на PC.

Kun настроил Tailscale — PC, laptop и телефон в одной приватной сети, где они безопасно видят друг друга. Дальше SSH между ними (на Mac это «Remote Login» в System Settings). На телефоне SSH-клиент подключается к Mac, attach к tmux-сессии — и он в том же workspace с теми же табами, агентами, окружением.

Для стабильности соединения используется mosh — transport layer поверх SSH, заточенный под терминальное состояние на ненадёжных сетях, что критично на cellular. Тот же опыт, просто более устойчивый.

Как всё складывается в обычный день

• День начинается с голоса — Kun описывает фичу или запутанный рефакторинг голосом.
• Если задача сложная, агент черновик плана в Lavish Editor, и Kun итерируется в браузере до готовности.
• Когда план готов, либо просит агента реализовать напрямую, либо отдаёт в gnhf для большой задачи, параллельно открывает свежий worktree через treehouse и стартует следующую задачу в параллельном tmux-окне.
• Когда агент финиширует, Kun не читает огромные diff строка за строкой — запускает no-mistakes, который ревьюит код, тестит E2E и открывает чистый PR, пока Kun двигается дальше.
• Когда он не за Mac — SSH с телефона, и весь workspace с ним.

Каждый инструмент убирает одну конкретную точку трения, и вместе они складываются в плавный workflow, который действительно нравится. Kun остаётся на уровне решений «что строить и хорошо ли это», а большая часть промежуточной работы идёт сама.

Заключение

Это всё, что Kun смог припомнить из того, что сделало заметную разницу в его workflow. Оглядываясь назад, его главное наблюдение: модели продолжают прогрессировать, инструменты и workflow вокруг них тоже будут эволюционировать. То, что работает сегодня, через несколько месяцев может устареть.

При этом полагаться только на готовые продукты вроде Claude Code и Codex — никогда не достаточно. Всегда есть место для более эффективного workflow, который выведет агентов на шаг дальше. Kun сильно выиграл от того, что строил кастомные инструменты под собственные точки трения. Вы столкнётесь с другим набором проблем — потому что работаете над другими проектами с другими процессами.

Поэтому он советует не принимать ничего, что вас замедляет. Если часть workflow фрустрирует — скорее всего, другие напарываются на то же самое. Найдите инструмент, который это фиксит, или соберите свой и поделитесь. Мы в середине промышленной революции. Лучшее время, чтобы быть креативным и переопределить, как всё должно работать. Давайте экспериментировать и получать удовольствие.

Оригинал

Оригинальная публикация: An Ex-Meta L8's Agentic Engineering Setup на ByteByteGo, июнь 2026.