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 показує, як влаштований цей конкретний проєкт, а оцінювати, чи рішення правильне, ти вмієш і так.