Coming to Terms with LLMs

I resisted LLMs for a long time.

It can never beat a human

Early on, I held something close to a conviction: "LLMs can never beat human-written code." Honestly, I still don't think that's entirely wrong. In certain areas, it holds true. Design decisions that require deep contextual understanding, intuition about a business domain, a sense for the ripple effects of a single line of code — these are still human territory.

The problem was that "certain areas" turned out to be narrower than I thought. A good chunk of what I'd categorized as "only a human can do this" was, in practice, something an LLM could handle reasonably well given enough context. Not perfectly — but it doesn't need to be perfect. An 80-point result in five minutes, with a human filling in the remaining twenty, is a perfectly good deal.

What I believed were my strengths

I had defined my strengths in two ways. First, I could deliver reasonably high-quality output fast. Second, my broad domain knowledge gave me a wide pool of ideas to draw from when solving problems.

I was genuinely proud of both. They served me well on my team. When a new feature was needed, I'd spin up a prototype quickly. When something broke in production, I'd narrow down the cause using instinct built from experience. In code reviews, I could offer feedback from multiple angles. These things were my identity as an engineer.

But once LLMs embedded themselves deep into daily work, these strengths became something anyone could do. Writing code quickly, coming up with diverse approaches — a few lines of prompt can do that now. Years of accumulated skill, flattened by a single tool.

What was even more uncomfortable was the process of admitting it. I understood it intellectually, but my gut wouldn't follow. "What I've built up still means something" kept colliding with "but the reality is the reality."

Questioning again

So I kept asking myself: "Are LLM outputs actually reliable?"

Half of that question was genuine curiosity. The other half was a defense mechanism — if the answer was no, my position was safe. And early on, I did find evidence to support that. Hallucinations, confidently suggesting APIs that don't exist, answers that nail the details but miss the bigger picture. I collected these cases and reassured myself: "See, it's not there yet."

But reality didn't cooperate. Colleagues were already shipping solid results with LLMs. One person finished a repetitive migration in a few hours. Another was using LLMs as an assist tool for complex query optimization. No matter how much I doubted, the output sitting right in front of me was hard to deny. And the quality was getting better over time.

FOMO played its part too. "Can I really survive in this environment?" That question wouldn't leave my head. I already knew that refusing to adapt means falling behind. But knowing something and accepting it are two very different things. There's a surprisingly deep gap between understanding something intellectually and actually changing your behavior.

Contradiction, then results

I was caught in my own contradiction. Rejecting LLMs while still being curious. Saying I wouldn't use them while quietly experimenting on the side. Arguing "it's too early" in meetings, then trying them out on personal projects after work. Looking back, it's kind of funny.

Hard to admit, but the results were honest. After various rounds of trial and error, I started integrating LLMs into my workflow for real — and the output was several times what I could produce on my own. Boilerplate code, test case generation, documentation, draft code reviews — the efficiency gain in these areas was tangible. Tasks that used to take me thirty minutes were done in five, and I could spend the remaining twenty-five on design and verification that actually mattered.

It's not a silver bullet, of course. The cases where you can use LLM output as-is are fewer than you'd think. Most of the time it needs editing, and sometimes you're better off starting from scratch. But the sheer value of "getting a starting point fast" is enormous. The time spent staring at an empty editor, agonizing over the first line — that's just gone.

Now my company token quota isn't enough, so I'm paying for a personal subscription too. Spending my own money on a tool I dismissed outright just months ago. Turns out convictions are flimsier than I thought.

It's not the change that's scary

People say change is frightening. I said it too. But looking back, it wasn't the change itself that was truly scary.

Falling behind because you lack the ability — that's unavoidable. There are limits that effort can't overcome. That just means everyone has a ceiling, and there's no shame in it. But standing still while hoping things will change on their own — that's the real problem. Staying frozen in the face of change is the same as doing nothing at all.

I sometimes hear people say "LLMs will make developers obsolete." I don't buy it. The tools changed, but someone still needs to define problems and solve them. The only new condition is that the person needs to know how to use the new tools. A new instrument was added to the toolbox — the carpenter's trade didn't disappear.

I moved late. But I moved. And the difference was bigger than I expected.