The Machine That Finishes My Sentences

A Strange New Silence

There is a particular quiet that has entered my work over the last year.

I open the editor. I describe what I want. And something else writes the first draft.

It is fast. It is often right. And it has changed the shape of my days in a way I am still learning to name.

For most of my life as an engineer, the hard part was the doing. Getting the syntax right. Remembering the API. Wrestling the thing into existence line by line. The struggle was the work, and the work was the proof.

Now the struggle has moved somewhere else, and I keep reaching for it in the old place.

What I Actually Do Now

I have built three tools that are, in one way or another, about working with agents. A CLI that hands coding sessions between them without losing context. Another that stages and commits and opens pull requests from what it reads in the repo. A third that notices when the code and the docs have drifted apart and proposes the patch.

So I am not a skeptic. I built the scaffolding. I use it every day.

But building those tools taught me something I did not expect: the bottleneck was never typing.

The bottleneck was knowing what should exist.

When you hand a task to an agent, you find out very quickly how well you understood it. A vague instruction produces confident, plausible, wrong code. A precise one produces something close to what you meant. The model is a mirror held up to the clarity of your own thinking, and most of the time the reflection is not flattering.

That is the part nobody warned me about. The work did not get easier. It got more honest.

The Fear Under the Question

There is a question I hear a lot, usually late, usually from someone who is not really asking about tools.

If it can write the code, what am I?

I have asked it myself. Usually at two in the morning, usually after a day where the agent did in ninety seconds what would have taken me an afternoon in my first year.

And I think the fear is real, but I think it is aimed at the wrong thing.

The fear assumes that what made you valuable was the typing. That the craft lived in the keystrokes. But I do not think anyone who has shipped something difficult actually believes that. The keystrokes were never the hard part. The hard part was the decision underneath each one. Why this abstraction and not that one. What breaks in eighteen months. What the person on the other end actually needs, which is almost never what they asked for.

None of that got automated. If anything it got exposed, because there is now less noise between the decision and its consequence.

Where the Craft Went

I have started to think of it like this.

Before, my craft was distributed across everything. A little of it in the naming, a little in the structure, a little in the actual mechanics of getting it working. It was diffuse enough that I could feel skilled just by being busy.

Now it has concentrated. It sits in fewer places, and those places matter more.

It sits in the taste to look at generated code and know, without quite being able to explain it yet, that this is wrong. Not broken. Wrong. Wrong in the way that will cost you in four months.

It sits in the discipline to read what you did not write. This is the one I underestimated. It is genuinely harder to review code than to write it, and the incentive to skim is enormous when the tests pass and the diff is green. Every serious mistake I have made this year came from accepting something I did not fully read.

And it sits in the architecture. The agent will happily build whatever shape you point it at. It has no opinion about whether that shape should exist. That opinion is still yours, and it is now almost the entire job.

The Thing I Am Actually Worried About

So I am not worried about being replaced.

I am worried about something quieter: that I will stop building the muscle that lets me tell good from bad.

Because here is the uncomfortable loop. My judgment came from years of writing bad code and living with it. From shipping the wrong abstraction and maintaining it for eighteen months and slowly, painfully, learning why it was wrong. The taste was purchased with time and consequence.

If the machine writes the first draft forever, where does the next engineer buy their taste?

I do not know. I genuinely do not. I think about it more than I think about job security.

What I have landed on, for now, is a rule I try to hold. When something matters, I write it myself first. Not because I am faster. I am not. But because the act of writing it is how I find out what I actually think about it.

Then I let the agent do the second version, and I usually keep the second version. But I needed the first one to know what I was looking at.

Not a Tool, Not a Colleague

People keep trying to name the relationship. Is it a tool? A pair? A junior engineer?

None of those fit.

A tool does not surprise you. A colleague has stakes. A junior engineer learns from the correction you gave them last week.

This is something else. It is a very fast, very well read stranger who has no memory of yesterday and no consequences tomorrow, and who will state a wrong answer with exactly the same confidence as a right one.

The right posture toward that is not trust and not suspicion. It is attention.

Which is, I think, the same posture that good engineering always asked for. We just used to be able to get away with less of it, because the slowness of typing forced a kind of accidental care.

That accident is gone now. The care has to be chosen.

What I Keep

At the end of most days, I look at what got built and I ask myself a simple question.

Did I decide this, or did I just accept it?

The days where the answer is clean are the days I feel like an engineer. The days where I have to sit with it are the days I learn something.

The machine finishes my sentences now. That is fine. That was never the part that was mine.

The sentence had to be worth finishing. That part is still on me.