20 лет переводил между заказчиками и программистами. Пару месяцев назад я потерял эту работу.
Что меняется, когда задача из «надо описать» превращается в одну строчку в терминале
Я больше двадцати лет переводил с человеческого на программистский. Не код писал, а вот это всё промежуточное: разговоры с заказчиком, выяснение, что он на самом деле хочет, оформление в техзадание, торг с разработчиками — а это вообще можно за разумное время? а что если без вот этой штуки? а зачем нам кэшировать здесь, если запросов в час тридцать?
Мой типичный рабочий день лет десять подряд выглядел примерно так: 30% — слушать заказчика и переспрашивать, 30% — формализовать в документ так, чтобы не было двух трактовок, 30% — спорить с тимлидом про реалистичность сроков и про то, что «этот компонент уже есть, не надо его переписывать», 10% — просыпаться в три часа ночи от мысли «а если они поняли вон тот пункт по-своему».
Как теперь выглядит мой день
Я открываю терминал, пишу:
/do реализуй функционал - авторизация в клиентском приложении, все необходимые экраны (логин, регистрация, забыли пароль).
И через сорок минут у меня готов pull request: с тестами, с миграцией без даунтайма, с обновлённым README, с открытым GitHub-issue, который ссылается на задачу, и с pass/fail-чеками против критериев приёмки.
Никакого ТЗ. Никакого торга. Никакой передачи подрядчику, который через два дня вернётся с уточняющими вопросами.
Но всё не так просто
Сразу скажу — это не «я попросил Claude и он всё сделал». Я так пробовал, и так оно работает плохо. LLM-агент в режиме «сделай мне X» уверенно генерирует, проверяет сам себя, заявляет что готово — и в трети случаев это галлюцинация: код выглядит правильным, проходит свой собственный самосуд, но на третий день после мерджа выясняется, что в проде что-то едет.
Я потратил время на поиск, что у такого подхода ломается, и пришёл к одной простой штуке — нужно разделить роли. Один агент думает и проверяет. Другой пишет. Третий, попроще, делает мелкие механические штуки. И они не должны меняться местами.
В коде моего скилла это выглядит так:
- Opus (сильная модель) — анализ задачи, планирование, ревью, решение о мердже. Никогда сам не пишет код, кроме редких случаев, когда я явно прошу через флаг.
- Sonnet (средняя) — план уровня «куда какой файл, что меняется», реализация, тесты, самопроверка. Никогда не принимает архитектурных решений.
- Haiku (быстрая и дешёвая) — только тривиальные механические правки. Один-два файла, без логики. Никогда не ревьюит сам себя.
Эти три никогда не путают позиции. Жёсткое правило: если архитектурное решение пришло от Sonnet — отклоняется и переотправляется Opus. Если Haiku пытается тронуть больше двух файлов — стоп.
Почему я не доверяю агентам ревьюить себя
Самая нетривиальная штука, которую я добавил, — это калибровка самооценки.
Когда Sonnet заканчивает реализацию, он обязан — до того как Opus посмотрит на работу — написать отдельный JSON: claimed_status: ready или claimed_status: not_ready, reason: .... Это его внутренняя оценка.
Дальше Opus открывает diff с холодным контекстом — без истории того, что Sonnet думал — и прогоняет жёсткие гейты: тесты прошли? покрытие не упало? зависимости без уязвимостей? pull request не разросся за пределы разумного? миграция без даунтайма? мультиязычность не сломалась? и ещё с десяток таких же.
И вот теперь сравнение: что сказал Sonnet и что сказали гейты. Если Sonnet сказал «ready», а гейт упал — записываем false_positive. Это и есть ключевая метрика. На дистанции она показывает, насколько агент калибруется по мере того, как я докручиваю промпты.
Это не про «ИИ умный/тупой», это про честную обратную связь. Без этого числа я бы догадывался, как работает мой инструмент. С ним — знаю.
Что встроено и почему это важно для меня
Кроме разделения ролей и калибровки, в скилле живут несколько вещей, которые когда-то были моей ручной работой:
- Аудит миграций без даунтайма. DROP COLUMN, RENAME, NOT NULL-без-default — блокируются, скилл предлагает паттерн expand-contract. Раньше я ловил это глазами на ревью.
- Stack detection. Скилл сам разбирается, какой стек (Go / TS / Rust / Python / Ruby / .NET / etc), какие конвенции в репо, что уже было написано. Кэширует это, чтобы не сканировать заново.
- Tracker-агностика. GitHub, GitLab, или произвольные шаблоны команд для Linear/Jira. Issue создаётся автоматически, PR ссылается на него.
- CODEOWNERS-aware ревью. Если в репо настроены ответственные за модули — параллельно поднимается специалист соответствующего профиля для аудита.
- Опциональный CI-gate и auto-merge. По умолчанию — выключено. Включаешь, когда уверен.
Чего я не делаю и что это меняет
Список того, чем я больше не занимаюсь:
- Не пишу ТЗ. Серьёзно — ни в каком виде. Самое подробное, что у меня есть, — это одно предложение в команде /do.
- Не торгуюсь со сроками. Скилл выдаёт оценку «это сложность Medium, ~30 минут» и обычно укладывается.
- Не объясняю существующий код. Скилл сам читает контекст-документ репо и обновляет его после каждой задачи.
- Не разрешаю споры о PR-ревью. Гейты pass/fail, не «оценка от 1 до 10». Либо тесты прошли, либо нет.
- Не пишу changelog. Это часть Phase 4 finalize.
Что освободилось вместо этого: время на то, чтобы думать о продукте. О том, что вообще нужно делать. О приоритетах. О том, что нашему пользователю на самом деле важно.
Главная мысль
Я не верю, что профессия программиста «умрёт». Это слишком сильное и слишком драматичное утверждение. Сложная архитектура, performance-критичные системы, всё что требует deep ownership — там живые инженеры останутся, и надолго.
Но есть вещь поменьше, которую я наблюдаю на собственном примере: ушёл целый класс задач, для которых раньше нужен был отдельный человек-переводчик. Не нужно «формализовать ТЗ». Не нужно «договариваться с подрядчиком». Не нужно «проверять, что все поняли одинаково». Это всё теперь — одна команда в терминале.
И в этом нет никакой потери. Никто из нас, кто этим занимался, не любил эту работу. Все мы хотели делать продукт, а делали бумажку.
Если ты, читая это, думаешь «ну я же не программист, мне это не для меня» — ты, возможно, ошибаешься. Скилл писан для людей, которым не нужно знать, как устроены git-worktree и почему DROP COLUMN без expand-contract ломает прод. Это знает скилл. Тебе нужно знать, что ты хочешь сделать.
Что я выложил
Скилл называется senior-by-default, лежит на GitHub под MIT. v0.2.2, активно разрабатываю, использую сам каждый день. Документация, конфиги для разных стеков, JSON Schema для валидации настроек, плагин-манифест для Claude Code — всё внутри.
Будет интересно услышать обратную связь, особенно от тех, кто пробовал многоагентные флоу и упирался в то же самое — модель уверенно говорит «готово», а потом приходится переписывать.