AI is a Multiplier

TL;DR: AI can extend your capabilities and amplify your mistakes. Use it to accelerate your work, not outsource your thinking or judgment.

I’ve seen software engineers build incredible things in very little time. I’ve also seen software engineers ship confident nonsense just as fast.

AI created neither outcome; it made both easier and faster. Calling it a multiplier is imperfect—LLMs can provide knowledge and capabilities you don’t already have—but it captures the central risk: AI amplifies whatever you bring to the table. The less you know about a problem, the harder it is to distinguish leverage from confidently presented error.

If you know what you want, understand the problem, and apply judgment, skill, and experience, you can move at a pace that would have seemed impossible before. But if you switch off your brain and let the machine do the thinking, you can produce huge disasters in no time. The problem isn’t that AI suddenly makes people foolish. It’s that it gives old foolishness a cleaner interface, a faster feedback loop, and a much larger blast radius.

Let’s go back about 26 years, to the beginning of my career.

I did an apprenticeship after school. It was the first time I worked alongside other software engineers in a professional/corporate environment.

Most folks were using Windows and WAMP. A few of us were using Linux, but internal IT told us we were on our own because they couldn’t support it, which was fine by me.

One day, one of the other Linux users told me he was going to learn assembly because...

"Hackers use assembly to hack every system!"

— hacker in training

He went on to claim that since everything ultimately becomes machine code, you could use assembly to hack the network cards of every computer on the planet "without anybody ever knowing."

After my apprenticeship ended, I joined an agency that built websites for customers. Most of what the other developers and I did was add features to the company’s homegrown content management system (yes, by that time every agency had its own CMS).

One day, a project manager forwarded a customer complaint: German umlauts were wrong throughout the UI. They weren’t garbled by an encoding problem. Instead of "ä", the customer saw "ae"; instead of "Ü", they saw "Ue"; and so on. I checked and found the text had been committed that way. When the developer who committed it was asked what had happened, the explanation was apparently:

"Using a US-layout keyboard is what good engineers do!"

— good engineer

And should German umlauts ever be needed, there was a workaround: an email from another project manager containing all the German special characters, ready to be copied and pasted.

If someone told you those stories today, you’d either start learning assembly on a US-layout keyboard immediately... or you’d become skeptical of everything that person said from that moment on.

Those engineers weren’t stupid. They trusted confidence over evidence. Their mistakes are funny because they’re easy to spot, but in an unfamiliar domain, bad advice is much harder to recognize.

Long before LLMs, people outsourced their judgment to confident coworkers, Stack Overflow answers, blog posts, or the "Nigerian prince" offering millions for a small upfront fee. Now I watch people paste half-baked ideas into an LLM, get back a confident, well-formatted wall of text, and accept it without a second thought. The source of confidence has changed and more importantly, generating and acting on that confidence has become dramatically cheaper.

That does not make LLMs useless. Used well, the same machine can be incredibly valuable.

I started maintaining ext-parallel, a PHP extension I hadn’t written. Getting productive in an unfamiliar codebase can take months of reading source code, fixing small bugs, and adding tests to build a mental map. This time, I used an LLM to help me navigate the source. It could summarize the architecture, tell me where things lived, and point me to the relevant files. Its explanations gave me a map to verify against the source code. I became productive within weeks rather than months. It handled the volume. I still had to do the thinking.

At my day job, I added I/O profiling to the PHP profiler I maintain. This required hooking libc’s syscall wrappers, such as open(), read(), and write(), via GOT manipulation. I wrote the first few hooks myself, establishing the pattern. The rest was repetitive: the same template with different function signatures. So I handed that work to an LLM. What would have been repetitive, mechanical typing took minutes.

"This machine has no brain, use your own!"

— someone on the internet

I knew what to hook and why. I understood the GOT mechanism, the architecture, and the risks involved. The LLM handled the repetition and the searching. It didn’t replace my judgment or my thinking.

This doesn’t mean only experts should use LLMs. They can help people learn and make unfamiliar work accessible. But if you can’t yet evaluate an answer yourself, you need stronger feedback: read primary sources, run tests, ask for review, and make small, reversible changes. Judgment can be developed; it can’t be delegated.

The lesson from those old stories wasn’t "don’t learn assembly" or "don’t use a US keyboard" (I did learn x86 assembly, and I use a US-layout keyboard). The lesson was: confidence is not competence.

If you don’t bring your own judgment, you’ll always find something eager to replace it: a coworker, a tweet, a blog post, or a large language model. An LLM can accelerate your work and your learning. It can also accelerate your mistakes. Knowing which is happening remains your job.