Kima Circles — The Bottleneck Isn’t The Code Anymore
Those who know best how to execute are the founders !
That’s why at Kima, we organize peer-to-peer sessions between founders every two months.
Tables of 15-30 founders each take turns to talk about their problems: they share their struggles and best practices in complete trust. And they leave with actionable advice and WhatsApp contacts of peers with whom they can exchange afterwards.
The tables are led by coaches who are specialists in their field.
On September 29, hosted by Scaleway, we held a session for the CTOs and technical founders of the portfolio on building software with AI agents and hiring engineers in 2026.
Thanks for reading Kima Ventures! Subscribe for free to receive new posts and support our work.
SubscribedThe two specialists who led the discussions
The sessions were led by Jean-Baptiste Kempf, founder and CEO of Kyber, a longtime leader of the VLC project and former CTO of Scaleway, and Sylvain Utard, co-founder and CEO of Altertable, previously the first employee at Algolia, where he spent close to a decade building and leading the engineering team, then VP of Engineering at Sorare.
The companies around the tables had very different products and constraints. Some had built their codebases with agents from day one. Others were working with a decade of legacy code, physical systems or heavily regulated customers.
The stacks vary, but the questions were the same in both rooms: how much should we spend on tokens? Who reviews code nobody can read anymore? What breaks when the codebase outgrows the context window? Should we still hire juniors? How do you interview someone who codes with an agent?
1. What teams are actually spending
A year ago, Sylvain Utard was complaining about spending €100 per developer per month on AI tooling. He now barely writes code himself, after a roughly 60/40 split between him and the agent the previous year.
Most in the room were now at €400 to €500 per developer per month, and say they would be comfortable doubling or tripling it. Most were using a combination of Cursor Pro plans, Claude plans and Codex plans, often all three at the same time.
At the top of the range, one founder on Cursor’s Pro tier reported around $3,000 per developer per month. “People are going flat out, they’re producing code at an insane speed.” His worry is not the bill but the dependency it creates: so many lines that no human can review them anymore.
In the other room, Jean-Baptiste Kempf offered a budgeting rule. His business plan has a line for engineering salaries and, right under it, a line for tokens at 10% of that engineering payroll. Whether it goes to API tokens or to machines with 128 GB of RAM running models locally, the order of magnitude is the same. Above 10%, start asking questions.
2. Review has become the bottleneck
As soon as someone mentioned how much code agents produce, the conversation turned to review.
There’s two schools on reviews.
The first one automates with agents. A B2B SaaS founder described several layers of review. A dedicated agent checks the pull request. A different model then challenges the code written by the first. When more than five PRs are open, another agent triages them into changes that appear safe to merge and changes that need a decision. His own verdict: “It’s a review hell, but I outsource that too.”
The other keeps it simple with narrow specifications. Another founder prefers tight, restricted specs and asks whether a huge spec is worth it when a simpler, sometimes business-side, answer exists. For the handful of truly complex features, he locks himself in a room for three hours with an engineer to design the architecture by hand, then lets the AI review and write the code. He expects to need more review machinery later, “but the setup takes a crazy amount of time.”
A good example in the room is a two-developer team that had hit the limit. After setting up a terminal tool to run several agents in parallel, they found themselves producing far more code than they could read. They stopped development, returned to specifications and feature scope, and then built an automated review pipeline.
Today, that pipeline gives draft PRs a light pass and ready PRs a deeper review, with findings classified as minor, major or blocking. A separate agent checks whether the implementation has drifted from the specification. The team had repeatedly seen agents modify unrelated parts of the system or make a solution more complicated than it needed to be.
Utard added that the best investment in review is the test framework: deciding what to test, how, and how to make it easy for the agent to write tests.
In terms of tools, people mentioned CodeRabbit, Cursor’s reviewer, Cubic, Qodo, and Antithesis.
3. Specs, modules, simplicity: what makes agent code hold up
Jean-Baptiste Kempf’s rule at VLC and Kyber is simple: vibe coding is banned, AI-assisted coding is allowed. The difference is ownership. Someone must own the PR and is responsible for what ships.
His mental model of an agent: “an intern, a junior, whose only goal is to go have beers with his friends at 5 p.m.” It takes the spec and satisfies it the easiest way possible; that is how every LLM’s reward function is built.
The typical pattern is a correct first PR, then a second feature that “wrecks everything” and touches every part of the codebase. He says it is a real disaster right now at Google and Meta.
Three practices that work for his teams:
Modules, not microservices. Many modules and sub-modules that are real compilation units (a Rust crate, for example), so the agent is forced to work only inside that boundary. This is what prevents the unreadable PR where the agent broke everything to fix one thing.
One AI reviews the other’s spec. Write a spec, have a second AI review it, iterate until it is good. Then a human reviews the spec, which is the step that matters most. Then ask for a modular architecture before asking for code. He notes that almost nobody does this anymore: today’s “architects” are information-system architects, and nobody talks about code architecture.
A “rewrite it simpler” skill. Once the code exists, force the agent to rewrite it simpler with the same result. They cut code by close to 30% this way. The spec also brings the tests with it.
Tests need a purpose
The two-developer team said the volume of generated unit tests is enormous and about 70% serve no purpose.
Another CTO described the same failure from the other side: agents want to please, so they write tests where everything is mocked and nothing is tested. It took many iterations on the rules to get roughly correct tests.
Kempf suggested having a second agent challenge and clean up the first agent’s tests. Utard agreed this is the default if you do nothing. Altertable has precise skills on why and how to test, and on typing. If it is typed and it compiles, there is no point testing that a string ends up in a variable.
Typing is the best guardrail
Utard believes typing changes the quality of agent output more than anything else. He only writes Ruby because Sorbet adds types to it; Altertable itself is Rust and C++ for the core engine and some Ruby & TypeScript for the app. Another participant confirmed agents do “less voodoo” in typed languages. The robotics team, mostly Python, is watching mypy and Astral’s ty, which is not yet stable. They would write everything in Rust if they could, but the AI ecosystem lives in Python.
You need to maintain your SKILLS.md
A founder in the room said he rewrites all his skills every two months. Utard confirmed: product skills written eight or nine months ago were still explaining things that no longer made sense. Altertable deleted 14,000 lines of skills and kept five. It works very well.
4. Where coding agents works less well
The success stories share a trait: codebases born in the agent era, small enough to fit in context, and testable in a container. Three founders described what happens outside that envelope.
Legacy code without reliable tests
A founder in Sylvain’s room started his own codebase in January, but he also acquired a company whose Go codebase dates from 2014 and has seen fifty people pass through it in ten years. There, the agents “do whatever they want.”
Shipping a complete feature is nearly impossible; every task has to be scoped tightly. He attributes it to the combination of an aging codebase, missing documentation, and the absence of the “agentic verbosity” (comments, rules) that a codebase started with these tools accumulates naturally. He was scared to refactor, for fear of breaking untested code.
Utard’s contrast: Altertable, started in January 2025, made a point of occasionally “burning €100 of tokens” on a clean refactor even during heavy production periods. Refactoring is now so cheap there is no reason to hesitate, and the result is a codebase clean enough that agents reproduce its patterns reliably.
Codebases that outgrow the agent’s view
Another CTO’s codebase was written from scratch by agents starting last October. It now exceeds 600,000 lines, mostly Python with some Rust, and is far larger than any agent’s context window.
Despite the rules, agents reinvent the wheel on every task. He counted 700 different parsing functions. The team is looking at embedding the codebase or adding retrieval, and is working on interface contracts. His view: the problem is invisible on small, recent codebases, and the difference is size.
5. What a software factory really looks like
One founder wanted to “debunk a myth”: how many people actually run swarms of agents 24/7, the “American dream” of always-on engineering?
First answers from the room: “no, never” for some, “setting it up” for one. What exists is more partial and more interesting.
From a ticket to staging
The B2B SaaS founder has the most complete setup in either room. A conversation produces a specification in Linear. The ticket is tagged for an agent, picked up overnight, implemented and merged to staging, then tested through the CLI or the interface.
The workflow runs in a cloud VM with scheduled agent runs. It illustrates how much of a simple feature’s implementation can be automated. Reaching staging, however, is a different milestone from deciding that a change should reach customers.
The same founder had extended the approach beyond engineering : their “Company Brain”. Business colleagues who had never opened a code file were now working in Claude or Codex on a GitHub repository fed by sources including email, Slack, Granola and Drive.
Bots with a specific job
Utard runs a different kind of fleet.
A QA bot signs up every day and behaves like a new user. It reads the documentation, checks the onboarding flow against it, and uses the CLI and APIs. The run takes about twenty minutes and complements the CI tests by exercising the experience as a whole.
A benchmark bot receives a task such as comparing Altertable with a particular competitor on a particular warehouse type. A couple of hours later, it returns scripts and results.
A demo bot checks the demo account every morning and recreates resources that Utard deleted during the previous day’s demonstrations.
Each bot has a recognisable job and a result someone can inspect.
The dilemma: improve the setup, or build?
One founder described the immediate dilemma: spend three or four hours improving the setup, or spend those hours building the product. Another acknowledged that building the setup had become something of a passion and consumed a substantial share of his time. Complex features still required manual design.
Kempf raised a related concern. As a company grows from two people to twenty and then sixty, the CTO can become the only person who understands how the system works. Adding tools and databases is easy. Maintaining a business-critical system that only one person can operate is exhausting.
Putting more knowledge in a repository can help, but only if the team can find and use it. If everyone works in a different corner, with different tools and conventions, the CTO may remain the point through which every important decision passes.
His practical advice was to document the technical architecture early: how the system works, rather than only what the product is supposed to do. He also advocated refusing new technologies by default.
The useful question is whether the setup reduces the team’s workload or creates another system only the CTO knows how to run.
6. Hiring in 2026: the junior debate
If agents change what a developer does all day, they change who you hire. This is where the two rooms disagreed most, sometimes with themselves.
No juniors, or only juniors?
Utard opened with his own history. At Algolia in 2013, almost everyone was under 26 for the first two years, many straight out of EPITA where he taught. That required intensive onboarding and supervision.
At Altertable he has hired six people beyond the two founders, with no juniors, and did not expect to change that soon. The ecosystem moves so fast that someone who has already done it beats the average junior who needs support.
The other room reached the opposite practice by a different path.
An insurance founder reported receiving around a hundred CVs a day from a LinkedIn post, with very few candidates progressing through the process. Everyone he has hired came through the network: university, former classmates, former colleagues. The strategy that kept coming back: take interns from the top of the class at EPITA or 42, then hire the best. Another founder said some of his strongest employees had joined as early interns.
There was also an example from Utard’s room of a junior hired because he was exceptional. During the exercise, the candidate found a recently released open-source matching engine that the team had missed despite monitoring the field. When you are first mover on a new topic, you need someone willing to do a lot of research and be scrappy.
Kempf endorsed it and added his rule for both hiring and parting: “When there’s a doubt, there’s no doubt.” Keeping someone who is not good enough technically or, above all, is not the right cultural fit is never worth it, however long the search took.
Sourcing, and evidence beyond the CV
Utard looks for visible evidence of technical work: GitHub activity, or a track record somewhere (meetup, side project, LinkedIn). In interviews he listens for how the person keeps up (Hacker News, X), and wants real answers, not a certification.
For sourcing, he recommended spending time on LinkedIn, publishing, noticing who engages, and meeting speakers at technical events. He also asks candidates who are not a fit whether they know someone who might be.
At Algolia, at 100 to 150 people, the recruiting team ran a Friday sourcing lunch. Employees spent two hours finding people on LinkedIn and adding them to a spreadsheet for recruiters to follow up. “It’s long, it’s boring, but you need to do it.”
For a Rust role, a founder suggested a bot that overnight pulls the top 100 Rust projects, their contributors, their LinkedIn profiles, and every speaker at a Rust meetup in the last six months. With open source you can also see how someone behaves. He concluded there is still a human part: you cannot tell whether someone is good from their LinkedIn.
Other channels named: former CTOs or CTOs whose company failed, a common Algolia hire in 2013-2015 (”it proves they get their hands dirty”); school forums (”bring 200 stickers and 80 bottles”); recruiting firms on success fee (20 to 30% of salary) or RPO when many identical roles are open.
How to interview when candidates use AI?
The take-home assignment no longer works. Utard’s recommended process: a 45-to-60-minute first call, a more technical second call, then an hour of live coding, in screen-share on the candidate’s own laptop so they are comfortable.
Does the candidate get to use the agent? Utard says yes: test people as they will work, and they will not restrain themselves on prompts. If they finish the exercise in one prompt, fine; then “explain it to me, review it.” And when someone claims to code with AI, “no, show me.”
One participant objected that one time in ten the candidate writes a prompt that is slightly too open, the agent reads the whole repo, finds every trap and solves it in five minutes, and there is nothing left to observe. His team now controls the prompts. Others suggested exercises the model cannot solve directly: logic, math, a business problem, a whiteboard design.
Another founder, after a failed first Rust hire, stopped testing the language at all. He verified it through reference checks, then ran an engineering test with no code: handle prompt caching, draw the architecture, decide what goes where, optimize. That part separated candidates sharply. The question “do you code with AI?” did not.
7. Around the code: pricing and custom integrations
Pricing when the value is tokens
The founder of a startup selling to large enterprises faces an “almost financial engineering” problem: customers want multi-year fixed-price contracts, while his underlying cost, the token, is neither fixed nor predictable.
Kempf called it a star question with no answer except testing with customers. Another founder suggested changing the contract’s shape: sell a million euros of consumable credits at current conditions rather than three years of guaranteed service.
The room expects tokens to get cheaper at constant intelligence, since today’s frontier will run on smaller models in three years, and one participant cited a fast model running at 98% inference margin, as evidence that labs are not all losing money.
What about client integrations?
A founder serving merchants named his itch: client implementation.
Some clients take the API docs and run; others need everything done for them, and they pay well, so you cannot drop them.
One founder has a customer using a CRM with no API and COBOL still inside. The founder planned to run an agent in a VM to navigate the interface and download files. With an account worth around €100,000 a year, he considered a three-week, €15,000 implementation worthwhile.
A competitor had declined the integration. He saw his willingness to do it as part of the company’s defensibility, while worrying about maintaining a separate integration folder for every customer as the business grew.
Kempf expected common patterns to emerge: by thirty customers, perhaps four or five integration types. If no reusable patterns appeared, that would be a reason to revisit the approach.
The decision involves more than whether an agent can write the connector. It includes understanding the customer’s workflow, deciding which exceptions are worth supporting, and turning repeated work into something maintainable.
On pricing integrations: setup fees credited against usage work for now; another founder bills every request beyond the basics as a daily rate upsell.
What’s left to defend
Late in the evening, one founder argued that software defensibility barely exists anymore: the cost of software tends to zero, and what counts is execution and understanding your market.
Kempf partly disagreed. Deep technical expertise still creates a barrier. On topics he knows well, including low-latency networking and clock drift, he periodically tests Claude and continues to find its answers inadequate. Other participants emphasised domain expertise.
The examples throughout the evening explain why both views can hold. Agents can accelerate implementation while leaving difficult technical and business questions unresolved. A larger volume of code does not tell a team whether it has understood those questions correctly.
Kempf saw opportunities in verifying the security and correctness of the software being generated, and in the work that precedes implementation: gathering knowledge, designing architecture, writing specifications and managing that information.
Which is, section by section, what this evening was about.
It was 7:45 p.m. “Time for a drink, if that works for you?”
© 2026 Kima Ventures
16 rue de la Ville l'Evêque, 75008 Paris, France