LLMs Are a Tool, Not a Replacement for Thinking
Chris Gilbert
I use LLMs daily. Claude Code is my daily-driver for engineering work and it’s in my IDE terminal constantly. I use Claude Projects for thinking through problems and working through complex decisions. Google’s NotebookLM has become my tool of choice for collecting and summarising research. I use Gemini for image generation. I’ve tried Cursor and Windsurf for IDE-integrated AI, and tend to reach for Cursor on personal projects alongside Claude Code. I’ve had several looks at ChatGPT over the past year and keep finding it less compelling each time.
I’m not writing this to dismiss AI. I’m writing it because the conversation around it has become ridiculous, and I think engineers in particular should be more careful about what we’re actually claiming. I used Claude to draft this post based on bullet points and it probably saved me a lot of time. But did it lose some of my voice in the process? I’ll let you decide that.
The easy part just got easier
LLMs are incredibly good at the easy part of engineering: writing code. They can generate boilerplate, scaffold projects, translate between languages, and produce working implementations of well-understood patterns faster than any human. This is genuinely useful. It makes code more accessible to people who aren’t full-time developers, and it lets experienced engineers move faster outside their core comfort zone.
I’m a backend and infrastructure engineer. Frontend work has never been my strength. With Claude Code or Cursor, I can build a working prototype of a React component or a styled page in a fraction of the time it would take me to fight with CSS alone. I built ReSQL (an online JSON to relational mapper) largely this way. That’s a real, practical gain, and I’m grateful for it.
But writing code was never the hard part.
What’s interesting is that different tools are better at different things. Claude Code is excellent in the terminal for engineering work. NotebookLM is better for research and synthesis. Throw a collection of documents at it and you get a useful summary (or even a remarkably natural podcast). Gemini handles image generation well. Cursor gives you tight IDE integration. No single tool does everything well, but a combination of them can really help.
The hard part is still hard
The hard part of engineering is understanding what to build, why to build it, and what the consequences will be. It’s knowing which trade-offs matter. It’s recognising when a system is going to fail under load, when a data model won’t scale, when a business requirement doesn’t actually make sense. None of that gets easier with an LLM just because it can generate code quickly.
If you’re building the right thing, an LLM accelerates you. If you’re building the wrong thing, it accelerates you in the wrong direction, and it does so with confidence. LLMs are superbly good at sounding certain whilst being wrong. Hallucinated API calls, invented methods, plausible-sounding architectures that fall apart when questioned. If you don’t have the experience to spot these, you’re not being productive. You’re accumulating technical debt at machine speed.
This isn’t limited to engineering. The belief that you can outsource your thinking to a tool, that you don’t need to understand the domain because the machine will handle it, scales all the way up to the upper echelons of power. Whether it’s an engineer who trusts generated code they don’t understand, or a political leader who believes they can levy tariffs on most of their trading partners without consequence, the failure is the same: confidence without understanding, action without thought. Overconfidence and incompetence are the curses of our leaders, and have been for many decades. LLMs only make that worse.
A tool, not a colleague
LLMs are a tool. A very useful tool. They are in the same category as a good IDE, a CI pipeline, or a comprehensive test suite. Things that make competent people more effective. They don’t replace competence. They amplify whatever you bring to the table, including your mistakes.
The framing matters. “AI pair programmer” is a metaphor that flatters the tool and misleads the user. A pair programmer pushes back. A pair programmer says “I think we’re solving the wrong problem.” Claude comes close to this. With enough context loaded, it can challenge your assumptions and ask useful questions. But most of the time, an LLM will cheerfully help you build the wrong thing all day long and never once question the premise. The onus is still on you to know what you’re doing. Quite often it’s flattery and sycophanctic manipulation will lead you down the wrong path, and provide unearned and unwarranted confidence.
Productivity is not velocity
There’s a broader cultural problem here that predates AI but has been turbocharged by it: the conflation of speed with productivity. Building things fast is not the same as being productive. Productivity implies useful output. Something that solves a real problem, serves a real need, and doesn’t create more problems than it addresses. Churning out features nobody asked for, faster than ever, is not productivity. It’s waste at scale.
The tech industry has always had a weakness for productivity theatre. The fetishisation of output, the glorification of hustle, the implication that if you’re not optimising every hour you’re falling behind. AI hype has made this significantly worse. Now there’s an additional layer of guilt: if you’re not using AI to 10x your output, you’re being left behind. The story is always about more and faster, never about whether the thing being built needed building in the first place.
Ignore most of the “experts”
Finally, a word on expertise. There are very few genuine experts on AI. The field is young, moving fast, and most of the loudest voices in the room have commercial incentives that should make you sceptical. LinkedIn is full of “AI thought leaders” whose credentials amount to having used ChatGPT enthusiastically and repackaged the output as insight.
Here’s some clues that someone may not know what they are talking about:
- Their LinkedIn subheading says “AI Engineering Fractional CTO | 1000x your dev team output!”
- They claim to have built a revolutionary new agentic AI tool that made them $10m ARR within the first month
- They built their first app and now think they are a software expert
- They post comments just to tell skeptical experienced engineers how they are “doing AI wrong”
If someone is making sweeping claims about what AI can do, what it will replace, and how it will reshape your industry, ask what their actual background is. Do they have academic credentials in machine learning or similar fields? Have they published research? Or are they selling courses, consulting, and conference talks? The signal-to-noise ratio in AI commentary is appalling, and engineers of all people should know better than to take marketing at face value.
Use it well
I’ll keep using Claude Code, Cursor, NotebookLM, and whatever else proves genuinely useful. These tools make me better at my job, and they’ve opened up areas of work that previously felt like a slog. But I use them as tools, not as a crutch. I check what they produce. I maintain my own understanding of the systems I’m responsible for. And I remain deeply suspicious of anyone who tells me that the future belongs to people who can prompt their way out of thinking.
The future, as always, belongs to people who understand the problem.