Як задача стає продакшеном
Як я працюю насправді у 2026-му: кожна задача спершу проходить два фільтри — чи можна не робити її руками взагалі й чи можна прискорити написання — і лише потім доходить до коду. Нижче весь ланцюг, крок за кроком.
Передумова — власник чи виконавецьФільтр працює лише тоді, коли я власник своєї частини
У Promova мені капітально змінили мислення: не просто бути розробником, а валідувати кожну задачу, що до мене приходить. Не «як це зробити», а «чим це допоможе бізнесу». Але цей фільтр працює лише за однієї умови.
Задача одразу йде через фільтр. Я відповідаю за результат, тому маю право сказати «цього не треба робити взагалі» або «це має робити хтось інший».
Фільтра немає. Є задача, є термін, є виконання. Це не погано — це просто інша домовленість.
Різниця не в навичках, а в мандаті. Незалежна одиниця, яка цілком відповідає за свою частину, коштує компанії дешевше за виконавця — бо не робить зайвого.
До коду
Приходить задача
Не починаю з «як це зробити». Перше питання — чим це допоможе бізнесу. Друге — чи це взагалі треба робити руками і чи маю це робити саме я.
Фільтр перший — чи можна взагалі не робити це руками?
Три виходи, і всі три відповідають на одне питання: хто це робить далі. Якщо задача йде будь-яким із них — вона перестає бути моєю, а капасіті лишається на те, де справді потрібен розробник.
виходи з пайплайну- Робить агент
Налаштовується один раз і більше не приходить ні до кого. Далі агент крутить і виконує її повністю сам, без жодного залучення.
Автоматичне ревʼю коду · аналітика сама падає в окремий Slack-канал, замість витягувати логи руками
- Робить замовник
Задача не доходить до мене взагалі. Той, кому вона потрібна, виконує її разом з AI. Моя роль — побудувати цей шлях один раз.
Аутріч-розсилка · платформа інфлюенсерів
- Робить команда
Функціональність або плагін у самій системі, через які команда змінює налаштування сама — без тікета й без розробника.
Плагін редіректів у CMS, де SEO-команда вписує свої налаштування
Фільтр другий — прискорення написання коду
Задача пройшла перший фільтр, отже, вона моя. Наступне питання: чи це рутина в контексті коду? Якщо патерн повторюваний — стилі кнопки, типова структура — спершу пишу під нього скіл, і лише потім код. Один раз довше, далі щоразу швидше.
Рішення
Plan mode — аналіз до першого рядка
Я маю прожити цей код, а не отримати його. План вирішує, хто його пише.
- Код мені незнайомий
- Пишу сам.
- Код мені знайомий
- Пише агент.
- Не знав, але зрозумів із плану
- Пише агент.
Доставка
Виконання
Починає той, кого визначив план — я або агент.
Перевірка в dev — агент
Перевіряє агент, не я: ганяє сценарій через Playwright або читає помилки просто з dev-сервера Next.js через MCP. Моє капасіті на це не витрачається.
Перевірка в білд-режимі — агент
Dev бреше. Інші чанки, інші оптимізації, інша поведінка. Річ, що працює в dev і вмирає в білді — класика, тому білд отримує окремий прохід. Так само агентом.
Юніт-тести + Playwright
Тільки коли воно справді працює. Юніт-тести на логіку, Playwright на сценарій — теж пише агент.
Стейдж — тут уже я
Перше місце, де перевіряю руками я сам. Локально дивлюсь лише тоді, коли задача чутлива. Далі віддаю тестувальнику — саме в такому порядку, не навпаки.
Pull request
Перевіряють агенти зі скілами, відповідальними за ту зону проєкту: зміна в оптимізації йде проти правил оптимізації, зміна в платіжці — проти правил платіжки.
Прод
Реліз.
Фінальна перевірка
Тестувальник на проді. Якщо все рівно — готово.
- OOP
- SOLID
- DRY
- KISS
- YAGNI
- CI/CD
Знаючи архітектурні практики й тримаючи послідовність кроків, можна писати швидко і якісно одночасно. Швидкість дає порядок, а не швидший набір тексту.
Експертиза в конкретній технології завжди дає кращий код — це не обговорюється. Але вона не переноситься: змінив стек — почав спочатку. А розуміння флоу розробки, архітектури й принципів переноситься повністю. Саме воно дозволяє працювати там, де код тобі ще незнайомий: plan mode із кроку 04 показує, як влаштований цей конкретний проєкт, а оцінювати, чи рішення правильне, ти вмієш і так.