Skip to main content

Как задача становится продакшеном

Как я работаю на самом деле в 2026-м: каждая задача сначала проходит два фильтра — можно ли не делать её руками вообще и можно ли ускорить написание — и только потом доходит до кода. Ниже вся цепочка, шаг за шагом.

Предпосылка — владелец или исполнительФильтр работает лишь тогда, когда я владелец своей части

Promova капитально изменила моё мышление: не просто быть разработчиком, а валидировать каждую задачу, что до меня доходит. Не «как это сделать», а «чем это поможет бизнесу». Но этот фильтр работает лишь при одном условии.

Я владелец своей части

Задача сразу идёт через фильтр. Я отвечаю за результат, поэтому имею право сказать «этого не надо делать вообще» или «это должен делать не я».

Я исполнитель

Фильтра нет. Есть задача, есть срок, есть выполнение. Это не плохо — это просто другая договорённость.

Разница не в навыках, а в мандате. Независимая единица, которая целиком отвечает за свою часть, обходится компании дешевле исполнителя — потому что не делает лишнего.

До кода

  1. Приходит задача

    Я не начинаю с «как это сделать». Первый вопрос — что это даёт бизнесу. Второй — нужно ли вообще делать это руками и должен ли делать это именно я.

  2. Фильтр первый — можно ли вообще не делать это руками?

    Три выхода, и все три отвечают на один вопрос: кто это делает дальше. Если задача уходит любым из них — она перестаёт быть моей, а капасити остаётся на то, где действительно нужен разработчик.

    выходы из пайплайна
    • Делает агент

      Настраивается один раз и больше не приходит ни к кому. Дальше агент крутит и выполняет её полностью сам, без какого-либо участия.

      Автоматическое ревью кода · аналитика сама падает в отдельный Slack-канал, вместо ручного вытягивания логов

    • Делает заказчик

      Задача не доходит до меня вообще. Тот, кому она нужна, выполняет её сам вместе с AI — моя роль построить этот путь один раз.

      Аутрич-рассылка · платформа инфлюенсеров

    • Делает команда

      Функциональность или плагин в самой системе, через которые команда меняет настройки сама — без тикета и без разработчика.

      Плагин редиректов в CMS во владении SEO-команды

  3. Фильтр второй — ускорение написания кода

    Задача прошла первый фильтр, значит, она моя. Следующий вопрос: рутина ли это в контексте кода? Если паттерн повторяющийся — стили кнопки, типовая структура — сначала пишу под него скил, и только потом код. Один раз дольше, дальше каждый раз быстрее.

Решение

  1. Plan mode — анализ до первой строки

    Я должен прожить этот код, а не получить его. План решает, кто его пишет.

    Код мне незнаком
    Пишу сам.
    Код мне знаком
    Набирает агент, я вычитываю каждый дифф — здесь я знаю, как выглядит правильный код.
    Не знал, но понял из плана
    Теперь знаком. Набирает агент, я сверяю с планом строка за строкой.

Доставка

  1. Выполнение

    Начинает тот, кого определил план — я или агент. В любом случае дальше ничего не идёт, пока я не прочитал дифф.

  2. Проверка в dev — автоматически

    Проверки ведёт агент: гоняет сценарий через Playwright или читает ошибки прямо из dev-сервера Next.js через MCP. Работает без моего присмотра — я читаю, что он вернул, и решаю, что дальше.

  3. Проверка в билд-режиме

    Dev врёт. Другие чанки, другие оптимизации, другое поведение. Штука, что работает в dev и умирает в билде — классика, поэтому билд получает отдельный проход. Так же агентом, и так же результат читаю я.

  4. Юнит-тесты + Playwright

    Только когда оно действительно работает. Юнит-тесты на логику, Playwright на сценарий — черновик пишет агент, дальше вычитываю и правлю я.

  5. Стейдж — мой собственный проход

    Осознанный ручной проход, прежде чем это увидит кто-то ещё. Локально смотрю только тогда, когда задача чувствительная. Дальше отдаю тестировщику — именно в таком порядке, не наоборот.

  6. Pull request

    Проверяют агенты со скилами, отвечающими за ту зону проекта: изменение в оптимизации идёт против правил оптимизации, изменение в платёжке — против правил платёжки.

  7. Прод

    Релиз.

  8. Финальная проверка

    Тестировщик на проде. Если всё ровно — готово.

Основа
  • OOP
  • SOLID
  • DRY
  • KISS
  • YAGNI
  • CI/CD

Зная архитектурные практики и держа последовательность шагов, можно писать быстро и качественно одновременно. Скорость даёт порядок, а не более быстрый набор текста.

Экспертиза в конкретной технологии всегда даёт лучший код — это не обсуждается. Но она не переносится: сменил стек — начал сначала. А понимание флоу разработки, архитектуры и принципов переносится полностью. Именно оно позволяет работать там, где код тебе ещё незнаком: plan mode (шаг 04) показывает, как устроен этот конкретный проект, а оценивать, правильное ли решение, ты умеешь и так.