One engineer, on purpose.
I’m Johannes Girard — a senior platform engineer, French, working fully remote from Normandy. (LinkedIn) AiOverload is my project: built in my free time, developed in the open from the public release on, with everything this site claims pinned by tests rather than by confidence. This page is the honest version of who I am and how the thing was actually made.
The path
Hotels, AWS certs, and a long way around.
Five-star hotels → engineering school at 25
Before tech, I worked in five-star hotels. At 25 I went back to engineering school — and kept working hotels on weekends and holidays to pay for the studies. Hospitality teaches you service under pressure; engineering gave me the system. Both stay in everything I build.D2SI — consulting in Paris, five years
Right after school I joined D2SI in Paris because I wanted experience fast — consulting delivers that. Five years, many clients, and four AWS certifications: Solutions Architect (Associate and Professional), DevOps, and Developer. I left having learned a lot — and D2SI is still the company I miss the most: it’s where I met the most important person in my career, the one who let me do what I do today. With confidence. (Or so I keep telling myself.)Architecture, then enablement
I fell in love with architecting first, discovered DevOps second — and then the mix of both: being an enabler so developers can focus on their jobs. Then monitoring, post-mortems, keeping platforms ready and understandable, docs that stay up to date, observability everywhere — and never, ever forgetting the price of anything.Accor, Aircall, Veolia — then sennder
I moved fully into system architecture: customer problems under real constraints — product, pure backend, data, a bit of big data — and moved from Normandy to Paris along the way. Since then: Accor Group, Aircall, Veolia — and sennder, where I’ve been for more than four years, fully remote, back in Normandy.One more thing about the path: I entered the IT world at 30 — later than most, and I got here on the trust of others. I was lucky to meet people who believed in me early and helped me grow alongside them; I learned from their hard skills and their soft ones. That debt is part of why this project ships in the open: trust, passed on.
Why this project
Agents are easy. Fleets are hard. Governance was missing.
Creating an agent is easy. Running several is harder. Governing them — real boundaries, real audit, at scale — there was no solution I wanted to run. So I built the missing half, and I followed the principles declared all over this site: contracts before code, deny-by-default, the event log as truth, loud failures, cost as a first class citizen. Strongly opinionated? Yes. But I trust the process — because the process is what makes the claims checkable.
It took iterations to get here: different languages, architectures, data management, harnesses — more than six months of broken builds before the shape held. Now it’s close. Close enough to show.
Today AiOverload is developer-first, because its GitOps spine assumes git. The destination is domain-agnostic: the same governed-execution layer for any team whose agents touch real keys and real consequences.
The honest risk
Probably too ambitious — said out loud.
Let’s be direct about the scope: an event-sourced engine, a reflex gate, a gateway boundary, a console, a task plane, a fleet directory, a knowledge plane, and an always-on resident runtime — that is a lot of system for one project, never mind one maintainer. It may be too much. Saying so is cheaper than discovering it late.
The counterweight is a rule I try to apply without mercy: every piece of complexity has to earn its place against usability. A governed step must not be harder to run than an ungoverned one; a boundary that operators can’t read doesn’t get merged; a feature that only demo’s well waits until it works well. I don’t always get the balance right — but I am trying my best to find it, in the open, where the trade-offs are visible instead of buried.
Full disclosure
Built mainly with AI — and here is exactly how.
Most of AiOverload — the engine, the docs, the ADRs, this very website — was written with AI pair-programmers, mainly Kimi: Kimi 2.8 Preview and Kimi 3 through Claude Code and Kimi CLI, with Z.ai’s GLM 5.2 and 5.3 in the loop and Mistral reviewing pull requests. All of it under my direction. That fact deserves the same honesty as everything else on this site.
The discipline, stated plainly:
- Agents draft; the ladder judges. The same class of model writes the code and reviews it — which is precisely why nothing ships on anyone’s say-so. 71 Go packages of tests, 166 reflex tests, contract schemas for every wire payload, and a hermetic CI ladder decide what merges. A claim without a pinned test is a bug, whoever wrote it.
- Decisions are recorded where they can’t be rewritten afterwards — ADRs with rejected alternatives, an issue tracker as the working record, conventional commits that reference both.
- The human owns the taste. Architecture calls, refusals, and the boundaries of what gets built at all are mine. The models are extremely fast pair-programmers; the opinions are the maintainer’s.
- Mistral keeps the record meaningful. Pull requests are checked for purpose, and the issue tracker stays clear, well-defined, scoped, and cross-linked — the record stays navigable because it is kept navigable.
- The log is honest about its limits. Every commit is authored under my own token — git shows my name, not the tool that helped draft the change. What makes the record trustworthy isn’t the byline; it’s that every claim in it is pinned by a test.
This is what agentic development done carefully looks like — and the reason this platform exists is that done carefully should not require one engineer’s stubbornness. It should be the default.
Public release soon.
Self-hosted, AGPL-3.0 — and developed in the open from the first public commit. Source and docs publish with the release. Leave your address: one email at release. That’s it.