I went through this in a podcast with Tanguy Goretti at Hexa. This is the written version, with the parts that matter and none of the ums.
One disclaimer first, because it changes how you should read the rest: I built this alone on the technical side. A designer and a PM help, and there is a team around me, but I am not running a twenty-person engineering org. I am not giving lessons. Plenty of problems arrive when you scale a team that I have not had to solve yet.
From day one at Verso there was not a line of code written by hand. I decided the ownership of the codebase would go to my agents.
That sounds like abdication. It is the opposite. Giving up ownership only works if you pour everything you would have spent writing code into the layer around it — what I call harness engineering.
Foundations enforced in the code itself. Not documented, enforced. Abstract classes that leave no choice: every repository inherits from an org-scoped repository, so when an agent creates a new one it looks at what sits next to it and inherits the security and authentication abstractions whether it thinks about them or not. Be extremely opinionated, and put the opinion where it cannot be ignored.
Tools that let agents be autonomous. They need to know how you code, but also to reach the environment: read the logs, check the CI, look at GitHub, inspect the tracking. An agent that cannot see the consequences of its work will not produce good work.
I say I gave up ownership, but I still spend my time in that codebase. The ownership I gave up is over the lines. Not over the shape.
I went back to my terminal. I tried the tools built for this — Conductor and others — and found nothing that beats my terminal with my own aliases and shortcuts.
Six permanent worktrees. Most people create them on the fly; mine are permanent and their whole lifecycle runs on aliases. Each one gets its own colour in iTerm so I know where I am at a glance. One worktree, one PR — I keep the mono-commit-per-PR habit from the old world. Each has its own database, backend and frontend, so I can run six versions of the app at once. Launching Claude is c. Codex is x. The whole dev environment is d.
Claude and Codex run side by side, always. One scopes and implements, the other reviews — it is rare that a PR is opened without both having been over it.
I call my skills declaratively rather than hoping the agent picks the right one. The central one is implement, which itself calls the others: read the guideline files, implement, run review-current-work, then run the browser QA skill if the change touched the frontend. Another one, teach, captures something we just did together so the agent can do it alone next time. The harness improves itself.
Hooks are the underrated part. A pre-tool-use hook blocks what should never happen — removing a file, resetting a database. A post-tool-use hook logs every tool and skill invoked, so I can audit later which skills are never used and prune them. Low effort, high impact, especially on security.
Then the cron jobs. Every night, agents run an audit skill against a slice of the system — backend, frontend, docs, security — and each produces a report ranking issues by severity and difficulty. An auto-improve skill picks the best complexity-to-value trade-off and opens a PR. Around eight a day. One job checks that my .claude and .codex setups have not drifted apart and opens a PR when they have.
The running joke is that it is the codebase that never sleeps. It works at night and I review its work in the morning. It is like having three or four engineers who only do clean-up — and day after day, the codebase gets cleaner instead of rotting.
Every PR is reviewed by Bugbot, Cubic and CodeRabbit. The point of running three is coverage: what one flags, the others usually miss. Then a loop checks the PR thirty minutes after it was pushed, triages the comments, fixes what needs fixing and pushes again, until everyone agrees and all that is left is my final look.
They cost real money and it is still absurd value. Compared to a senior engineer's salary, a few hundred a month for something that reviews every PR you open is nothing. When they go down you feel naked.
For bigger jobs I write a spec, then run a loop. Each iteration reads the spec, reads a markdown file tracking where we are, spawns a fresh agent to do only the next step, has it update the tracking file with the result and the learnings, then exits. A new agent picks up from there.
The truth is what is in the markdown and the filesystem, never what is in the context window.
That is the whole trick. It keeps context from bloating and it forces the separation of concerns across many agents instead of one overloaded one.
Everything above should work regardless of who is behind it. When Anthropic has a bad week of outages, plenty of people are completely blocked. I move to Codex and it is fine. If a better provider shows up tomorrow I will take it.
That is why I keep the two setups in sync, and why I care that neither takes precedence. The model is a plug, not a dependency.
Be rigorous about the first foundations you lay, because that is what the agents build on. Bad foundations are the context every future decision inherits — it compounds either way, and the direction is set early.
Step back periodically and ask, point blank: which of my guidelines are still true? Where has the frontend drifted? Where is the duplication? Doing this regularly surfaces the places you have quietly stopped agreeing with your own codebase.
Then invest in the harness. All of it — skills, hooks, the review loops, the crons.
A lot of developers say what they loved was writing code. I do not find my days less challenging. I find I spend all my brain on the problems that actually matter.
Vibe coding is a terrible name for this. There is nothing about going with the flow. It needs a very defined workflow and very clear foundations. What changed is the volume: far more decisions per day, far more context to hold, and enough context switching that you can lose track of which subject you were on. That is exactly why it is worth building a system that does not need you for every decision.
I could not have done this a year ago. What we have today would have taken two years, maybe one. It is a real multiplier — and it demands a lot of rigour, and a lot of investment in everything around the code.