I'm an engineer, not a coder. Code was never the job.

One sentence comes back every time someone asks me what I do: I'm an engineer, not a coder. It isn't a pose. It's a definition of the job. Understand a real problem, choose the means that gives the best result, deliver it, then prove what it changed. Code is one of those means. Agents don't change that definition. They make it impossible to ignore.

What the market calls a “product engineer”

The term has been around for a few years. In 2019, Gergely Orosz described the “product-minded engineer”: a developer who cares about the product itself, and wants to know why decisions are made and how people use it. He gives them nine traits, among them end-to-end ownership of a feature and short validation cycles  (open receipt). PostHog turned it into a handbook: a product engineer talks to users, decides what to build, owns pricing, revenue and the experience, and does support. The job “goes beyond shipping code”  (open receipt).

I agree with all of it. My job is product engineering: I'm accountable for the impact on the business, not just for the code shipped. Still, my definition differs from the market's in two ways.

It starts from the engineer, not the developer. PostHog writes “a software developer who…”. I prefer the definition an engineering professor, Billy Vaughn Koen, gave in 1985: the engineering method is the strategy for causing the best change in a poorly understood or uncertain situation within the available resources  (open receipt). Not a word about code. Code, a workshop, a training plan, a spreadsheet, a team, a swarm of agents: these are resources. I take the one that gives the best result.

It demands proof. The market talks about product sense, empathy, taste. I care about those too, but a feeling doesn't tell you whether the change happened. I want a baseline before touching anything, a hypothesis, a definition of done, and a measurement someone else can redo. Numbers, yes, in the service of a story people can follow.

An engineer's CV lists technologies. Mine does too: Kotlin, Java, Fortran, Ada. That's the part that says least about what I do.

The same job since the steel plant

The job, constant

1. Understand
2. Choose the means
3. Deliver
4. Prove

---

The means, changing

1. 2005Developer, Steriacode: migrations, telecom services
2. 2008Project manager, steel plantuser workshops, 25 applications
3. 2013Change leader, steel plantLean plan, 35 facilitators, 4,000 people
4. 2015IT manager, Anaquaproduct roadmap, code, infrastructure
5. 2017Agile coach, AltranImpact Mapping, Event Storming
6. 2018Crafting lead, OctoTDD, code audits, training
7. 2021Senior engineer, scale-updesign, delivery, production
8. 2026Engineer with agentsI design, agents execute, I make them prove it

I started in 2005, fresh out of a generalist engineering school, as a developer and then junior team leader at Steria  (open receipt): migrating a combat-management system, services for telecom operators. At the steel plant, the job suddenly widened.

ArcelorMittal, 2008–2013. Project manager on the IT transformation of a steel plant: more than 50 applications, a €16M budget  (open receipt). I ran workshops with end users to start from their needs, and led the design and development of the interfaces: 7 people, 25 applications  (open receipt). There I saw an experienced operator hear that a machine was about to break, and trigger the emergency stop seconds before it broke  (open receipt). No specification describes that kind of knowledge. You have to go and find it on the floor. Toyota made it a principle: go and see for yourself to understand the situation  (open receipt).

The improvement plan, 2013–2014. Not a line of code. A Lean and Theory of Constraints plan for continuous casting, cost-deployment matrices that put a price on every loss so we could pick the actions that paid most, a target of €20M a year, 200 workshop days  (open receipt), and 35 facilitators trained for 4,000 participants  (open receipt). The product was a plan that 4,000 people would adopt. The means was training. Same job.

Anaqua, 2015–2017. IT manager: the product roadmap, development across the whole suite, the infrastructure (€300k)  (open receipt). Three jobs in one job description.

Altran, then Octo, 2017–2021. As an agile coach, I facilitated Impact Mapping and Event Storming workshops  (open receipt). Gojko Adzic's Impact Mapping  (open receipt) starts from the goal, then the actors, then the changes in behaviour you expect, and only at the very end the deliverables. It's still the order I think in. At Octo, I ran code audits and taught TDD and Clean Code  (open receipt). Code quality isn't an end in itself. It's what lets you change direction fast when the measurement says you got it wrong.

