BUILDING WITH AGENTS

Set up the structure once, and trust what they ship without watching every step.

Romain Pattyn • Codika

A quick show of hands

Some questions for you.

01Who already used a coding agent? (Claude Code, Codex, Gemini, Cursor)
02Who uses one every day?
03Who feels they’re still micromanaging it?
04Who has let it run on its own all night, spawning sub-agents?
WHAT THIS TALK IS ABOUT

A Methodology, not a Demo.

A repeatable way to run coding agents on their own, and trust what they ship.

Five major takeaways.
THE CASE STUDY

Let’s replicate Calendly.

We rebuilt it internally: the same premium features, plus more, and we own 100% of the code.

0
Agents
-
Runtime
-
Tokens
-
Spared
THE METHODOLOGY

Five building blocks.

Each one is a requirement, and the takeaway that solves it.

01You agree on exactly what to build  a shared, readable plan
02No human is needed mid-run  front-load every manual step
03Context never overflows  an orchestrator + sub-agents
04The test loop closes itself  a companion CLI
05You can trust the output  independent QA agents
REQUIREMENT 1
You have to agree on exactly what to build.

The agent builds what you give it, not what's in your head. The hard part is making sure the spec really is what you want, and that you and the agent read it the same way. Get this wrong and you can't blame the agent.

TAKEAWAY 1
Write the plan as HTML.

Plain plan mode is too thin. Have the agent write a real HTML plan you can see: the data model, the UML, the mermaid flowcharts, and a live roadmap, all in one page.

DON'T FEAR THE CONTEXT

Iterate deeply on the plan.

People avoid changing small plan details to "save context." That's backwards. Go into every detail. Planning rounds are the cheapest, highest-leverage tokens you'll ever spend. A wrong decision here costs you a whole phase later.

The plan is where mistakes are free. Spend tokens here, not in the rebuild.
REQUIREMENT 2
Once it starts, it can't wait on you.

An overnight run dies the moment it needs a human. Nothing during implementation or testing can require you, so every manual step has to be handled before launch.

TAKEAWAY 2
Front-load every human step.

Accounts, OAuth, CLI logins, secrets, all set up before you start, so nothing blocks the agents mid-flight. Plus a stop rule for the rare real blocker: it stops and asks, it never guesses.

REQUIREMENT 3
No agent can hold a whole product in its head.

A build this size runs to millions of tokens, far past any context window. And you never want to compact the conversation, because that quietly drops information you needed.

TAKEAWAY 3
One fresh sub-agent per phase.

Fragment the build into phases. An orchestrator spawns a zero-context sub-agent for each one, auto-merges its PR, and logs the results back into the plan. 38 phases shipped this way across three versions.

DELEGATE AND TRACK

One orchestrator, many sub-agents.

The orchestrator never writes code itself. It hands each phase to a fresh sub-agent, follows its progress, and records the outcome, its PR, runtime, tokens, and any deviations, in a roadmap it owns. It delegates and tracks; the sub-agents do the building.

01
Pick the
next phase
02
Delegate to a
fresh sub-agent
03
Track its PR,
time, tokens
04
Record the result,
move on
REQUIREMENT 4
Writing the code is not enough.

To run unattended, the system has to implement, deploy, test, and fix itself from the test results. The whole loop has to close with no one in it.

TAKEAWAY 4
Build a companion CLI around your API.

Two wins. First, true end-to-end tests: a test becomes a real booking through the real API, not a mock. Second, it makes the product 100% agent-native, any agent can install the CLI and drive the tool itself.

The agent closes the loop on its own
drives simulates real usage writes the real change reads it to verify Agent the QA brain CLI — acts like a user Product (app + API) SOURCE OF TRUTH Database Google Calendar Function logs self-improving E2E loop
Click to enlarge
A PLANNING TRICK

Design the E2E tests at planning time.

Ask the agent to design the CLI-driven end-to-end flow during planning. Projecting itself actually using the tool surfaces edge cases (concurrency races, timezones, buffers) that enrich the plan before any code exists.

Make the agent imagine using the product. The edge cases write themselves.
REQUIREMENT 5
It can't grade its own homework.

The agent that wrote the code can't be the one that signs it off, it's biased toward its own work. The review has to come from a different agent that never saw the implementation.

TAKEAWAY 5
Verify with an independent agent.

A fresh QA agent caught a real serverless bug: a fire-and-forget call that never fired on Vercel. 12/12 end-to-end and 13/13 Playwright, against a live database and calendar. That's how you trust the output.

KEY TAKEAWAYS
01 Write the plan as HTML: agree on the whole system first
02 Front-load every manual step, plus a stop rule: it runs unattended
03 Phase the work: one sub-agent per phase, delegated and tracked
04 Build a companion CLI: the agent tests through the same API
05 Independent QA agents: fresh context you can trust

Romain Pattyn • Codika

Building with agents: the blocks that let them run unattended.

01 / 15