AI Doesn’t Replace Engineers. It Removes Blank Pages

It is 21:40 on a Tuesday. There is a proposal due Thursday, and I know exactly what it needs to say. I have known since the discovery call. I could explain the whole architecture out loud, right now, in four minutes, including the bit where the customer’s licensing makes half of the obvious answer a bad idea.

And yet the document is empty. The cursor is blinking. I have made tea. I have checked whether the Proxmox trial box is still up, which it is, and which was never in any doubt. I have straightened the desk.

This is not writer’s block. Writer’s block implies I do not know what to say. What I cannot do is start, because starting means committing to a first sentence, the first sentence commits me to a structure, and the structure is the bit my brain treats as expensive. The typing was never the problem. I type quickly.

Every engineer knows this and almost nobody names it. The runbook nobody has written. The script you have been meaning to knock together since March. The handover doc for the thing only you understand, which you will absolutely write, next week, definitely. The knowledge is all there. The activation energy is missing.

The expensive part of knowledge work was never the production. It was the starting. AI has largely killed the blank page, and that is enormous, and it is not remotely the same as killing the engineer.

What actually got automated

I use Claude every working day: coding, documentation, proposals, research. I am neither a booster nor a sceptic, both of which have become identities rather than positions. I have just been doing this long enough to have opinions about where it earns its keep and where it quietly wastes my afternoon.

What changed is that the cost of a first draft has gone to roughly zero. That is the whole revolution, and it is enormous, because an astonishing proportion of the work I have avoided over twenty years was avoided at the blank-page stage, not the difficult stage. Not because it was hard. Because it had not been begun.

What did not change is the part that was always the job: knowing whether the draft is any good.

Turning “write” into “correct”

The biggest win, by a distance, is documentation.

Documentation is the purest form of the blank-page problem. Everyone knows they should do it. Nobody wants to start. It has no deadline, so it loses every prioritisation contest it enters, until someone leaves and takes the only copy of the truth with them.

What AI did here is not “write it for me”. It changed the task from write the runbook to correct the runbook, which is a completely different psychological job. Writing from nothing needs structure, decisions and momentum. Correcting needs only that you notice when something is wrong, which an experienced engineer cannot switch off. Show me a wrong runbook and I cannot stop myself fixing it. Show me an empty document and I go and make tea.

So I now document things I would previously have kept in my head. The Caddy config and why it is arranged the way it is. The order you have to bring the lab back up in after a power cut, which I have rediscovered by trial and error more than once. It all goes down now, because going down costs almost nothing. That is what makes building a second brain viable rather than aspirational, and why the point is building knowledge rather than producing documents. The document was only ever the tax on keeping the knowledge.

The caveat is not small. An AI-written document nobody has verified is worse than no document at all. Not equivalent. Worse. An empty wiki page is honest about its emptiness. A confidently-worded runbook carries authority it has not earned, and someone will follow it at 3am, tired, in no position to be sceptical. You have not saved them time. You have laid a trap and signed it.

So the rule is simple. If my name is on it, I have read every line and I believe every line. AI gets a document to 90%. It cannot supply the belief.

The argument the model cannot make

Presales taught me something deflating: most of a proposal was always reassembly. The same architecture, explained again, for a different customer. The same three paragraphs about resilience, the same diagram with different labels, the same “why this and not that” section rewritten from memory because you could not find the last one.

AI does the reassembly beautifully. That work is gone and I do not miss it.

What it cannot do is know which argument this customer needs, because it was not in the room. It did not hear the IT manager go quiet for a second too long when someone mentioned the migration that went wrong. It does not know that half the obvious recommendation is politically impossible for reasons nobody will ever write down.

That is not a limitation you fix with a better prompt. That is the discovery call, and the discovery call is the actual product. Everything downstream of it is formatting.

The danger here is the inverse of what people worry about. Everyone frets about AI producing obvious rubbish. Obvious rubbish is harmless; you see it and you bin it. The real risk is a proposal that is fluent, confident, professionally toned and subtly wrong about the customer. Because it reads well, nobody catches it. A clumsy proposal that is right gets fixed in review. A polished proposal that is wrong gets signed.

We have spent our careers using fluency as a cheap proxy for competence, and that proxy has just been broken. The route from proposal to production depends on the proposal having been true.

Coding: it types faster than I do

