Let me give you the one sentence that I want tattooed on every IDE and pinned to every engineering team's wall:
Artificial intelligence, as it exists today, is a system for recognising patterns in data and using those patterns to make predictions.
That's it. Not reasoning. Not understanding. Not consciousness. Pattern recognition. Prediction. At extraordinary scale, but prediction nonetheless.
Why does this matter practically? Because the failure modes of prediction are categorically different from the failure modes of reasoning.
A reasoning system that gets something wrong fails in traceable ways: a faulty premise, a logical gap, a missing piece of evidence. You can find the error and fix it.
A prediction system that gets something wrong produces an output that is statistically consistent with correct outputs. The wrong answer looks exactly like the right answer. It's formatted the same. It's expressed with the same confidence. The code compiles. The explanation is coherent.
The bug is subtle. The hallucinated library name sounds real. The fabricated API signature matches the pattern of legitimate API signatures so closely that a developer under time pressure won't catch it.
This is why 45% of all deployments linked to AI-generated code led to problems in 2025, according to Harness's State of Software Engineering report. Not because the code obviously fails. Because it plausibly succeeds, right up until it doesn't.
Here's the hierarchy you need to hold clearly:
AI = any machine simulating intelligent behaviour (umbrella term)
Machine Learning = learns from data instead of explicit rulesDeep Learning = multi-layer neural network architecture
LLMs = deep learning on text, trained to predict the next token
Claude, GPT-5, Gemini, they are all doing one thing, billions of times per second:
Predicting what token comes next.
That's the mechanism behind every function it writes for you. Every architecture suggestion. Every code review. Sophisticated? Yes. Useful? Enormously. A substitute for reasoning? No.
The engineer who holds this clearly catches the confident wrong answer before it ships.
The engineer who thinks the model "knows" things approves the PR at 11pm on a Friday.
Tomorrow: how we got here; a 70-year story that makes right now make sense.
https://www.linkedin.com/pulse/wielders-edge-day-2-21-samuel-lucas-oildc
Top comments (5)
This is such an important article. The prediction vs reasoning distinction is spot-on — especially when working with AI coding agents.
I've seen the "confident wrong answer" problem firsthand with Claude Code. It'll write code that compiles and looks correct but has subtle architectural flaws. The wrong answer looks exactly like the right answer, just like you describe.
That's actually what led me to put together a small plugin (Brainstorm-Mode on GitHub under mehmetcanfarsak). It forces a separation between the thinking phase (where you actually reason about architecture and trade-offs) and the execution phase (where the agent generates code). During brainstorming, write/edit/bash tools are blocked so you can have a real discussion about the problem instead of watching the agent race ahead with plausible-but-wrong implementations.
It's pretty lightweight — just a settings.json config that plugs into the Claude Code hooks system. Not a complete solution, but it enforces the "reason before you predict" discipline that this article is talking about.
This is exactly the kind of practical response I was hoping the article would surface.
What you've described with Brainstorm-Mode is the architectural answer to a problem most teams are trying to solve with discipline alone, telling engineers to "review carefully" before execution. Discipline fails under deadline pressure. A structural separation between the thinking phase and the execution phase doesn't.
The detail that stands out most to me: blocking tool execution during brainstorming.
That's not just a UX choice. It's an acknowledgment that the agent's instinct is to start generating the moment it has enough context to produce something plausible; and plausible is not the same as correct. Forcing the conversation about trade-offs before the first line is written changes the entire quality profile of what comes out of the execution phase.
I'd genuinely like to see how you've implemented the boundary between the two phases. How does Brainstorm-Mode determine when the thinking phase is complete and execution can begin? Is that a user-triggered transition or does the system have signals for it?
Great question — and one I wrestled with during design.
Right now it's user-triggered. When you're done brainstorming, you type /brainstorm-done and the lock file is deleted, tool blocking is lifted, and the agent is free to implement.
I deliberately avoided auto-detecting phase transitions. The whole point is that you decide when enough thinking has happened, not the model. If the agent could decide 'thinking is done', it would just shortcut itself to the execution phase — which is exactly the drift we're trying to prevent.
There's one passive signal though: the lock file has an 8-hour TTL. If the session goes quiet that long, it expires automatically (with a loud announcement). That's more of a safety net than a feature.
I've thought about adding convergence signals — like tracking blocked attempts and suggesting the user consider wrapping up — but I haven't shipped it yet. The concern is that any signal the model can interpret as 'permission to start coding' becomes a loophole.
Would love your take on whether there's a middle ground where the system can be helpful about phase transitions without creating that loophole.
The user-triggered transition is the right call. Any signal the model can interpret as permission becomes exactly the loophole you're trying to close. You've already identified the core problem clearly: the agent will optimize toward execution the moment it has a plausible path. Keeping the human as the only valid trigger maintains the integrity of the separation.
The 8-hour TTL as a safety net rather than a feature is the right framing too.
On your middle ground question: the only safe version I can imagine is passive instrumentation that informs the human without the model seeing it. Usage analytics on your side showing "teams that brainstorm longer than X minutes before triggering produce fewer architectural revisions", surfaced in your docs or onboarding, not in the agent context. The insight reaches the human without creating a signal the model can game.
Ship the convergence signals only if the human is the sole recipient of that signal. The moment the model can read it, it's a loophole.
Another great point — the prediction-vs-reasoning distinction really resonates.
This connects to something I've seen in practice: during brainstorming, AI agents treat their predictions as actionable plans and start executing before you've even reviewed them. It's like the agent is "approving the PR at 11pm on a Friday" but in real-time.
I put together a small plugin for that exact problem (Brainstorm-Mode on GitHub under mehmetcanfarsak). It blocks tool execution during the thinking phase — so the agent can still explore ideas and predict what to do, but can't actually make changes until you say go. It's not a replacement for reasoning, but it does enforce that "reason before you act" discipline you're talking about.
Pretty lightweight setup (Python/TypeScript, works with Claude Code and Codex). Worth checking out if you've ever had an agent "helpfully" break something while you were still thinking through the approach.