How a task becomes production
The way I actually work in 2026: every task first passes two filters — can it avoid manual work entirely, and can the writing be sped up — and only then reaches code. Below is the whole chain, step by step.
Precondition — owner or executorThe filter only works when I own my area
Promova rewired how I think: not just being a developer, but validating every task that reaches me. Not "how do I build this" but "what does this do for the business". That filter, though, only works under one condition.
The task goes through the filter immediately. I answer for the outcome, so I have the standing to say "this shouldn't be built at all" or "this shouldn't be built by me".
No filter. There is a task, a deadline, and delivery. Nothing wrong with it — it is simply a different contract.
The difference isn't skill, it's mandate. An independent unit that fully owns its area costs the company less than an executor — because it doesn't build the unnecessary.
Before code
A task arrives
I don't start with "how do I build this". The first question is what this does for the business; the second is whether it has to be built by me, by hand, at all.
Filter one — can this avoid manual work entirely?
Three ways out, and all three answer one question: who does this from now on. If the task takes any of them, it stops being mine and my capacity stays free for work that actually needs a developer.
pipeline exits- Agent-run
Set up once and it never comes back to anyone. From then on an agent runs and completes it entirely on its own, with zero involvement.
Automatic code review · analytics posted straight into a dedicated Slack channel instead of pulling logs by hand
- Requester-run
The task never reaches me. Whoever needs it does it themselves together with AI — my part is to build the path once.
Outreach mailing · influencer platform
- Team-run
A feature or plugin stitched into the system, through which the team makes changes on its own — no ticket, no developer.
CMS redirect plugin owned by the SEO team
Filter two — speeding up the writing itself
The task survived filter one, so it is mine. Next question: is this routine in code terms? If the pattern repeats — button styles, a recurring structure — I write a skill for it first and only then the code. Longer once, faster every time after.
Decision
Plan mode — analysis before a single line
I have to live through this code, not receive it. The plan decides who writes it.
- I don't know this code
- I write it myself.
- I know this code
- The agent writes it.
- Didn't know it, but the plan made it clear
- The agent writes it.
Delivery
Implementation
Whoever the plan picked starts writing — me or the agent.
Checks in dev — the agent
The agent checks, not me: it drives the flow through Playwright or reads errors straight from the Next.js dev server over MCP. None of my capacity goes here.
Checks in build mode — the agent
Dev lies. Different chunks, different optimisations, different behaviour. Something that works in dev and dies in build is a classic, so build gets its own pass — again driven by the agent.
Unit tests + Playwright
Only once it actually works. Unit tests for the logic, Playwright for the flow — written by the agent as well.
Staging — where I step in
The first point I check by hand myself. Locally only when the task is sensitive. Then it goes to QA — in that order, not the other way round.
Pull request
Reviewed by agents carrying the skills that own that zone of the project: a performance change is checked against performance rules, a payments change against payment rules.
Production
Release.
Final check
QA on production. If it holds — done.
- OOP
- SOLID
- DRY
- KISS
- YAGNI
- CI/CD
Knowing the architectural practices and holding the order of steps, code can be written quickly and well at the same time. Speed comes from the sequence, not from typing faster.
Expertise in one specific technology always produces better code — that isn't up for debate. But it doesn't transfer: change the stack and you start over. Understanding of the development flow, of architecture and of principles transfers in full. That is what makes it possible to work in a codebase you don't know yet: plan mode (step 04) shows how this particular project is put together, and judging whether a solution is the right one is something you can already do.