Ten years away from code, and what it gave me to come back

On the evening of 20 August, I opened a code editor for the first time in five months. Not out of some abstract urge: I am the president of a taekwondo club, its WordPress site was falling apart, and registrations opened three weeks later. A date, people waiting, no budget. The next day, the new site was online.

Ten years ago, I could not have done that in a day. Ten years ago, though, I was writing code every day. That paradox is what I want to tell.

Stepping away from the keyboard, one job at a time

I was a developer for seven years. Java, then iOS, for SFR, Natixis, Schneider Electric, a year in Geneva writing Swift. I knew my tools, I shipped, I liked it.

Then, in 2015, Gameloft gave me a team of twenty-five people in Vietnam. Later, the product ownership of a payment platform for Swiss and French banks. Then the technical leadership of a hundred-person company. Then founding a game studio with 760k€ of investment. Then presales: scoping, pricing, answering tenders, winning or losing.

With every role, less code. And with every role, something else to learn. Writing down what you want before asking for it. Breaking work down. Knowing where the risk is in a project, and where it is not. Saying no to a feature. Hiring. Holding a budget. Reviewing other people’s work without redoing it. Delivering on a date you promised.

Throughout those ten years, I kept a list. Projects that rattled around in my head, never started. A quiz buzzer for evenings with friends. A card game. A tool for an old strategy game I never let go of. The club website, rebuilt properly. None of them ever left the notebook. No time, and above all a gap that widened every year between what I knew how to do and what it took to do it.

What AI tools really changed

“Vibe coding” is often presented as faster typing. That is not what I experienced.

What I was missing to execute those projects was not the head. It was the hands, and the time. What I got back in February 2026, when I tried Claude Code for the first time, was a team. A team that writes fast, never sleeps, does not take offence when told to start over, and has exactly the flaws of a team: it does what you ask, not what you meant. It does not check on a real phone. It produces a nineteen-sprint plan for a game that will be published six days later.

In other words: what you need to know to work well with these tools is exactly what I spent ten years learning as I moved away from code.

Two concrete examples.

WhatToPlay, fifteen days, thirty-nine pull requests

The idea is simple: the PlayStation Plus catalogue is huge, and I just wanted to know what to play, sorted by rating. On 30 August, I started. On 13 September, the site ran in six languages across ten countries, updated every night.

Getting the data. The first reflex would have been to scrape Sony’s website. I asked first to look at how the public A-Z list on playstation.com was populated. Answer: a JSON endpoint, undocumented but stable, that returns a country’s whole catalogue with identifiers, cover art and dates. One hour of scoping, and the project’s most likely failure no longer existed. That is a presales decision, not a developer one: find where the risk is before writing a line.

The ratings. Neither Sony nor anyone else publishes a catalogue with press scores. It had to be cross-checked: RAWG for Metacritic, Steam as a fallback when RAWG sign-ups stopped working, HowLongToBeat for play times, IGDB as a third source to go from 64 to 72% coverage. A title is not an identifier: “Game Name”, “Game Name™”, “Game Name — Director’s Cut” are the same game or not depending on the source. The tool wrote the collection with hardly anything for me to fix. It could do nothing about the matching, because that is not a code problem: it is three hundred small decisions. Those, the product owner makes.

The design. A first interface on 30 August, ugly but working. An editorial redesign on the 31st, with sortable headers and a dark theme. A redesign of the visual system on 11 September, after ten days of using it every evening. I never asked “make me a nice site”. I asked for one thing at a time, looked at the result, corrected. Prompt after prompt, the way you run sprint reviews.

Deployment. Ingestion runs in GitHub Actions, at 05:17 UTC, and commits the data to the repository, which redeploys the site on Vercel. That is not the default choice; the default is a cron at the host. But the free plan caps function duration, and ten countries times several hundred games do not fit. With Actions, the catalogue’s history is free and a rollback is one git revert. That is a CTO decision: an architecture one person can sustain.

The method. Thirty-nine pull requests in fifteen days, one per subject. A circuit breaker per data provider when the cron started failing. A reproducible SEO audit in one command. Those are a manager’s reflexes, not a coder’s: you do not mix two subjects in one delivery, and whatever broke once must be caught the next time.

Taekwondo Meylan, or how WordPress became text files

The club website is the other example, and the most telling about what years of management bring.

The WordPress had a premium theme, a page builder, and a single administrator: me. Schedules were duplicated between the home page and the course pages. The HelloAsso registration link changes every season, and in August 2026 the home page still pointed to the 2025-2026 form. Nobody had noticed.

The new site is built with Astro. Content is versioned text: one YAML file for schedules, prices and links, one Markdown file per team member, per article, per event. And a schema that refuses to build the site if the content is inconsistent: a course without a schedule, a rank written “3eme Dan” instead of “3e dan”, a HelloAsso link that does not carry the current season. That check would have prevented August’s mistake.

The result: 104 redirects from the old addresses, verified on every deployment. A font served from the site instead of Google Fonts, and mobile Lighthouse going from 94 to 99, first paint from 2.5 to 0.9 seconds. A 3.3 MB share image that became 141 KB. And for the volunteers, an admin chat where you type “move Wednesday’s class to 6:15 pm”, which prepares a draft on a branch, shows a preview, and publishes only if someone clicks Publish. That button is not one of the agent’s tools. It is the only path to production.

I come back to this site at length in the next entry: it is twenty-five years old, and this is its fifth version.

What ten years of management gave my evenings

When I look at how I work on these projects, I see every job I have held.

The product owner writes down what he wants before asking. A three-page design document produced a card game published in six days. A vague brief produced two dead projects in February, with hundreds of pages of documentation and zero useful lines.

The estimator knows where the risk is. On day one, the tool produces a nineteen-sprint plan. I read the order and ignore the durations: the sequence is still right, the calendar no longer means anything. And I know that the bug that only happens on a Galaxy A33 will cost three days, whatever the tool.

The CTO picks an architecture one person can sustain. No framework when two lines will do. No database when versioned files do the job. The cron wherever it fits the budget.

The producer cuts. The question I ask before any project: what can I put in someone’s hands tonight? If the answer is “nothing, I need to scope first”, I scope on one page, not fifty-five.

And the manager reviews. A script you did not write, you do not know what it does not do. You try it on five cases before running it on everything. You open the site on a real phone. You do not trust, you verify, and you do it without offending anyone, which, with a tool, is finally easy.

These projects had been in my head for years.

AI did not build them. A team I lead in the evening did, with what I learned during the day.