We are generation zero

Three years ago, working without AI was not a choice: it was the default. Today it is one, and it calls for a justification. The shift happened fast, and without many people really deciding it.

We are the first generation to work with these tools. Not the first to use machines, obviously. The first to spend our days alongside software that produces text, code and decisions in our place. There is no previous generation to tell us how this goes: no hindsight, no established practice, no mistakes already made that we could learn from.

Generation zero. That is where this series starts.

I knew the machine learning that came before

Before LLMs, I worked on forecasting systems. I was not the one designing the models, that was the data scientists' job. I was on the operations side: running them, feeding them, delivering the results.

Regression models, trained on five to ten years of weather history. They forecast electricity consumption or production, the output of a photovoltaic installation for instance. And sales too: mineral water, ice cream, barbecue charcoal, anything whose demand follows the temperature. Training took a few hours on an office workstation.

Those models were useful, and good within their lane. But the lane was narrow and we knew where its walls were: we knew what data they had been trained on, what we asked them to predict, and by how much they were wrong. We measured the error, compared it to last month's, and scraped for accuracy points.

Above all, none of them ever surprised anyone. A model that forecasts ice cream sales forecasts ice cream sales. It does not start writing code one morning.

I spell all this out because it gives me a yardstick many commentators do not have. When I say that what followed is a break, it is not a newcomer's wonder. It is the comparison with what I used to run.

First shock: the level, then the pace

Two things struck me when LLMs took off, and the first is the level itself. Holding a conversation with a machine without catching it out after three sentences used to be a thought experiment. The Turing test was quoted as a distant horizon, almost as a curiosity from the history of science. It stopped being a horizon without anyone quite noticing.

But what marked me most is the pace. In classical machine learning, progress is counted in points scraped over months, on a task defined in advance: you know what you are trying to improve before you start. Here, capabilities appeared in steps, within months, on tasks no one had explicitly aimed at.

Software that improves faster than its own authors can describe what it is able to do — we had never seen that.

Second shock: the tooling

The second moment is the shift from chat to tool. Claude Code, Cursor, Aider, Codex, Gemini CLI: the names change, the principle is the same. It is called a harness, because it harnesses the model to the working machine.

As long as the model stays inside a chat window, it remains an interlocutor. I ask a question, I read the answer, I decide what to do with it. I am the only one touching the code. The harness removed that airlock: the model reads the files in the repository, runs commands, writes into it, re-runs the tests, reads what broke.

This is not a change of degree, it is a change of nature. We moved from a model we question to a model that acts. And the question that comes with it is no longer “is the answer correct”, but “am I really reading what it just did”.

Third effect: making itself indispensable

This is the one that strikes me as most important, and the one least discussed.

There was no decision. No day on which I weighed the pros and cons. The tool settled in through small touches, until my way of working was calibrated around it.

The direct result is measurable: I produce more code, and more features land in applications over the same period. But the deepest change is not there. It is in what I now undertake without thinking twice.

Writing documentation, for example. It was the task I postponed the most, and it is now done in pairs. Or those personal projects that stayed at the idea stage for years: they become proofs of concept in two hours. The entry cost of an idea has collapsed, and that changes what you allow yourself to start.

There is a trade-off, one I accepted without really choosing it: I no longer hold a precise picture of my own codebase. I know its broad lines, the application backbone, the sensitive areas. The detail escapes me. It is a new kind of stress, and I have not yet decided whether it is well placed.

And that is where the difficulty begins, for this series as much as for me. You do not judge coolly a tool you depend on. A developer whose productivity rests on an LLM is not a neutral judge of AI, and I am not going to pretend otherwise. I state the problem on the first page so the reader keeps it in mind on every line. It is a reason to write with method, not a reason to keep quiet.

What I hold against both current discourses

On one side, the advocates of AI without guardrails. They take vendor announcements as settled results, confuse a demonstration with a product, treat every model release as a historic event, and see in any attempt at regulation a brake applied by people who supposedly missed the point.

On the other, the catastrophist discourse, often hysterical, which piles up dangers without ever separating what has happened from what might happen, nor saying on what timescale, nor through what mechanism.

Let me be clear, because the confusion is easy: I hold nothing against anyone using these tools. I use them every day. What I am aiming at is the discourse that rejects rules in advance, not enthusiasm.

Both camps are symmetrical, and they share exactly the same flaw: they do not cite sources. The first repeats the seller's figures, the second repeats the fear. Neither gives the reader what they need to check and conclude for themselves.

I am not going to look for a midpoint between the two. Alternating good news and bad news to give an impression of neutrality informs no one. I would rather do something else: make every claim verifiable.

Where I write from

I am not an AI expert. I am a user.

What that forbids me: ruling on alignment, on the internal architecture of models, on what 2030 will look like. I will make no predictions.

What that allows me: to describe precisely what I see from my desk, to check what I am told, to read primary sources and report them honestly, including when they contradict what I would have liked to write.

A user who verifies is more useful than an expert commenting outside their field.

The method

It comes down to a few rules.

What comes next

Two things.

A timeline, first: a dated and sourced record of what has happened since 2017 and the paper that introduced the architecture behind today's models. Every entry links to its primary source and carries the date that source was read. It is online and will grow over time: building it means checking every entry one by one, and I would rather fill it slowly than fill it fast.

Then articles, one or two a month:

• what I see from my chair, in detail and with measurements;
• how to read a model announcement without being taken in, in either direction;
• the material cost: energy, water, compute, what is published and what stays opaque;
• employment: what the data shows against what is announced;
• documented harms versus existential risk. On one side what is documented today: data leaks, scams impersonating a voice or a face, false content in circulation, medical or legal advice gone wrong, emotional dependency. On the other, the hypothesis of a long-term loss of control. Two registers that get mixed up constantly, even though they call for neither the same evidence nor the same answers.

I do not know where this series will take me. That is rather a good sign: if I already knew what to conclude, there would be no need to check anything.