AI is excellent at boilerplate: the argument parser, the Dockerfile, the systemd unit, the error handling I would have written badly anyway. It is excellent at glue, the unglamorous code that gets thing A talking to thing B. It is excellent at the shape of a script, which matters more than it sounds, because a skeleton is not a blank page. It is excellent at a language I half-know. And it is excellent at remembering an API I have used twice, forgotten, and would recognise instantly if shown. Not one I have never used, which is more dangerous.

It is unreliable wherever the correct answer depends on context it cannot see. My actual environment. My actual data. The weird legacy constraint that makes the textbook answer wrong. It does not know the NUCs run Hyper-V and the OptiPlexes are the Proxmox trial, and unless I tell it, it will confidently pick one.

The pattern that works: I know what I want, and it types faster than I do.

The pattern that fails: I ask it to make a decision I have not made.

Arrive with the decision taken and AI is a superb typist. Arrive vague, hoping it will supply the judgement you are missing, and you get something plausible, accept it because it looks fine, and find the problem three days later. The model never pushes back. It never says “you have not thought about this”. It gives you exactly what you asked for, including when what you asked for was incoherent.

This website was substantially built the way I am describing. Hugo, the theme, the deployment, the endless fiddly bits of a static site, all of it moved faster because the first version of everything arrived instantly and I spent my time correcting rather than starting. I wrote that up in building krishaynes.co.uk. The AI did not build it. It removed the blank pages, and then I built it.

Which is why every infrastructure engineer should still learn Python, more urgently now, not less. You cannot review what you cannot read. If you do not understand the code, you are not using an assistant. You are trusting a stranger.

Research, and the failure distribution from hell

The best thing an LLM does, by some margin, is be a fast, patient, non-judgemental explainer of a domain you are new to. It does not sigh. It does not make you feel stupid for asking what a register is for the third time. It answers the embarrassing beginner question at 23:00 on a Sunday, and the social cost of asking a human is one of the great hidden taxes on learning anything as an adult with a reputation to protect.

Working out how to talk to my inverter over Modbus, I went from knowing nothing about industrial serial protocols to a working mental model in an evening. Not because the model handed me answers. Because it let me ask forty stupid questions in a row, quickly, and each answer let me ask a better one. Same story with quantisation and context windows and what actually fits in VRAM, which became picking a local model.

And now the poison in the well.

It is confidently wrong about niche technical detail precisely where you are least equipped to notice. That failure distribution is the worst one imaginable. In the domain you know well, you catch every error instantly, and the model is reliable there anyway. In the domain you have just entered, with no priors and nothing to check against, it is at its least reliable and you are at your least capable of telling.

You can trust it most exactly where you need it least.

That is not a reason to stop. I use it constantly and it is worth every minute. It is a reason to hold the output as a map rather than a fact. It gets me to the right region of the problem and the right vocabulary. Then I check the register map in the manufacturer’s actual document, because the model will invent a plausible register address with total composure and be wrong by four.

Validation is the job now

If you take one thing from this article, take this section.

The workflow that works is generate, then verify. And the verification is not a nice-to-have bolted onto the end of the real work. It is the work. Generation got cheap, so the balance of my day has shifted into checking, and I have had to make peace with that, because checking does not feel like producing.

Here is the rule of thumb I have arrived at. It has served me better than any prompt technique I have ever read.

Never accept output you could not have written yourself given enough time. If you could not have written it, you cannot review it. And if you cannot review it, you are not engineering. You are gambling with extra steps.

That sounds restrictive. In practice it is liberating, because it tells you exactly where the line sits. Boilerplate I could have written and did not want to: accept freely, it is a typing service. A clever algorithm in a language I do not really know, solving a problem I do not really understand: reject, or go and learn it first, because I cannot tell the good version from the disastrous one.

The habits are unglamorous and non-negotiable.

Run it. Obvious, routinely skipped. Code that has not been executed is a hypothesis. I have watched myself skim a forty-line script, think “yes, that looks right”, and commit it, when I would never have done that with a colleague’s pull request. The fluency disarmed me. It disarms everybody.

Check the thing exists. The API, the flag, the parameter, the config key, the module. Not “does it look like it exists”. Does it exist. --help is free. The documentation is free.

Check the citation actually says that. If it has cited a source, open the source. A depressing proportion of the time the source is real, the quote is plausible, and the source does not say the thing.

