Every morning, Camille opens his terminal. Eight new pull requests are waiting for him. Created, reviewed, and pre-approved while he was asleep.

Not by a team. By his agents.

In this episode of Build with AI, Tanguy Goretti (CTO at Hexa) sits down with Camille Epitalon, CTO and co-founder of Verso, a startup he built entirely solo on the technical side in three months, with over twenty paying enterprise clients already on board. Camille opens his terminal live and walks through, brick by brick, the setup that makes it all possible.

Verso: A full-AI qualitative research platform

Before diving into the setup, a word on what Verso actually does, because it’s inseparable from how Camille codes.

Verso is an AI-native qualitative research platform. In practice: where agencies like Kantar or Ipsos used to charge €100,000 and three months of lead time to conduct qualitative consumer interviews, Verso delivers the same output in three days for a few thousand euros.

The product covers the entire chain: an AI agent co-designs the interview guide with the client, other agents recruit participants, an AI moderator conducts the interviews (video, audio, screen share, emotion analysis), and researcher agents produce a dynamic report from the raw data. The client can then query that data through a built-in chat interface.

The philosophy: giving codebase ownership to your agents

From the very first minutes, Camille lays out the mental framework for everything that follows:

“From day one, I told myself: I’m handing ownership of my codebase to my agents. The codebase belongs to my agents.”

It sounds radical. But Camille is precise about what it means and more importantly, what it doesn’t mean.

Delegating ownership doesn’t mean letting go of the wheel. It means investing heavily in what he calls harness engineering: everything that surrounds the codebase so that agents operate within a safe, consistent, and opinionated framework.

Two conditions are non-negotiable, according to him:

1. Solid foundations in the code. Clear abstract classes, well-defined contracts, enforced patterns. For example, all his repos inherit from an OrgScopedRepo: which ensures that when an agent creates a new repo, it automatically picks up all the security and authentication abstractions. The agent doesn’t need to be told the rules: they’re baked into the structure of the code.

2. Well-equipped agents. Not just with instructions, but with the right tools to observe the environment: logs, tracking, GitHub, CI. An autonomous agent needs to be able to connect to everything it needs to make decisions without constantly asking its human.

The live setup: 6 worktrees, aliases, a terminal as cockpit

Camille moved from VS Code and Cursor to... his terminal.

His setup is built around 6 permanent worktrees, each associated with a color in his terminal (via iTerm). When he opens a profile, the worktree automatically re-syncs with main. The entire lifecycle (reset, sync, opening a PR) is managed through aliases. To launch Claude Code, he types c. Codex: x. Full dev environment: d.

The metaphor he uses is vivid: “My six worktrees are like six different engineers. I try to avoid having them work on the same thing.”

In practice, each worktree maps to one PR. Camille works async, he kicks off a task, switches to another worktree while the first one runs, and comes back to check the result later. Six instances in parallel, but never all active at the same time.

The cron jobs that code through the night

This is the part that raises eyebrows.

Every two hours, and especially overnight, cron jobs launch Claude or Codex agents in headless mode from Camille’s Mac. These agents follow predefined skills, do their work, and open pull requests on GitHub. In the morning, Camille just has to review them.

These cron jobs are primarily focused on clean code and refactoring. A few concrete examples:

• Backend audit: reads the Python/FastAPI guidelines, produces a report prioritized by criticality and fix complexity, then picks the best value/effort trade-off to create a targeted PR.

• Frontend audit: same principle on the React/TypeScript side.

• Skills sync: checks every day that the .claude and .codex config folders are in sync - if a skill was updated on one side but not the other, a PR is automatically opened.

• Simplify skill: a Claude built-in skill that identifies over-complex areas in the codebase and proposes simplifications.

The logic: rather than blocking a large refactoring project, agents chip away every night at small, targeted improvements. Day after day, the codebase cleans itself without friction.

“Verso is the codebase that never sleeps.”

The Ralph Loop: launch a feature before bed

For heavier features, Camille uses the Ralph Loop.

The concept: a bash loop running continuously in the terminal. At each iteration, it reads a Markdown spec written upfront, consults a tracking file that records where the implementation stands, spins up a new agent (Claude Code or Codex) to handle only the next step, and updates the tracking file with learnings and results.

Each agent operates with a fresh context and a limited scope, avoiding context bloat and drift over long tasks. The source of truth is never in the context window: it’s in the filesystem.

In practice: Camille writes the spec with an agent’s help before heading to lunch or going to bed. He launches the ralph loop. When he comes back, the feature is implemented, or close to it.

Camille notes that some sessions can burn through all his API credits in a single night on ambitious tasks.

The automated review chain

No PR ships without going through multiple layers of review. Here’s the full chain:

1. Auto-review during implementation. The Implement skill automatically calls Review Current Work at each step. The agent self-reviews before opening a PR.

