How I work

Agents write the code. I make the decisions.

I'm convinced that writing code by hand is a thing of the past. Used correctly, AI agents do the job both better and faster. What's left for the engineer is the part that matters most: shaping the idea, setting the direction, and making decisions — continuously, in close collaboration with the agents.

See a real task The workflow: Quarterdeck

Speed and control

Faster is the easy part.

Agents make development faster. They also bring problems that didn't exist before: decisions taken silently, a design that drifts a little with every task, tests that prove nothing, code invented so there is something to show.

I know both sides. My work is keeping the speed agents give without giving up quality or control of the project: every key decision stays mine, and the implementation follows it.

The loop

How a feature gets built

1
Plan
Me + agents

I describe the idea or the plan. Agents break it into tasks and put them on the board, working with the task tracker directly through MCP.
2
Refine
Me + agents

An agent reads every source it can find, then interviews me — one round of questions at a time, each with its recommendation and the alternatives it rejected. I decide. Agents write what was settled into the project's documents — the PRD, ADRs, mockups, rules — and the approved specification into the task.
3
Implement
Agent

A ready task goes to an agent. It writes failing tests first, then the code, runs every check, and stops to ask the moment it needs a decision it isn't allowed to make.
4
Review
Me

I read the pull request description rather than every line: what was built, which decisions the agent made and what it rejected, and diagrams showing how the architecture and the flows changed. Then I merge it myself.
5
Retro
Me + agents

Agents analyse the finished session. Whatever went wrong, or was harder than it should have been, becomes a change to the workflow.

By hand

Almost nothing — on purpose.

All the code is written by agents. Now and then I change a config value or a data file myself; nothing more.

When I don't like a result, I don't fix it by hand. I ask for the fix, and then change the conditions in the workflow so the same problem can't come back. Fixing the code solves one task. Fixing the process solves every task after it.

Example

A real task, start to finish

One task from an product I'm building this way. Three sessions, three different jobs.

1 · Refinement

Before asking anything, the agent read the task and its sources. It found that the task's own description was out of date — a later architecture decision had replaced the model it assumed — and listed the places in the code the change would break. Then it put nine questions to me in one round, each with a recommendation and the options it had rejected. Most of my answers were a word or two. One was a new product idea, so it became an edit to the design document rather than a line in the task. The specification that came out records 13 decisions, an amended ADR, and notes on four neighbouring tasks the change affects.

2 · Implementation

In a separate session, an agent built it from that specification: tests first, committed while still failing, then the code. Every check passed, the mutation score stayed at 100, and the timing-sensitive cases were checked by hand in a browser. The pull request said what the feature now does, listed the decisions the agent made with the alternatives it rejected, and showed one new connection on the architecture diagram — already covered by the ADR amended during refinement.

3 · Retro

One thing in that pull request was a compromise. One of the workflow's own checks couldn't read an import split over two lines, so the agent had to work around it. It didn't touch the check — a guardrail outside its task isn't its to change. It explained the workaround in the pull request instead, and the retro turned it into a task of its own. Refining that task showed the check was also blind in the other direction — the very case it existed to catch — and the decision was to replace it with a stronger tool. The workflow is better for every task after this one.

My part in all three: answering questions, approving decisions and estimating, review the result. Not writing code, and not reviewing it line by line.

Beyond code

Where else agents do the work

Refining ideas

Agents interview me about a task until nothing important is left undecided, and weigh the alternatives for an idea before I commit to one.

The task board

Agents read and update the board through MCP: tasks from a plan, specifications, and notes on the tasks a change affects.

Documentation

What's settled in refinement goes into the project's documents — PRD, ADRs, mockups, rules — drafted by agents, approved by me.

Architecture you can see

Diagrams of the architecture and the flows are regenerated by agents with Archify, and they're what I read first in a review.

Retros

Agents analyse finished sessions and propose changes to the workflow itself, so it gets stricter where it needs to and simpler where it can.

The right tool per job

Midjourney and other task-specific tools, wherever a coding agent isn't the right instrument.

Tools

Mostly Claude Code. Also Codex, Gemini and Devin, and task-specific tools like Midjourney. The workflow connects the agents to the rest of the toolchain — GitHub, the task tracker, deployment.

Claude Code Codex Gemini Devin Midjourney MCP GitHub Archify

For a team

Not just faster output — an understanding of what agents change in a development process, and how to keep their advantages without giving up quality or project management.

The workflow itself: Quarterdeck installs into any repository and adapts to the team's tracker, language and branch rules.
Or the thinking behind it, applied to the processes the team already has.

Contact

Curious how this would work on your project?

Happy to walk through it — what agents do well, where they need guardrails, and what I'd set up first.

panov.eduard.k@gmail.com Quarterdeck