Me and AI: the manual that did not exist

Now and then I hear that everything I do is AI-generated. It sometimes irritates me, though I understand where the suspicion comes from. A tool and the person using it are two different things, and using a good tool well is a skill.

Yes, AI writes a large share of my code. I am writing this to say what happens around it, and why that is the part the result depends on.

Where I come from

I graduated as a process engineer in 1986 and started the same year on information systems for process industries. The work has been the same ever since: collect data, and try to work out something useful from it. First from production processes, then telecom networks, then immersive computing, and most recently language models, the AI programs that produce text. As a full-time programmer I wrote an application within a network management system that kept the inventory of a network's base stations: their hardware, firmware and configurations. I wrote it alone and in full, mostly in C++, and it has run in the networks of hundreds of operators for decades. I still write code almost every day. I am also an adviser to a company in the AI field. This article does not deal with that company in any way.

As an engineer I believed in manuals. A good manual lists the inputs, the outputs and the failure modes, and the machine behaves as the manual says. A valve opens at three bar (about three times atmospheric pressure), not because it wants to please anyone.

AI is the first tool in my career that has no such manual. It behaves well most of the time and, now and then, wrongly with total confidence. So I had to write the manual myself.

The rules I wrote

In one of my projects, a production pipeline for audiobooks and books, I have written down the rules I use when working with AI. They are not theory. They are near-misses, recorded afterwards. I will pick six, the last of which concerns this site.

1. Look at what has already been done. I use two computers, and in September 2026 their work drifted apart so far that a day's changes on each side had to be untangled by hand. The rule that came out of it: the first act of every working session is to bring this machine up to date with the other one's changes and say aloud what has happened there. An AI does not, by default, remember yesterday, so the memory has to live in files.

2. The file is the authority, not the note. Notes record what was true when someone wrote them. When I ask about the state of the book, the machine has to look in the files, not answer from the last conversation or from its own recollection. The same principle runs through this site: the dates in an article on regulation are not checked against a model's memory but against the European Commission's own page.

3. Decisions are recorded, and a person makes them. The project has a file for the decisions that history does not show: which machine, on which day, and who decided. The machine proposes, I say yes or no, and the answer goes in the log. When someone asks three weeks later why something is the way it is, the answer is there.

4. Nothing irreversible without permission. The machine may not rewrite history that has already been saved, or delete anything that cannot be brought back. If something stops, it has to say so rather than push harder.

5. Do not believe a single reader, however sure it is. I have manuscripts read by several AI agents (programs that carry out a task on their own), each given a different role: an editor, an audiobook narrator, a librarian. They are the same language model in different roles, so they are not independent of one another and their mistakes can be the same ones. Agreement catches slips, but it proves nothing. That is why a critical claim is always checked by me against the primary source. On this site every article goes through a reading circle of the same kind, a round of feedback from several readers, before it is published, this one included.

6. The site has its own limits. I do not write about the company I advise. On markets and funding I stay at the level of public figures, and I give no investment advice or forecasts about named companies. If a topic touches my affiliation, I say so in the article itself.

Beyond these there are smaller ones of the same kind. When I chose sound effects for an audiobook, I let my ears decide, not a marketing promise. I tried fifteen AI-made sounds against a free sound library, with the levels matched, and the library won all fifteen pairs. It was one listener and not a blind test, but it was enough to keep my opinion honest.

How I take responsibility for what the result says

Saying "I am responsible" is easy. On this site it means four things. The AI writes a draft, and the draft goes through a reading circle before it reaches me. I get a report with the findings gathered, and corrections are made only once I have approved them. Before publication a program checks that the site works technically, but I check the content myself. And every figure, date and source is checked against the original and not against the machine's memory. If I do not understand what the machine has done, I do not publish it.

What the numbers say and what they do not

Someone will want numbers, so here they are. My work is stored on GitHub, a service where program code is kept in projects called repositories. I have 105 of them, of which 7 are public and 98 private. The account dates from 2014, while I started programming in 1986, so a large share of my work is not there at all. For the 75 repositories where the service identified a main language, 38 are TypeScript, 17 JavaScript, 7 Jupyter Notebook, 6 Swift, 4 Python and 3 C++.

My "contribution count" for the past year is 3,129. It counts activity, such as saved changes and proposed changes, not lines of code, and I do not offer it as proof of anything. It does not say who wrote which line, and the profile does not show a total number of lines. Someone who works with AI may save more changes, so the figure says more about how I work than about how much I do. The numbers say little beyond the fact that there is continuous activity on the account.

The more decisive question is a different one: who decides what is built, and who answers for it working?

Who does what

The examples on this site are built in three parts: what the machine does, what the human does, and where it fails. The same split works in my own work.

The machine writes quickly, does not tire of repetition, and finds mistakes I would not notice. It is an excellent helper for anything that is broad, routine, or needs a whole file held in mind at once.

I decide what is built and why. I recognise when the machine is confident and wrong. I answer for what the result says. In the book I am writing, which is about who I am, the memories and experiences are my own, though some scenes are disclosed in the book as composites, and AI is a reader and a helper. Customer names and contract values are not published, and that is a rule the machine may not reconsider on its own judgement.

It fails when either side forgets its role. If the person trusts the machine blindly, errors pile up. If the person gives the machine nothing to do, the person loses what the machine is genuinely good at.

Nor do I claim that AI makes me faster. The research group METR measured in 2025 that experienced developers took 19% longer on tasks when they used AI, while believing afterwards that they had been about 20% faster. The result covered sixteen developers working in their own familiar codebases, with early-2025 tools. METR now believes a speed-up is likely, but regards its newer data as unreliable. The lesson holds all the same: my own impression is not a measurement, which is why I rely on rules and checks.

Why this is not a new problem

The question of responsibility is not new. When a person answers for the work, the question is always who checked it. Here AI is closer to an intern than to a compiler, the program that turns code into machine language. A compiler behaves predictably, but an intern's work has to be reviewed, however quick and fluent the explanations. The machine can do a great deal, but the result is always in someone's name.

So what matters is not whether the machine did it. What matters is whether someone checked, and whether the checking is built into the work or left to goodwill.

In forty years I have seen several waves, each of which was, in its day, the one that would change everything. What they share is that the name of the tool changed and the responsibility stayed where it was.

What has to be disclosed

This text, too, was made together with AI: it read my material, proposed the structure and wrote a draft, and I decided what it claims. After that it went through the same kind of reading circle as every other article. Uncovering AI is a personal project, not the website of any company.