2. Cross-review between agents. Claude Code and Codex review each other’s work. Camille doesn’t necessarily read the diff himself - he asks Codex to review Claude’s work and vice versa, via the Check Reviews skill, which triages comments and proposes fixes.

3. External AI reviewers. Three tools run on every PR: BugBot, Cubic (a YC startup that Camille says is taking off fast on benchmarks), and Code Rabbit (which he finds less impressive today but keeps out of habit). After each comment, a loop mechanism checks the PR 30 minutes after the push, triages the feedback, fixes what can be fixed, and pushes again.

4. Final human review. Camille steps in last, for high-impact decisions or complex trade-offs. The skills are explicit about this: “Don’t make one-way-door decisions without me.”

The cost of all these tools? A few hundred euros a month. Camille is unequivocal: it’s a non-negotiable expense.

Live Browser QA

To validate front-end changes, Camille uses a browser QA skill inspired by Vercel’s. The agent connects to the local app (each worktree runs its own instance with its own DB), navigates to the given URL, takes screenshots, clicks, interacts, and produces a report detailing what works and what doesn’t.

In the live demo, you can watch the agent open Chrome, auto-login to Verso, find the right component, test it, and validate that a video playback speed control button works correctly.

The current limitation: screenshots don’t capture animations. Camille thinks the real revolution in agentic QA will come when models can read video in real time.

Business skills: the whole team is AI-first

An often-overlooked point: at Verso, agents aren’t reserved for developers.

From day one of onboarding, everyone, including the business team, has access to Claude Code, Codex, and the terminal. Business-specific skills have been built for them: drafting an email, preparing a client’s context in the knowledge base, writing a LinkedIn post, or aggregating all call transcripts and emails from a client to pre-fill study templates.

There’s also the Teach skill: when Camille just accomplished something manually with an agent, he can immediately ask it to document what it just learned as a reusable skill. It’s the self-improvement mechanism of the harness itself.

The agnosticism principle: never get locked in

Camille emphasizes a structural point: his setup has to work regardless of the provider.

Skills are nearly identical between Claude Code and Codex (with minor format adaptations), and a cron job checks every day that both config folders are in sync. When Anthropic has outages he switches to Codex without friction.

“Tomorrow, if another provider is better, I’ll switch with pleasure. Being agnostic and not locked in is pretty important.”

Takeaways for ×10 (or ×100) developer productivity

In closing, Camille and Tanguy summarize the principles they apply at Hexa and Verso:

Invest in foundations first. Agents build on what they see. If the code structure is ambiguous or inconsistent, AI will drift in the wrong direction and it compounds. Clear patterns, well-thought-out abstractions, guidelines documented as Markdown files in the codebase: that’s what determines the quality of everything produced afterward.

Run regular audits. Periodically, ask the agent to cold-analyze the codebase: what are the main separation-of-concerns violations? Where is there code duplication? Which areas have drifted from the guidelines? It’s an effective way to identify technical debt before it accumulates.

Engineer the harness hard. Skills, hooks, agents, cron jobs: everything surrounding the codebase deserves as much attention as the codebase itself. It’s an investment with exponential returns.

Don’t panic about new tools. A new “game-changer” tool drops every week on LinkedIn. Tools change. Principles don’t.

“Vibe coding is the worst name for this practice. It’s real engineering work, defined workflows, clear foundations. It’s not ‘go with the vibe’ at all.” - Camille Epitalon

The bottom line

What Camille built at Verso isn’t just an efficient dev setup. It’s a way of working where agents are treated as real collaborators - with clear responsibilities, a well-defined framework, and progressive autonomy.

The result: an enterprise product in production in three months, built alone. Paying clients. And nights where the code keeps improving while he sleeps.

Hexa Product Lead Pierre sits down with Louis Pinsard, CTO & co-founder of Dialog — an AI shopping assistant handling hundreds of thousands of conversations per month across 200+ ecommerce stores — to explore how they scaled from basic RAG to the infrastructure that supports several hundred thousand conversations a month.

They started with a very basic RAG setup, which was enough to land their first client. But pretty quickly they hit the real problems: product catalogs that explode in size and break your retrieval, a growing volume of users with increasingly diverse queries, keeping latency low through all of it, and building evaluations that give you objective criteria to actually know whether your agent is getting better or worse.

Louis walks through the full technical evolution, from chunking strategies and retrieval tricks to the evaluation systems they wish they’d built sooner.

You can watch the full conversation above, or read the recap below.

Subscribe now

1) The first version was literally a LangChain tutorial in production

Dialog started in early 2024, right around when GPT-4 had been out for a couple of months. The team needed to move fast, so they did the most basic thing possible: a textbook RAG setup. User sends a message, you search for semantically close documents, stuff them into the LLM’s context, generate a response. A few lines of code, shipped to production.

