Hiring the first engineer for a vibe coding platform inside a French bank

I spent the last few weeks interviewing candidates for a job that has no template: first engineer on a vibe coding platform inside a large French bank. Not a chatbot, not a copilot rollout, and not a tool for developers. A portal where any employee describes what they need and agents build it: dashboards, internal power apps, small web apps. The analyst who tracks branch performance in a fragile Excel file should be able to turn it into a real app without opening a ticket.

The bank already runs an AI coding platform serving more than 2,200 developers. That solved creation for the people who could already create. This portal is the harder bet: extending it to the tens of thousands who couldn't. Hiring for it taught me more about the current state of the market than any report I've read this year.

Everyone has an agent story now

Here's the problem with interviewing for this kind of role in 2026: everyone has built agents. Or rather, everyone says they have. The word costs nothing.

So I ended up sorting candidates with a crude filter I now use everywhere: real experience versus narrated experience. Narrated experience sounds great in an interview. The candidate walks you through an architecture and names the right tools. Then you ask what broke in production and the story dissolves. There was no production. There was a demo, a weekend project, sometimes just a well-digested YouTube video.

Real experience is messier and less articulate. The candidate hesitates, then tells you about the retry storm that doubled their token bill, or the tool call that failed silently for three days. You can't narrate your way into that level of detail. Pain is the only teacher of it.

And for this product, the bar is higher than usual. When your users are developers, they debug around your rough edges. When your user is a branch analyst, the agents have to hold up on their own. Whoever builds this needs to have seen agents fail in the wild, because here nobody will be watching the logs for them.

The ones we didn't hire

Some candidates were too junior for a role this exposed. Some were senior on paper but hadn't touched the agent stack beyond prompting. One or two were technically fine and just wrong for the team. All normal. What surprised me was how weakly seniority predicted anything. Ten years of Java tells me you can engineer. It tells me nothing about whether you've internalized how LLMs fail.

The person we hired is 25. Yes, I passed on candidates partly for being too young, then hired one of the youngest in the pool. The difference: he has already shipped agent networks that run in production today, with real users and real consequences. Age was never the variable. Scar tissue was.

Week one: vision before tickets

He started Monday. I spent the first day on context rather than setup: why the platform exists, who it's actually for, where I want it to be in a year. I plan everything backwards from the end state, and I'd rather he argue with the destination now than discover it in a sprint review in October.

On Tuesday I put him in front of the sponsor two levels above me. Thirty minutes. The sponsor confirmed the vision in his own words, without me steering. That meeting mattered more than any onboarding doc. When a new engineer hears the same story from the person paying for the project, ambiguity dies early. Most onboarding failures I've seen were alignment failures wearing a technical costume.

Agno, probably

Framework-wise we're leaning toward Agno. Not decided, but leaning.

The short version of why: it's an open-source Python framework with a runtime (they call it AgentOS) that runs entirely inside your own infrastructure, and the control plane connects to it rather than the other way around. For a bank, that direction of data flow is the whole conversation. Nobody signs off on employee-built apps passing through a third-party retention layer.

It also ships guardrails, human-in-the-loop approvals and audit hooks inside the runtime rather than bolted on. That matters twice as much when the people generating apps aren't engineers. I've built approval flows by hand before, at another client, on another stack. I never want to maintain that plumbing again.

The honest caveat: the new hire has more hands-on hours with these frameworks than I do. Part of why we hired him is so this choice gets made by someone who has felt the sharp edges, not just read the comparison posts. If he comes back in two weeks arguing for something else with production reasons, I'll listen.

If you're hiring for this

Ignore the years. Ask what broke. The people who can build agent platforms right now are the ones who have already been burned by them, and that population is young and small. Find someone who has been embarrassed by an agent in production. Everything else can be taught.