When the machine does the typing

Welcome. This blog is born as my logbook: the place where I record the course I am steering, what I discover and what goes wrong, with the idea that over time it becomes my personal knowledge base in the open.

I have spent over a decade building backends, automating processes and keeping critical systems alive in production. I learned an enormous amount and almost none of it got written down. I want to fix that in public, because explaining something is the best way to confirm you truly understand it.

And I cannot think of a better moment to set sail.

A unique moment

Generative AI (large language models and the agents built on top of them) is upending the way code has been written until now. In April 2026, Google’s CEO said that 75% of the company’s new code is AI-generated, up from a quarter in 2024. Read that figure carefully: it is self-reported, it describes one company with unusually good internal tooling, and “generated” is not the same as “shipped without anyone looking at it”. Even heavily discounted, the direction is hard to argue with. We have gone from assistants that autocomplete lines to agents that research, execute and iterate on whole tasks, and verification is the part that still lands on you.

Which is exactly why skepticism is worth keeping. A randomized trial by METR had experienced developers work on repositories they knew well and measured them 19% slower with AI, while those same developers estimated afterwards that it had made them 20% faster. The distance between those two numbers is what I take from the study. METR ran it again with more developers and newer tools: the slowdown shrinks without turning into a speedup, and the error bars are wide enough to go either way. Nobody has settled this. What is clear is that feeling faster is not evidence of being faster. The tool does not replace judgment: it amplifies it when it exists and exposes its absence when it does not. Learning to use it well is worth the effort, and a good part of this logbook is about that.

From implementers to engineers

For years, a large part of our job was translating decisions that had already been made into code. We were, above all, implementers: people who turned specifications into syntax.

When the machine does the typing, the value moves up a level. The work starts to look like what engineering was always supposed to be: understanding the problem, designing, weighing the tradeoffs, deciding what to build and why, and verifying that what was built actually works. And a second effect matters just as much: we get time back for the tasks that are also engineering and always got postponed, such as measuring, documenting, simplifying or teaching. AI is not taking the craft away; it is giving back the part that deadlines had stolen.

I have felt this shift first hand. I went from autocomplete guessing the end of a line to features that practically write themselves and get verified against tests the agent also writes. Whether that is enough, and how far it holds, is the question that occupies me most right now and the one that will come up here most often.

What you will find here

I will write about what I build and what I discover, with generative AI as the thread running through it:

1. Engineering with agents: how I design, supervise and verify what the models build.
2. LLMs in practice: which model I pick, how I iterate a prompt, and the traps you only find by using them for real.
3. Backend in production: performance, reliability, and the boring decisions that prevent incidents in the middle of the night.
4. Process automation: what is worth delegating to a model and what is better solved with plain old code.

No fixed schedule and no filler: I will publish when I have something genuinely worth sharing. If any of this resonates, welcome aboard.