It worked well enough to get about ten Shopify design partners on board. There was no real evaluation system — Louis would test a handful of queries manually and go with his gut. The models were also expensive, but the bet was that prices would keep dropping. That bet has held up.

2) Not every message deserves an expensive LLM call

Pretty quickly, they noticed people typing “hello” or sending off-topic messages, and the system would dutifully burn through tokens on zero-value interactions. So the first meaningful addition was a routing classifier that decides what kind of message this is before anything else happens. Is it store-related? About a specific product? A policy question? Or just noise?

This became one of the most important components in the whole system. The core idea hasn’t changed since: not all queries should be treated the same way, and sorting that out first saves money and improves quality simultaneously.

3) Re-ranking fixed the hallucination problem

Hallucinations came from two places: the retrieval step failing to surface the right documents, or surfacing too many and the LLM getting lost in an oversized context.

The fix was a re-ranking step. Instead of retrieving 10 documents and hoping for the best, you first cast a wide net — about 100 candidates — then run them through a specialized model whose only job is to pick the 10 most relevant ones for the given question. Tighter context, better results, fewer hallucinations.

4) The user’s question is almost never good enough to search with directly

If someone is on a skincare product page and asks “is this good for my skin type?” — that query has almost no useful semantic content. No product name, no ingredient, nothing for retrieval to latch onto.

One technique that worked well early on is HyDE — Hypothetical Document Embedding. You ask the LLM to generate a plausible answer without context, then use that hypothetical answer as your search query. Even a hallucinated answer will be semantically closer to the real documents than the vague original question was.

They also enrich queries with page context, conversation history, and keyword extraction. The rephrasing step turned out to be one of the highest-leverage improvements in the whole pipeline.

5) How you chunk your product catalog matters more than you’d think

A product has a title, a description (sometimes enormous), variants, collections, metadata — and if you naively chop all of that into fixed-size chunks, you get fragments where the end of a description bleeds into collection data. That’s meaningless to a retrieval system.

Dialog splits along logical boundaries first — description separate from title separate from variants — then applies size-based chunking within those sections. They also attach metadata like the product name to every chunk so fragments can always be traced back to their source. This becomes critical when you need to filter by price, skin type, or other attributes.

6) The filter trick that made structured catalogs useful

Many ecommerce catalogs already have structured filter systems — skin type, brand, price range. Dialog realized they could extract filters from the user’s natural language query before even hitting semantic search.

So “what’s a good moisturizer for dry skin?” gets “dry skin” extracted as a filter, the search is restricted to matching products, and semantic retrieval runs within that smaller subset. It’s adding determinism into a fuzzy process — and it works because the catalog structure already exists, you just need to tap into it.

7) They flew blind on evaluation for the first six months

For the first six months, improvements were measured by vibes. Louis would test manually, look at logs, ask clients to try things. That worked while the wins were obvious. But eventually changes got subtler and the risk of breaking something elsewhere got real.

The classifier was easy to evaluate — known input, known correct category, score it. RAG evaluation is much harder. You need query-document pairs that represent ground truth, and building that dataset requires genuine domain expertise. They use a mix of LLM-as-judge and human review, but Louis is clear this is still evolving.

8) What Louis would tell someone building an agent from scratch today

Three things.

Observability early — log the inputs and outputs of every component from day one. You’ll always be glad you have the data later, even if you don’t know exactly how you’ll use it yet.

Don’t jump to vector databases. Classical text search — BM25, Elasticsearch, even grep-style approaches — works better than people think, especially with structured data like product catalogs. Louis points to Claude Code as an example: it searches codebases through clever grep queries, not embeddings. Start simple, add semantic search when you’re genuinely hitting limits.

And use Python if the AI system is the core of your product. The ecosystem, tooling, and talent pool are all there. It sounds obvious, but it’s not always the default choice.

If you’re building AI agents on top of messy real-world data, the full conversation is worth your time. Louis gets into the details in a way that’s rare for a CTO of a company at this stage.

Subscribe to receive future episodes of Build with AI.

Watch on Youtube for English subtitles (settings > auto-translate > English).

AI is changing company building from the ground up. But what does that really look like, day to day, when you’re starting something new?

That’s what Build with AI brings to life.

We’re kicking things off with the very first step: finding and validating the idea. Hexa Partners Florent Quinti and Ugo Vollmer share how they’ve learned to use AI to explore unknown markets and test hunches.

In this episode

They share:

• What we look for in a day-zero idea

• How AI helps us explore an unknown market

• Turning intuition into conviction

• Prototyping without a CTO to test faster

• Where AI stops, and what stays human

When everyone can spin up 100 ideas in an afternoon… what’s the real edge?

Find out in the full episode.

Where to find Flo

Subscribe to his AI newsletter: https://www.linkedin.com/in/florentquinti/

Where to find Ugo

Ugo’s linkedin: https://www.linkedin.com/in/vollmeru/