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) показывает, как устроен этот конкретный проект, а оценивать, правильное ли решение, ты умеешь и так.