The useful kind of lazy
First, a short defense of the word, because laziness has a bad reputation.
There is the plain kind, where someone avoids the work and nothing gets done. And there is the constructive kind, where someone is willing to work very hard once, exactly so that the task never has to be done again. That second kind built most of the comfort around you. The dishwasher. The TV remote. The suitcase with wheels, which somehow only got invented in the 1970s, after we had already been to the moon.
Biology is on our side here. We are wired to save energy. For most of human history, wasting effort was dangerous, so the brain learned to reward the shortcut. A lot of what we call innovation is just this instinct, given some tools and a deadline.
Programming is this instinct turned into a profession.
The ladder of not writing code
You can read the whole history of programming as one long, patient project to write less code.
In the beginning, people wrote machine code and assembly. Every instruction spelled out, every memory address managed by hand. That was slow and painful, so we built high-level languages and let the compiler do the dirty work. Then we stopped solving the same problems over and over: package managers arrived, and if you needed to format dates or parse a file, you typed one install command and pulled in code written by a stranger on the internet.
And here I have to ask an honest question. When you install a dependency, do you read all of its source code?
Not all of it. Almost nobody does. You read the documentation. You skim the parts that matter, glance at the stars and the date of the last commit, test that the output is right. Then you ship it. Reading every one of the tens of thousands of lines underneath would destroy exactly the time saving that was the point.
So for two decades now, most software has been built mostly from code that nobody in the building has read in full. We are fine with it. It works.
AI is a dependency generated on demand
Now look at AI coding through that lens.
When I ask an AI to write a function, what do I actually get? A piece of code written by someone else, which I check on the surface, test on its outputs, and, for the everyday stuff, wire in without reading every line. That is a dependency. The only new part is that it did not exist five minutes ago. It is a dependency generated on demand, for my exact problem.
It changed my role too. I describe what I want, I review what comes back, I wire it into the larger system. Less typist, more editor. These days a large share of the code I ship is code I did not type. I directed it.
If that sentence makes you uncomfortable, I understand. But notice that the process did not start with AI. We have been outsourcing the writing of our own programs for decades, one abstraction at a time. AI just added one more rung to a very old ladder.
So why don’t we trust it?
Why do we trust a library written by an unknown person more than code generated by a machine? Because we clearly do. The criticism of AI coding is loud right now, and I do not remember anything that loud when dependencies became normal.
I can find three honest reasons.
The first is community validation. Open source has an old saying: given enough eyeballs, all bugs are shallow. When you pull in a popular library, you are not really trusting the author. You are trusting the crowd. Thousands of people use it, so someone must have looked, someone must have filed the bug, someone must have fixed it. That is tribal trust, and it runs deep in us. An AI-generated snippet has an audience of exactly one. You.
The second reason is practical, and it is fair. A library is deterministic. Same input, same output, every single time, until someone changes the code. AI is probabilistic. Ask it twice and you may get two different structures. Sometimes it invents a function that does not exist and presents it with full confidence. A library never makes up an API on the fly. This part of the distrust is earned, and pretending otherwise would be dishonest.
The third reason is the hardest one to say out loud. A library never threatened anyone’s job. A library is a hammer. Nobody ever felt that jQuery would replace them. AI does not behave like a hammer. It behaves like a colleague. It does a part of the thinking, not just a part of the typing. And I think some share of the resistance is not a technical judgment at all. It is the quiet question underneath: if the machine writes the code, what am I for?
We have been here before
One piece of history worth remembering. Open source code also met serious resistance at the start. In the 90s and early 2000s, big software companies treated outside code as a threat and kept it far from their systems. Letting code written by unknown people on the internet into your product sounded reckless. It took ten or fifteen years for that to flip from reckless to default.
I think AI coding is standing at the start of the same trust curve. And the curve tends to play out the same way every time. You resist. Then a deadline arrives, you are tired, and you try the tool. Two days of typing turns into an hour of reviewing. The colleagues who use it ship faster, and the market notices. Slowly it becomes normal, and the fear does not get refuted. It just evaporates. The same way you now run an install command without blinking.
The line I still draw
I should be honest about one thing, because “I don’t read it” can sound like “I don’t care”, and that is not what I mean.
There is a line, and where you draw it is the whole game. Mario Zechner, who writes his own coding agent, said it in a recent talk in a way that stuck with me: read the critical lines yourself, every one of them. Hand the machine the boring parts, the boilerplate, the throwaway scripts, the bug reproductions, the research. Do not hand it the core logic your business stands on, or the code that touches money, passwords, or other people’s data.
The old dependency rule worked the same way, we just never said it out loud. I never read the source of a date-formatting library. But the function that processed a payment or checked a password, I read that line by line, every time. Trust the crowd for the plumbing. Read the part that can hurt someone yourself.
For me the line tracks the environment. Most of what I build are internal tools, in a sandbox where the worst case is a broken script. There I let the agent off the leash, I experiment, I ship code I only skimmed, because the result is the whole point and nobody gets hurt if it takes a wrong turn first. The moment the same work touches a client, a user, or money, it flips. Then it is not only the result that matters but how it got there, and I slow all the way down to reading every line.
There is a quieter reason too. The friction of reading is also how the system gets into your head. Give all of it away and you ship fast for a month, then wake up maintaining a codebase you never actually understood.
The part that was always yours
AI code will not become accepted because the models turn perfect, or because we suddenly become trusting people. It will become accepted because, over the long run, we are too rational, and yes, too lazy, to keep taking the slow road on purpose. That is not a weakness of our character. It is the same instinct that put wheels on the suitcase.
I still review what the AI writes, lightly when it is a sandbox toy and line by line when it can hurt someone, exactly as I always treated a stranger’s library. But I stopped pretending that this makes me fundamentally different from who I was years ago, installing one on a Friday afternoon and trusting the crowd to have read the rest.
My teacher was right. The good programmer found the easiest way again. They always do.
Both speeds are valid, and I think it is worth being good at both. The fast one when you are playing in a sandbox, the careful one when something real is on the line. The tool will happily do either. Knowing which one the moment calls for is the part that was always yours, not the tool’s.
Where is your line? Which code do you actually read, and which do you just trust?