Since 2021, I've been a senior engineer  (open receipt) at a Paris scale-up: I design, I ship, I run what I ship. More than fifteen years of changing means, not jobs.

Why AI confirms the job instead of replacing it

If the job were typing code, AI would replace it. PostHog says it bluntly: anyone can pay $20 for a machine that spits out code that works well enough  (open receipt), so code on its own no longer creates an advantage. “But here's the good news: it never was.”

Anthropic surveyed 132 of its engineers and researchers in August 2025  (open receipt). Many describe a role shifting from writing code to managing AIs, and everyone is becoming more “full-stack”. They also name the trap: the paradox of supervision. Supervising Claude takes exactly the skills that atrophy when you hand it too much.

I wanted people to experience that trap rather than hear it explained. In June 2026, in two days, I designed a workshop, “AI = Augmented Engineer / Alienated Engineer”, run on 4 June at Alpes Craft  (open receipt). One codebase, a Medium clone, and two phases. First, work through a backlog longer than the slot by delegating to the agent. Then take what was delivered and attack it from every angle with AI, making the call yourself at every agent output.

In between, an individual quiz separates what I believe from what my code does. One question asks where a published article becomes visible. The codebase's tag system saves nothing: no article is ever reachable by tag  (open receipt). Anyone who ticks “by tag” has assumed the product works without checking.

That morning, less than three hours before the start, I typed the workshop's core idea to my agent: “we're going back to our job as engineers, which is to understand problems and find innovative solutions to them. We very often move to a meta position […] and if we use that to learn along the way, we become superpowered ourselves”  (open receipt). The design document puts it in one line: producing gets cheaper and cheaper, understanding becomes the scarce resource.

Today, I hardly type code any more  (open receipt). I design, I steer agents, I demand proof, I decide. That's not a gap to apologise for. It's the same job with a longer lever. Experience without agents is slowness. Agents without experience are volume without direction.

Doing without agents today would be a mistake. Believing they'll build a product on their own, end to end, is another. The human keeps the decisions that take judgement, right down to “something feels off”. Agents take the implementation. My job is to build the system that makes that possible.

The approach, in six moves

With or without agents, I follow the same loop.

1. Go to the source of the need. A user, a session, a complaint, a log. Not the summary someone gives me of it.
2. Write down the baseline before changing anything. Without it, no improvement can be shown.
3. State a hypothesis and a definition of done. Done is something you can observe at the user's end, not a closed ticket.
4. Choose the cheapest means that does the job. Often a script rather than a model. Sometimes a workshop. Sometimes a deletion.
5. Ship small, measure, start again. One hypothesis per experiment, so that a failure points to its cause.
6. Prove it. A number says where it comes from and how to recount it.

What the sixth move teaches feeds back into the first.

I apply the rule to myself. Every claim on this site carries a receipt: the source, the method, the date, how strong the proof is  (open receipt). An unknown receipt id fails the build, and the site doesn't deploy  (open receipt). The career facts in this essay are marked “declared”: they're my word, and the receipt says so (why receipts).

How to apply it

1. Before the first line of code, write down the baseline. A number, a screenshot, a failing test. If you can't write it, you don't yet know what you're changing.
2. Write “done” as a fact at the user's end. “A new sign-up publishes their first article in under two minutes”, not “the PR is merged”.
3. List three means before choosing one, including one without code. A setting, a script, a doc page, a deletion. It wins more often than you'd think.
4. Go and watch usage every week. A user session, the support queue, an hour next to someone using your tool.
5. With agents, delegate the execution, never the understanding. My workshop's test: can you say what the code shipped this week does without rereading it? If not, you shipped volume, not a result.
6. Give your own numbers a receipt. In a review, a sprint demo, a CV: where the number comes from, and how someone else can recount it.

The title changes from company to company: product engineer, staff, lead. The job doesn't. Understand, design, deliver, run, measure: the whole thing, not one piece. Agents have made the middle piece almost free. All the rest remains, and that's the job.