Be most suspicious of the confident specifics. Version numbers. Exact flag names. Parameter orders. Obscure API signatures. The moment the output gets precise about an arbitrary detail is the moment to slow down, because that is exactly where the hallucination lives, and the precision is what makes it credible.

Verifying takes real effort and provides no dopamine whatsoever. Generation feels like progress. Verification feels like admin. That gap is where careers will quietly go wrong over the next few years, and the people it happens to will not notice it happening.

What a hallucination actually is

The word has become a synonym for “the AI lied”, and that framing sends people to entirely the wrong defensive posture.

The model is not lying. Lying requires knowing the truth and choosing otherwise. It is not confused either; confusion implies an intent to be right that has gone astray. It is doing exactly what it was built to do, which is produce the most plausible continuation of the text so far. Plausible-and-wrong is not a malfunction. It is the natural shape of the failure, because plausibility is the only thing being optimised.

Hold that in your head and you can predict where it fails, which is the most useful skill in this business.

It fails where the truth is arbitrary rather than derivable. Nothing in the structure of the world determines whether a flag is --recursive or --recurse, or that a feature landed in 3.4 and not 3.2. A citation’s page number, an obscure API’s argument order, whether a capability exists in a given product version: these are facts you can only know by having seen them, and where the model has not reliably seen them it generates something with the right shape. The right shape is what fools you.

It fails least where there is strong regularity. Structure. Explanation. Idiom. The form of a well-built script. Why a thing works the way it does.

So: trust it on shape, distrust it on specifics. Trust the explanation, verify the version number. Trust the architecture of the script, check the API call. Knowing where the failures cluster is the whole difference between someone productive with these tools and someone badly burned by them. It only requires giving up the idea that the model is a knowledge base. It is a plausibility engine.

The bottleneck moved, and I do not know where the next lot get it

Everything AI produces has to be accepted or rejected by someone, and that someone needs to have been in the room, understood the constraint, and known what “right” looks like for this customer, on this estate. No version of this technology removes the accept-or-reject step, because that step is where the responsibility lives, and responsibility does not delegate to a probability distribution.

The bottleneck used to be production. It is now discernment.

And discernment is not something you can be handed. You accrete it slowly, by doing the work, getting it wrong, and carrying the consequence. I know that C:\Windows\Installer is not junk because I deleted it and broke a backup server. I know which questions decide a project because I have failed to ask them and watched the thing quietly die a year later, which is most of the argument of why most AI projects fail. Every scrap of judgement I have was paid for in first drafts that were wrong.

Which brings me to the thing I would rather not land on.

If the first draft is free, and juniors never have to write one, where does their judgement come from?

I genuinely do not know, and none of the confident answers convince me. “They will learn by reviewing” assumes you can review without ever having produced, and I do not think you can; review is pattern-matching against your own scar tissue, and you do not get scar tissue from reading. “It is the same as calculators” is comforting and wrong, because a calculator cannot be fluently, plausibly wrong about your customer.

I have twenty years of blank pages behind me and I now get the benefit of skipping them. The people entering this profession get the benefit without the twenty years. That might be fine. It might also be that we have removed the exact friction that manufactured the judgement, and we find out in a decade.

I am suspicious of anyone who claims to have that one solved, in either direction. An honest “I do not know how we fix that yet” is a better place to stand than a confident non-answer.

What to actually do on Monday

The framing that has held up best for me is that AI is an amplifier. It multiplies whatever judgement you already have, in both directions. Good judgement, amplified, is extraordinary to have on your desk. Bad judgement, amplified, produces confident, fluent, well-formatted disaster at a speed you could never have managed unaided.

Three things that are actually usable.

Use it to start, never to decide. The blank page is its territory. The decision is yours. The moment you notice you are hoping the model will resolve an ambiguity you have not resolved, stop, and go and resolve it.

Verify anything you would be embarrassed to get wrong. Not everything needs the same depth; the throwaway script does not. The runbook with your name on it, the proposal going to a customer, the config touching production: every line, and be most suspicious of the parts that sound most certain.

Watch for the moment you stop checking. There will come an evening, late, when you are tired, the output looks fine, and you cannot quite be bothered to verify it. You accept it anyway. That is the moment. Not a dramatic failure. A small, quiet erosion.

Because the instant you accept output you have not checked, on the grounds that it looked right and you were busy, you have stopped being the engineer.

You have become the customer.