DEV Community: Kristopher Sandoval

Local Consumer LLMs Are Kind of Terrible Right Now. They’re Going to Kill Cloud AI Anyway.

Kristopher Sandoval — Fri, 01 May 2026 19:03:36 +0000

Here’s a disclosure up front — I use Claude quite frequently. I use it for research when I’m writing an in-depth piece, I use it to review code (especially when that code is from someone else), and I use it for a smattering of tasks both simple and complex where I feel limited by my own understanding and capability. It’s fast, it’s sharp, and if I’m being honest, I rely on it more than I probably should. I also use local AI pretty constantly — right now, I am running five separate models as a mixture of experts in a self-checking council for code scaffolding and review. So understand that what I’m about to say isn’t coming from someone who’s cheerleading against frontier AI out of ideological principle.

Local LLMs, as a category, are currently aggressively mediocre.

That’s not a take designed to be contrarian — it’s just accurate. If you fire up Ollama today, pull a capable open-weight models, and ask it something genuinely complex, you are going to notice the gap. The reasoning stumbles and context limitations surface quickly. The multi-step tasks that Claude handles with what looks like effortless coherence take considerably more coaxing from a local 8B model. And the wait is often significant — people used to their query taking 30 seconds to handle will be shocked at the reality that local LLMs are often a “set, walk away, have a coffee, check on the kids, and then see if we’re actually done generating” affair.

This all needs a bit of a reality check as well — while I’m sure there’s a chunk of tech bros currently screaming at the screen that some local models are killing the game, they’re not using consumer-grade hardware that is common. They’re using two massive 16GB graphics cards in a breakout box connected over Oculink — whereas most people who want to use local LLMs as a self-starter are more likely to be using a Mac Mini or a name brand prebuilt with Linux installed. And in those cases?

Well, simply put — there is no honest reading of the current benchmark data that says local models have caught the frontier.

But the trajectory — and this is what I actually want you to sit with — is something else entirely.

At the end of 2023, the best closed model scored around 88% on MMLU while the best open-weight alternative managed roughly 70.5%. That was a gap of 17.5 percentage points, and it felt huge — especially considering the bulky hardware you’d have to plop thousands of dollars down on to actually achieve this result.

By early 2026, that gap is effectively zero on knowledge benchmarks, and single digits on most reasoning tasks. Open-weight models now trail the state-of-the-art proprietary models by only about three months on average. Across independent benchmarks and real-world workloads, the performance gap between proprietary frontier models and open-source alternatives has narrowed to less than five percent on many core tasks. And the cost of that hardware? That calculus is starting to change too — especially as more consumer-grade hardware is building for local AI first.

What was a canyon two years ago is now a crack — and that crack is getting smaller every quarter.

So let’s talk about what’s actually happening here, why local models matter even before they fully close that gap, how you can set one up and evaluate it for yourself today, and what the shape of this thing looks like from where I’m standing.

The Honest State of Local Models Right Now

Let’s stay honest for a moment, because the local AI community has a tendency to paper over the gaps with benchmark cherrypicking.

The current best-in-class local setup — something like Qwen 3 72B or DeepSeek V4 Flash running on a machine with enough VRAM to handle it — is genuinely impressive. Qwen 3 72B scores 83.1 on MMLU and 84.2 on HumanEval, which would have put it in GPT-4 territory just two years ago. For most daily coding tasks — completion, explanation, refactoring, test generation — you can run a capable local model and not feel like you’re working with something broken. Llama 3.3 8B scores 73.0 on MMLU at Q4_K_M quantisation, which is a number that required a cloud API call to hit in 2023.

But the ceiling on complex multi-step reasoning remains meaningfully lower than frontier cloud models — particularly for anything below the 14B parameter class. In February 2026, Claude Opus 4.6 leads Humanity’s Last Exam at 53.1% with tool access. The best open-weight models aren’t close on that benchmark. On agentic tasks — BrowseComp, TerminalBench, OSWorld — open models trail significantly. The consistency gap is real too: proprietary models tend to perform well across all categories simultaneously, while open models spike on specific benchmarks and dip on others.

There’s also the quantisation tradeoff. Q4_K_M quantisation generally preserves benchmark scores within 1–3 points of full precision on MMLU for most models — which is good news — but degradation can exceed 5% on specialised tasks like multi-step maths reasoning. You’re making a significant tradeoff — and while that’s fine, it’s one that you aren’t having to make with cloud models. You’re making a trade, and it’s important to understand what you’re trading.

All of this is also not just a benchmark question — there’s also the equally important hardware question. The smallest setup that gives you genuinely capable inference — something that won’t frustrate you on a real task — requires at least 8GB of RAM for a 7B or 8B model, and realistically 16GB+ for a comfortable experience. The “sweet spot” models like Llama 3.3 8B and Mistral Small 3 7B run on a 16GB machine, but pushing into 70B-class models — where the quality gap closes considerably — requires the kind of hardware budget that not everyone has sitting around. An RTX 4090 or an Apple M4 Max/Ultra starts to look like a reasonable investment if you’re running this professionally, but it’s not nothing. And if you take a look at Reddit, you’ll see that the people who can actually show off the frontier of local LLMs are the ones willing to drop more than $75K on 16 DGX Spark units, not the average person using local models for routine tasks.

None of this is catastrophic. It’s just the current reality. And the current reality is worth naming plainly before we get to the part that actually matters.

Why You Should Care Even Before They’re Better Than Claude

You might be reading this and thinking to yourself “man this person hates local AI”. To be clear, I think local AI is a huge revolution that’s right on the horizon. And today? Well, “not as good as Claude” and “not worth running locally” are not the same statement.

The case for local models isn’t purely about closing the capability gap with frontier cloud models. It’s about what local inference gives you that cloud inference structurally cannot — and those are things that matter regardless of where the benchmarks sit right now.

Privacy is the obvious one. Healthcare companies, law firms, industrial operators, and government contractors cannot send their data to third-party APIs — not because of paranoia, but because of HIPAA, GDPR, SOC 2, and a dozen other compliance requirements that make cloud AI a non-starter for sensitive workloads. Running Ollama locally means your data never leaves your network. There are no terms of service to audit, no data retention policies to worry about, and no compliance exposure from third-party processing. For those use cases, a local 8B model that’s 80% as capable as Claude is not a wild compromise — and in some cases, it may be the only viable option.

Cost is another dimension that doesn’t get discussed honestly enough. GPT-4o currently charges approximately $15 per million output tokens, and Claude Opus 4.6 is in the same range. For developers iterating on prompts, building RAG pipelines, or processing high volumes of documents, those charges compound fast. A Mac mini M4 Pro with 48GB RAM runs you roughly $1,800 USD as a one-time cost, with monthly electricity expenses of $10 — $20 USD with regular use. Break-even analysis puts local deployment at 3–8 months of use versus cloud API pricing at scale, and after that it’s essentially free inference. For production workloads processing more than 10 million tokens a month, the maths is not close.

And then there’s model sovereignty — which is less talked about but increasingly important. OpenAI retired 33 models in January 2025 alone. When GPT-5 launched, its changed model routing broke production workflows overnight. Companies had to debug broken integrations under pressure. With open-weight models running locally, you control the version — you can freeze a model that works and run it indefinitely with no deprecation notices, no forced migrations, and no breaking changes to your prompt stack because someone at the vendor decided to retire a model. In production environments where stability matters, that’s a significant operational advantage.

TrafficBench benchmarking found that 80.7% of LLM workloads can be handled by small local models with 77.1% energy savings versus cloud-only deployment. The implication isn’t that local replaces cloud for everything — it’s that most workloads don’t actually need the frontier, and running them locally is cheaper, faster, and more private.

A Mixture of Solutions

So here we land upon a significant reality — as things currently stand, local AI can’t beat the cloud providers, but it’s not an all or nothing proposition. Being able to deploy local AI for tasks which carry significant cloud costs and require local inference is pretty good — while you don’t have the frontier of Claude or ChatGPT, you do have good enough considering the work you’re actually doing. Taking the next step into the cloud gives you that rapid frontier experience — and hybridising between the two gives you a very strong solution.

For right now, that’s going to be the reality for some time to come — but things are changing rapidly. You can see the calculus above — over time, the reality of local models has become more reasonable, more attractive, and potentially more useful. And while right now local models are kind of “meh” compared to cloud models, that may not always be the reality.

So what’s going to change this ultimately? A few things:

Better local hardware — right now, unless you want to shell out a crazy amount of money, you’re quite limited in what you can do. Some local models compete in very, very limited areas like computer vision and home automation, but we’re going to need much better hardware and drivers to run it. As an example, the new Mac Minis are decent enough for local AI — but the introduction of things like TinyGPU will make merging unified memory with external GPUs and NPU units more feasible, thus dramatically increasing the ability, size, and context window of local models.
Better pricing — jumping on the hardware issue is the fact that what is available is just too dang expensive. Mega AI datacentres use a lot of RAM, a lot of CPUs, and a lot of cooling systems, meaning that what hardware we do have is crazy expensive. Right now the math heavily favours cloud compute, but that’s not going to be true forever.
Universal drivers and memory layers — until we get a way to really hybridise our VRAM, RAM, processors, etc. across a totally (and truly) unified layer, we’re always going to run into issues. The Mac Mini does really well with a unified data bus across its memory, but it can’t really use eGPUs at scale. Mega-Linux boxes with fifty graphics cards are great but they’re not cost effective. Adding horizontal power scalability is difficult unless you’re a data centre. Once we figure out that connectivity problem — be it via an updated Thunderbolt standard, Oculink, or whatever connector comes into vogue — we’re going to see an explosion of networked local AI.
Cost losses in the cloud space come home to roost — right now, most AI providers are operating in the red. Eventually, they will need to change their cost models either due to necessity or investor hunger. And just like how Netflix cost increases are causing people to look for alternatives, cost surges for cloud resources are going to drive people locally.

Setting Up Your First Local LLM with Ollama

The fastest way to experience the current state of this for yourself — and I genuinely recommend doing this before forming a strong opinion either way — is to get Ollama running on your machine. Yes, llama.cpp is probably better for resource use, but for the average person, this is going to be a much more accessible methodology. Ollama has become the de facto GUI standard for running local LLMs, and for the average user who doesn’t want to live in the CLI, this will represent their first foray.

It takes about ten minutes to go from zero to a running model — here’s how to get going.

Installation

macOS:

curl -fsSL https://ollama.ai/install.sh | sh

Either run this, or download the desktop app directly from ollama.com. On Apple Silicon, Ollama automatically uses Metal GPU acceleration — no additional configuration required.

Windows:

Download the installer from ollama.com/download. Windows ARM64 devices received a native build in 2026, eliminating the performance penalty from previous x86 emulation. If you’re on Windows 10 and have an NVIDIA GPU, make sure your driver is version 525 or newer.

Linux:

curl -fsSL https://ollama.ai/install.sh | sh

For systemd-based distributions (Ubuntu, Debian), enable it to run as a service:

sudo systemctl enable ollama
sudo systemctl start ollama

Pulling and Running Your First Model

Once Ollama is installed, pulling a model is a single command. For a first experiment, llama3.2:latest is a reasonable starting point - it’s 2GB, runs on any machine with 8GB RAM, and gives you a representative feel for what local inference currently looks like.

ollama pull llama3.2:latest

To start chatting directly in your terminal, you can use the CLI like this:

ollama run llama3.2

Alternately, you can also do all of this — including the model pull — inside the GUI itself, which is going to arguably be the more common install and use methodology.

If you want to step up to a more capable model and your machine has 16GB+ RAM, try llama3.3:8b or mistral:7b:

ollama pull llama3.3:8b
ollama run llama3.3:8b

Checking GPU Acceleration

After pulling a model, verify whether Ollama is using your GPU or falling back to CPU-only inference. In a separate terminal window, you can issue this command:

tail -f ~/.ollama/logs/server.log | grep "n_gpu_layers"

If n_gpu_layers is 0, inference is CPU-only. If it matches the total layer count, you have full GPU offload. Partial offload happens when the model is too large for your VRAM - Ollama handles this automatically, but it’s worth knowing where you sit.

Using the REST API

A cool thing about Ollama is that you can use the GUI or CLI, but you can also call a local API which runs by default at http://localhost:11434. You can issue commands to it the same way you would any other API tool:

curl http://localhost:11434/api/generate \
  -d '{
    "model": "llama3.3:8b",
    "prompt": "Explain the difference between RBAC and ABAC access control models",
    "stream": false
  }'

Or using the chat endpoint:

curl http://localhost:11434/api/chat \
  -d '{
    "model": "llama3.3:8b",
    "messages": [
      { "role": "user", "content": "Write a Python function to parse a JWT without a library" }
    ],
    "stream": false
  }'

This makes Ollama particularly good as a drop-in replacement for external API requests. You’ll get substantially worse performance — at least on most setups — but you’ll get full privacy and control, and that’s not something to laugh at.

Evaluating the Gap Yourself

Once you’ve got it running, I’d suggest a simple three-step evaluation to form your own opinion.

First, give it a task you actually do every day — a coding problem, a writing task, an explanation — and see how it handles it. Note how long it takes to get the answer — and how many times you have to instruct it to tighten up its reasoning and output. Compare it to your cloud usage — and note any delta between the two.

Second, give it something genuinely complex: a multi-step reasoning problem, a document analysis task, something that requires holding a lot of context. See how quickly it hallucinates or makes assumptions. Ask the AI to complete a multi-step process that requires creative thinking and see how it compares against the froniter cloud model.

Finally, note where it starts to degrade. That degradation point is the gap — and watching it directly is more instructive than any benchmark number. See how long you can keep the conversation going before it goes off the rails — and compare that to the chat limit in place on ChatGPT or Claude.

You’ll likely find that for everyday tasks, capable local models handle the load. You’ll also likely find that somewhere around complex multi-step reasoning, the frontier cloud models pull ahead. Both things will be true at the same time, and that’s the more accurate picture — albeit one that is constantly changing.

The Trajectory Is the Story

And here’s where I want to spend a moment, because that gap is shrinking faster than almost anyone predicted.

Consider the rate of movement. The performance gap between the best open-weight model and the current mainstream proprietary leader currently sits at roughly 6 points on overall capability indices. In mid-2024, that gap was considerably wider. In October 2024, it was 15–20 points on quality indices. In eighteen months, open-weight models have closed more than half of that distance.

There are specific areas where open-weight models already match or beat proprietary ones outright. On maths: GLM-5 (Reasoning) scores 98 on AIME 2025 and 95 on HMMT 2025 — competitive with the best proprietary maths scores. On competitive coding: DeepSeek V4 Pro reaches 93.5 on LiveCodeBench and Kimi K2.5 reaches 89.6 — both ahead of Claude Opus 4.6 at 76 on that specific benchmark. On knowledge: GLM-5 hits 96 on MMLU and 94 on GPQA.

These aren’t cherrypicked anomalies — they’re leading indicators of where the whole category is heading.

Epoch AI data shows open-weight models now trail the state-of-the-art by only about three months on average. That’s the lag time between a frontier capability appearing in a closed model and appearing in an open-weight one. And realistically, three months is not a strategic moat — it’s at best a release cycle.

A Berkeley California Management Review analysis draws the comparison to Clayton Christensen’s disruption framework deliberately: open-source LLMs are following the classic disruption pathway — starting with cost advantages that democratise access, then rapidly improving through community-driven innovation while offering capabilities that closed models structurally cannot match. The pattern has played out in operating systems, databases, and web servers, and there’s no principled reason to think AI model weights are exempt from it.

Not There Yet, But the Direction Is Clear

I want to be precise about the claim I’m making here.

I’m not saying local LLMs are ready to replace Claude for everything today. They’re not — in actuality, local AI models are comparatively terrible when looking at the cloud frontier. The complex reasoning gap is real. The agentic capability gap is real. For the hardest problems, frontier cloud models still hold a meaningful lead, and for tasks that genuinely require that ceiling, the answer right now is still to use them (for better or for worse).

What I’m saying is something more specific. I’m saying that the capability gap is narrowing faster than the AI narrative acknowledges — and while local models are arguably pretty bad compared to the frontier, the structural gap is closing incredibly fast. For the majority of actual daily workloads, a well-run local setup may already be good enough, costs nothing per token, and keeps your data on your hardware. The lack of quality or the inability to do complex multi-stage multi-variable tasks can be excused when the cost is zero after a few months compared to working with a cloud provider that will always take your money.

And there are some specific areas where open-weight models have already surpassed frontier closed models. The three-month lag time between frontier capability and open-weight capability is not a property of the category — it’s a snapshot that gets updated with every release cycle. The intelligence is getting cheaper, the models are getting smaller without losing quality, the hardware is getting faster, and the community building all of this is not slowing down. An NVIDIA position paper from June 2025 makes the argument that the next real leap forward in agentic AI won’t come from models getting bigger — it’ll come from them getting smaller, more specialised, and more deployable at the edge.

Local AI right now is not perfect. It’s not the best answer in most circumstances where AI is super valuable. But it is on a clear and measurable path toward being better, stronger, and accessible to anyone who wants to run it — and that trajectory is worth paying attention to.

So I’ll reiterate my statement — local AI right now is comparably terrible against cloud AI. But that statement is getting weaker day by day — and soon, the inverse will be true.

The IT/OT Gap Is 80% Politics: A Field Manual for the People Stuck in the Middle

Kristopher Sandoval — Wed, 29 Apr 2026 19:58:47 +0000

You’re on a site, and you have roughly two million dollars of capital equipment sitting idle for five days because somebody in an office five hundred miles from the plant blocked a MAC address.

The sequence of events that got you to this point was unglamorous and entirely typical. A new vibration sensor had been installed on a critical line. The sensor was a known model, ordered through approved channels, commissioned by a competent integrator. It was also, as far as the central IT team was concerned, a new device on the network with no ticket, no security review, and no entry in the configuration management database.

The IT team did what their playbook told them to do. They blocked it. The plant did what its playbook told it to do. It tried to run anyway, which it couldn’t, because the line’s monitoring depended on the sensor that was now silently disconnected. By the time the politics resolved — through escalation, then meetings, then a hastily-drafted exception process — the plant had lost five shifts of production.

Sound familiar?

Here’s the thing — nobody in that story was incompetent. The IT team was applying a sensible policy. The OT team had ordered a sensible part. The integrator had done the work correctly. The thing that broke was the seam between IT and OT; the thing that broke was political.

Almost every modernisation deck I’ve ever seen treats the IT/OT gap as a technical problem — one that can be solved with a better gateway, a better protocol, a better diagram — and almost every modernisation project I’ve ever seen fails at the gap because it is not actually a technical problem. It is a political one. About 80% political, by my rough estimate. And until that 80% is dealt with, no amount of architecture is ever going to hold.

What the Gap Actually Is

The shorthand version of the IT/OT gap is that IT and OT have different priorities. IT cares about security, patching, compliance, and uptime in the abstract. OT cares about production, safety, and the specific machines on the floor. This framing is true and useful — but italso misses the part that actually causes the failures.

The deeper version is that IT and OT have different theories of accountability.

When IT makes a change that breaks something, the consequences are typically distributed — a service has degraded performance, a few users complain, the on-call rotation handles it, and life goes on.

When OT makes a change that breaks something, the consequences are concentrated and immediate — a line stops, a shift’s output is lost, somebody’s bonus is gone, and in the worst case, somebody gets hurt.

Simply put, these are not the same risk profiles — and accordingly, they cannot be managed by the same processes. And every modernisation deck that pretends they can is, intentionally or not, asking one of the two organisations to bear the other’s risk profile without compensation.

And that right there is the true battle you’re waging. It looks like a technical fight because the symptoms are technical — blocked MAC addresses, denied patches, disputed change windows, contested ownership of brokers and gateways. But the substance and the impact is ultimately political — it’s about who owns the data, who gets paged at 3 AM, and who gets blamed when production stops.

Until those are negotiated, the fight will keep happening, in the symptoms, forever.

Why Architecture Alone Doesn’t Fix It

Ok, so we see a problem — let’s address it with architecture. I’ve seen this play out before almost countless times — and I’ve also seen it fail more times than I can remember.

A vendor or consultant or internal architect proposes a modernisation architecture. The architecture has a clean line between IT and OT. There is a gateway. There is a DMZ. There is a Purdue model diagram with crisp boundaries. The pitch is that the architecture will solve the gap by making the boundary explicit.

But it will not. It can not.

The reason is that architectures are diagrams, and diagrams do not allocate risk. When the broker on the DMZ goes down at 2 AM on a Sunday, the diagram does not tell the on-call rotation who pages whom. When the gateway needs a security patch, the diagram does not tell the change-control board whether the patch can wait until the planned shutdown or has to go in next Tuesday. When the data fabric crosses the Purdue boundary, the diagram does not tell the auditors which team is responsible for the data loss. These are decisions that have to be made *by people*, in writing, in advance. The architecture is a precondition for the decisions, not a substitute for them.

And this is why “we have a great architecture but the IT/OT relationship is bad” is a sentence I hear all the time. It’s always a sentence about the same failure: the political work was deferred to be solved later, by the relationship, after the architecture was built. It does not get solved. It festers. The architecture survives, technically. But the project does not. And just as importantly, the relationships between the IT and OT teams fail catostrophically.

The Four-Part Political Playbook

To resolve this issue, you need to treat the IT/OT integration like the diplomatic problem it actually is. Diplomatic problems have known shapes. They’re solved by structured negotiations, not by technical specifications. And by attacking this problem through accepting what it actually is, you can significantly diminish the damage the IT/OT gap is doing to your business.

Below are the four agreements I’d insist on having in writing before any modernisation project crosses the IT/OT boundary in earnest.

Part 1: The Joint Incident Process

Every IT/OT seam needs a single incident process that both sides have signed. Not two processes — one. The process specifies who pages whom, in what order, on what timelines, for what classes of failure. It specifies who can call a production stop and who cannot. It specifies the escalation path when the two sides disagree about the severity of an event.

The reason this matters more than it seems is that incidents are when the seam between IT and OT is tested. During steady-state operation, IT and OT can avoid each other. During an incident, they can’t. If the incident process is not written down, it gets invented in the moment, by the people most stressed and least equipped to invent processes. This is how the MAC-address-blocking story happens. Nobody knew who could escalate to whom. So nobody did, until the production loss got large enough that somebody at the executive level intervened. Days, not minutes.

Write the joint process. Run drills against it. Update it after every real incident.

Part 2: The Data Ownership Matrix

The single largest source of unresolved IT/OT conflict, in my experience, is unclear data ownership. Who owns the historian? The MQTT broker? The dashboards that present plant data to the business? The AI models trained on that data? The training datasets themselves?

If you do not have a written matrix that lists each data asset, who owns it, who has access to it, and who is responsible for its quality, the answer in practice will be “whoever was loudest in the last meeting.” That is not a sustainable basis for an integration. The matrix is unglamorous to produce. It is a spreadsheet. It is also, in most plants, the most valuable single document the modernisation project can produce, because it forecloses dozens of latent fights that would otherwise happen one at a time over the next three years.

Build the matrix. Get signatures. Update it when assets change.

Part 3: The Shared Change-Control Window

IT change control runs on one rhythm — typically weekly or monthly patching cycles, driven by vulnerability disclosures and compliance schedules. OT change control runs on a completely different rhythm — typically driven by planned shutdowns, line changeovers, and seasonal maintenance windows.

When these two cadences collide, somebody loses. Either IT pushes a patch into a production window and risks breaking the line, or OT refuses to allow the patch and accumulates security debt. Both are bad outcomes. The fix is a shared change-control window, agreed in advance, that defines when each side can make changes to the shared infrastructure, and what the exception process is for changes that can’t wait.

The shared window is harder to establish than it sounds, because it forces both sides to admit their own constraints in front of the other. That admission is uncomfortable. It is also exactly what the integration needs.

Part 4: The Escalation Rules

The fourth agreement is the one that handles the cases the other three don’t. When IT and OT disagree on something — a patch, an architecture decision, a vendor choice, an incident response — there has to be a defined escalation path. Not a vague one. A specific one. Up to whom, on what timeline, with what required outputs.

In most plants I have worked with, the absence of a defined escalation path is the single biggest predictor of long-running IT/OT dysfunction. Disputes that should have been resolved at the working level escalate informally to the executive level, where they get resolved badly, by people who don’t have the context. Or they don’t escalate at all, and they fester. Either pattern poisons the relationship over years.

Define the escalation path. Use it sparingly. Document the outcomes.

Why This Is the Hardest Part

The four agreements above are not technically difficult. They are politically difficult, which is harder. Each one requires somebody to commit to a constraint — on response time, on access, on change cadence, on escalation — that they would prefer to keep flexible. The flexibility is, in a sense, what each side has been trading on for years. Giving it up feels like losing.

The reframe that helps, when I’m in these conversations, is that the flexibility is not actually flexibility. It is unmanaged risk. Each side has been quietly absorbing the other side’s risk in ways that nobody has accounted for, and the absorption is what makes the relationship feel adversarial. When the agreements are written, the risk gets allocated explicitly. The relationship gets less adversarial, because nobody is being asked to silently bear what they didn’t sign up for.

This is the part of the work the consultants don’t tend to write about, because it doesn’t sell frameworks. The frameworks are easy. The agreements are hard. Almost nobody who hasn’t worked the seam from the inside understands how hard.

What Good Looks Like

Of course I’m going to bring this back to FlowFuse, because it’s the team I work for and the case I think is honest. But hear me out, because the FlowFuse angle on the IT/OT problem is, perhaps surprisingly, mostly an organisational angle, not a technical one.

The platform-level value of FlowFuse in an IT/OT context is that it gives both sides a single tool they can both legitimately operate. OT engineers build flows in Node-RED, which they can read and reason about. IT operators manage the platform, which provides the audit trails, role-based access, and deployment controls IT needs to feel comfortable. The data flows are visible to both sides, which makes the data ownership matrix easier to fill in — because you can point at a flow and say “this is what we are doing with this data, this is who owns it, this is who can change it.” Visibility doesn’t solve the political problem, but it removes a class of arguments that would otherwise happen because nobody could see what was actually being done with the data.

To generalise the point back out: the tools that survive the IT/OT seam are the ones that *both sides can legitimately operate*. If your tool only OT can use, IT will block it on principle. If your tool only IT can use, OT will work around it. The shared-tooling property is a precondition for the political work, not a substitute, but it does meaningful work in dampening the symptoms while the political work is being done.

Treat It Like Diplomacy

The hardest sentence to write in a modernisation deck is “the IT/OT gap is mostly political, and the political work has not been done.” Nobody wants to hear it. Vendors don’t want to write it. Consultants prefer to sell frameworks. Executives prefer to believe the architecture will solve it.

But the engineers stuck in the middle — the people who get paged at 3 AM when the broker goes down, who eat the criticism when the patch breaks the line, who write the workarounds when the security policy collides with the production schedule — those people know. The gap is political. The fix is political. And the architecture is only the beginning of the conversation.

Ultimately, the modernisation projects that survive ten years are the ones whose teams treat IT/OT integration as the diplomatic problem it is, write the four agreements down, and update them as the relationship evolves. The projects that fail are the ones whose decks pretend the gap is technical and act surprised when the politics break the architecture. There are very few exceptions to this pattern.

And to be clear — I have yet to see one in my career.

Here’s a Hot Take For You: The Industrial Space Needs to Be Braver

Kristopher Sandoval — Mon, 27 Apr 2026 13:01:01 +0000

The Industrial Space Needs to Be Braver

Walk into any plant floor in 2026 and you’ll see something that should be shocking — but somehow isn’t. The PLC running the line was likely designed in the early 2000s. The protocol it’s speaking was probably standardised in 1979. The HMI looks like Windows 95 had a baby with a calculator. And somewhere in the back office, a tired controls engineer is gluing it all together with VBA and ladder logic — and, probably, hopes and prayers.

And this isn’t a story about technical debt. Technical debt implies a deliberate trade-off — you took a shortcut, you know about it, and you’re planning to fix it. What we have in industrial automation is something stranger and harder to talk about: a kind of institutional fear. We are not stuck on legacy protocols because they are the best tool for the job. We’re stuck on legacy protocols because nobody wants to be the person who broke the line.

And the worst part about all of this is that the caution I’m talking about has fundamentally metastasised into something much worse — it’s become an excuse. And the people paying the price are not the vendors, not the integrators, and not even the engineers — it’s the end users. Operators, technicians, plant managers, and ultimately the customers downstream who deal with the consequences of systems that should have been retired a decade ago.

The Conservatism Was Earned — And Then It Wasn’t

Let’s first acknowledge the obvious. Industrial environments are not consumer environments. Downtime on a production line can cost thousands of dollars per minute. A botched firmware update can take a refinery offline. Safety-critical systems — the ones keeping fingers attached to hands and chemicals contained in tanks — genuinely cannot tolerate the kind of “move fast and break things” energy that defines other parts of the tech industry.

So when people in industrial automation say “if it works, don’t break it,” there is a real reason behind that instinct. The conservatism was earned, hard, over decades of incidents, recalls, and lawsuits.

But somewhere along the way, that earned caution calcified. It stopped being a principle and started being a posture — and now, we’re no longer asking “is this risk worth taking?” Instead, we’re asking “can we get away with not changing anything?”

And to be clear, the answer to that question, increasingly, is no — because the cost of not changing has stopped being abstract. It is showing up in unpatched vulnerabilities, in integration nightmares, in workforce churn, and in the widening gap between what industrial systems can do and what their users actually need them to do.

Old Protocols Are Not Sacred

Modbus was published in 1979. Let that sit for a second. The protocol underpinning a huge chunk of industrial communication is older than the IBM PC, older than the public internet, and older than most of the engineers running plants today. And it is still, in 2026, one of the default ways two devices talk to each other in countless facilities around the world.

This is not a takedown of Modbus, by the way — it’s a remarkable piece of engineering and the fact that it still works is a testament to how well it was designed. But “still works” is doing a lot of heavy lifting in that sentence. Modbus has no native security, no built-in discovery, no metadata, and no real concept of identity. Yes, there are ways around that — and again, this is not a teardown of Modbus, I think it still has a place in modern plants — it’s just that we have spent forty years building scaffolding around it. VPNs, segmented networks, firewalls, custom translators — all because we cannot bring ourselves to retire it.

Meanwhile, the alternatives have matured. OPC UA offers proper security, semantic modelling, and a real information architecture. MQTT with Sparkplug B gives you a publish-subscribe model that actually fits the way modern industrial data wants to flow — event-driven, contextual, and unified. These are not experimental technologies anymore. They are mature, well-supported, and deployed at scale by organisations that decided the inertia was no longer worth the cost.

The question is not whether the new protocols are good enough. They are. The question is whether the industry is willing to commit to them — and so far, the answer has been “kind of” with a half-shrugged “maybe?” tacked on.

AI Is Not the Threat — The Refusal to Engage With It Is

Here’s a disclosure for you — I’m aware that the AI conversation in industrial has gotten exhausting. It is the elephant in every industrial conference room right now, and the discourse has, frustratingly, polarised into two camps.

On one side, vendors selling “AI-driven” everything, often with very little substance behind the marketing. And more on this in a moment — predictably, as a DevRel at FlowFuse, I think FlowFuse is a super notable exception to that statement.

On the other side, a kind of reflexive dismissal — “we don’t need AI, we need reliable automation.”

Both camps are wrong, and they are wrong in ways that reinforce each other. The hype camp gives the dismissive camp a reason to dismiss. The dismissive camp gives the hype camp a reason to keep selling fluff, because there is no real expectation of substance. And the people who would actually benefit from thoughtful AI deployment — predictive maintenance that catches failures before they happen, anomaly detection on noisy sensor streams, agent-driven workflows that handle the routine so humans can focus on the exceptional — are caught in the middle.

Fundamentally, AI is a tool, and like any tool it has appropriate uses and inappropriate ones. Predictive maintenance models trained on historical sensor data are not magic and they are not vaporware — they work, they have been working for years, and the organisations using them well are quietly running their plants more efficiently than the organisations refusing to touch the technology. The same is true of computer vision for quality inspection, of NLP for parsing maintenance logs, and increasingly of agentic systems that can sit alongside human operators and handle the long tail of routine decisions.

Refusing to engage with any of this is not safety. It is abdication. And ultimately, it’s not an abdication that just harms your org.

The End Users Are the Ones Paying

Here’s the part that doesn’t get said often enough — every conversation about industrial modernisation tends to incorrectly focus on the vendors, the integrators, the standards bodies, and the C-suite. The end users — the people who actually have to use these systems every day — rarely get a seat at the table. And it shows.

Consider for a moment two realities. In one, a technician walks up to an HMI that was designed in the last five years — clean, contextual, surfacing the information that actually matters and hiding the rest. They diagnose an issue in two minutes and move on. In the other, the same technician faces a 1995-era screen with sixty status lights, three nested menus, and documentation that lives in a binder somewhere. The same problem takes them an hour (or more), and they are frustrated and demoralised by the time they fix it.

Multiply that across every shift, every operator, every plant. The cost of bad UX in industrial is enormous, and it is paid in time, in errors, in turnover, and in the steady erosion of institutional knowledge as experienced operators retire and the people replacing them refuse to put up with tooling that feels punishing. We talk about the workforce shortage in industry as if it is purely a recruiting problem, as if we can fix it with some new marketing and some flashy logos. But the reality is that a lot of it is a tooling problem. People do not want to spend their careers fighting with software that was bad twenty years ago and has not gotten better — and it’s why a specialist who can either work in the industrial space or work in something like aeronautics is going to choose one over the other almost every single time.

What Bravery Actually Looks Like

I want to be clear about what I am and am not arguing for here. I am not saying rip out the existing infrastructure. I am not saying replace your stack with whatever raised a Series A last week. I am also not saying to pile AI on top of every process and hope for the best. If you’re looking for someone to tell you that the answer is just “more frontier tech, faster,” that is not what this article is about.

What I am saying is this. Bravery in industrial automation looks like a few specific, concrete things.

It looks like running real pilots of new protocols on non-critical lines and taking the results seriously, not as one-off experiments to file away. It looks like evaluating new PLC providers and software-defined platforms with the same rigour you’d apply to an incumbent, rather than dismissing them out of hand because they are unfamiliar. It looks like funding modernisation of HMIs and operator tooling as a first-class investment rather than a perpetually-deferred nice-to-have. It looks like engaging with AI thoughtfully — identifying the use cases where it actually fits, deploying it in those use cases, and being honest about the ones where it doesn’t.

And, fundamentally, it looks like being willing to own the discomfort of change rather than passing the cost of stagnation onto the people who can least afford to pay it.

What Good Looks Like

Now as I said earlier, I think FlowFuse is getting this balance 100% right. Of course I’m going to say that though — I’m the Developer Relations Advocate at FlowFuse. But hear me out — actually digest what I’m about to say.

FlowFuse as a solution treats everything in your stack as a message. It is protocol agnostic — once the message is in the system, it becomes pure data. It supports ancient protocols as well as frontier ones. And importantly, it has AI that actually makes sense. You can use MCP systems to connect documentation and live data sources to the FlowFuse Expert, and then interact with that data as first-class objects. You can get maintenance reports, shift summaries, heck you can even get functional troubleshooting that doesn’t just alert you to a problem, it tells you where the problem likely lives.

And the people who use FlowFuse (and preceding tech Node-RED) are short-circuiting much of this problem — because once you abstract away the older way of doing things and start treating everything as a data point, a source of message, then you can update individual lines, test new methods, and update as you go. You can revitalise your stack without breaking your stack — and you can actually get out of 1986 and step into 2026.

For that reason I think FlowFuse is doing it right — because they support your choice to engage with the frontier. Instead of just telling you to modernise, they’re telling you that you should do that — and then giving you a practical way forward.

And I think that’s a pretty dang good model that others in the industry should be looking at — especially if you’re one of those ancient providers who look at this and balk at the idea of having more than three colours in your interface.

The Final Word: Stagnation Is a Choice

The thing about technical inertia is that it always feels like the safe option. Doing nothing is, by definition, the lowest-risk move on any given day. But the days add up. The protocols get older, the PLCs get more locked in, the gap between industrial tooling and the rest of the technology landscape gets wider, and the workforce that has to deal with it gets smaller and more frustrated.

Ultimately, we cannot keep treating the status quo as a default. The status quo is a choice, made every day, by everyone who decides it is easier to live with the current pain than to take the risk of fixing it. And the longer we make that choice, the harder it becomes to make any other one.

The industrial space needs to be braver. Not reckless, not credulous, not chasing every new acronym that comes out of a vendor pitch deck — but braver than the version of itself that has been hiding behind earned caution as a justification for not doing the harder work. The frontier technologies are here. The new protocols are here. The new providers are here. The end users have been waiting.

It’s time we stopped making them wait.

Vibe Coding Isn’t the Problem — It’s Your Approvals Process

Kristopher Sandoval — Fri, 24 Apr 2026 08:03:12 +0000

Screaming into the void about AI is like complaining about the advent of the train.

Vibe coding is in the news these days, and for largely negative reasons. And in many cases, fair enough — vibe coding has been associated with severe lapses in security, both in terms of the products they create and the platforms used to develop them. For many, vibe coding is just not worth what you get from it — and it’s facing huge pushback in dev spaces.

Here’s the thing though — the problem was never the vibe coding. The problem is the approvals process that allows vibe coded content to proliferate unchecked. This may seem a bit of victim blaming, so let me set an expectation here — if you’re looking for a tech bro to tell you that vibe coding is the future and anyone against it is a luddite, that’s not what this article is about. I don’t think vibe coding is the best thing since sliced bread — but I also don’t think it’s the worst thing to happen in development.

What I do think it has done, however, is expose some critical flaws in the way that software — especially open-source software — gets built and released.

So let’s talk about that.

What Vibe Coding Is

Let’s first talk about what vibe coding actually is. Put simply, vibe coding is perhaps one of the most impactful movements in recent years towards the democratisation of development.

For a long time, creating software — or really any kind of code, for that matter — was locked behind years of education or experience. And breaking into this space was difficult — you either had to hack away at your projects for months before you start to learn the cadence and standards of good development, or you had to go get an actual degree. It was heavy, difficult, and gated.

Vibe coding as a general term encompasses a lot of different development processes — but ultimately, the easiest definition is “coding done by those who aren’t necessarily coders”. Credit: Bernd Dittrich

Vibe coding flipped that entirely. Suddenly, you have huge groups of people who have never coded before able to create proofs of concept — and in some cases even MVPs. This was a monumental shift — it’s not just quicker time to value, it’s opening up a branch of value that was entirely unreachable for the average person.

And that’s a big reason why it’s so attractive for many users. The concept of just having an idea and creating it from nothing is attractive — and anyone who has been around online spaces for any amount of time can pull out a million “I have a great video game idea so I just need to find a developer” posts from their memory.

But that’s also part of the problem — vibe coding opens up access, but it doesn’t necessarily mean that the access it opens up comes with the talent, understanding, or experience needed to execute on it well.

What Vibe Coding Isn’t

Vibe coding is a “tool”, but calling it a “tool” is probably selling it short — it’s an enablement system in the way that the assembly line or rocket fuel was a “tool”. But for all the things it is, there’s quite a few things it isn’t.

First off, it’s a programming solution — not a solution for taste or experience. The average developer has been at the game for so long that they have a solid feel for what “right” is — and what standards or conventions actually do cumulatively. And this is how you can see vibe code at a glance — sections of code that do a simple function in an overly complex way, pointers that don’t point to what the in-line documentation claims, and issues of just bad taste.

Many vibe coders would look at this image and have their eyes almost immediately gloss over — and that’s part of the problem. Credit: Radowan Nakif Rehan

Vibe coding also isn’t some sort of shortcut to senior engineer level. One of the best values long-serving developers have is their knowledge of what the systems they’re working on actually do. Abstracting away the expertise on how to write code and the knowledge of what good code looks like, being able to explain how that code works and in what way is huge — and the lack of that understanding is often why vibe code works and then stops in its tracks.

A big issue here is also the fact that vibe coding isn’t a shortcut for maintenance. Code isn’t something you just build once and it’s good forever — it’s something you have to patch, refactor, maintain, update, debug, and continually improve. Attack vectors change as quickly as user needs, and code is a breathing artefact that needs altering. Vibe coding doesn’t shortcut that — and now you have a code base that needs to either be maintained by someone who doesn’t understand code or by a machine that already thought what it did the first time was good enough.

And finally, it’s not a tool that is self-describing. Vibe coders seem to think of vibe coding like the difference between a trowel and a shovel — but really, the difference is more akin to the one between an abacus and a MacBook Pro. In theory they can do the same things — they can both calculate numbers. But the reality of the tools are very different. You can get a number from an abacus and more or less understand what it means. Most people who own a MacBook Pro barely understand that programs run on binary, let alone the billions and trillions of calculations that happen constantly on their machine.

Where You’re The Problem

So here’s the reality of all of this. Considering everything I just wrote above, too often the real problem with vibe coding in production and open source projects is not just the vibe coders — it’s the maintainers who just accept and move on.

For a long time, maintainers balanced a variety of issues. Burnout from managing too many PRs, the reality that open source is seldom funded by the massive corporations which benefit from it, and a sort of communal trust that developed over time to solve these problems. We’re all in this boat together — so if I’m giving you development for free, you should trust that the effort I put into it was in good faith.

Open source maintainers already have a pretty full plate — but that doesn’t absolve them from dealing with this problem. Credit: Mohammad Rahmani

But that’s no longer the reality of open source and general production in the AI revolution — and the assumptions that we’ve made for so many years need to be fundamentally shifted. Just because code looks right doesn’t mean it is right — and while we could have trusted maintainers and PR writers to test their code in the past, we now have to take on that burden ourselves. It’s not fair — and I don’t like it as much as you don’t like it — but gone are the days where we can look at some code, see that it looks generally correct, and then run some basic unit tests and call it good.

So where do we go from here?

Changing the Mindset of Development in the Age of AI

The honest answer here is that our entire review culture needs to be rethought from the ground up.

For decades, the implicit contract of open source and internal development has been that if a contributor submits code, they are either trying to do something malicious or genuinely trying to add to the codebase. And because of that, we’ve given it a general once-over, maybe a deeper once-over for quality, run it through some security checks, and if everything looks good on that front, started the process of merging. It was built on the assumption that anyone submitting code actually understood what they were submitting, and unless there was some glaring signal that the code was bad, we were generally ok with giving the benefit of the doubt (which is a broader and more insidious issue, but is one for a different article).

But today, that contract no longer holds. We can have massive codebases developed by seemingly experienced people with zero documentation and — worryingly — zero (or minute) understanding.

So here’s what needs to change.

Treat Every PR Like the Author Can’t Explain It

As reviewers, we need to start asking contributors to walk through their changes in plain language. Don’t accept “this adds a caching function” — ask “how does this implement a cache, what happens when the cache is cold, what happens when it overflows, and what is your eviction strategy”. Better yet, force every PR to answer this proactively — if you provide the questions, AI can answer it, but demanding answers up front either makes the unknowledgeable author actually learn their code or surfaces those who understand it from the mire.

You don’t need to accuse anyone of vibe coding, either — if they can’t explain it, tell them to come back when they can, and just don’t merge it.

Force Smaller PRs

Vibe coding often results in a ton of files sprawling across different directories. In some cases, this is just style — I’m very guilty of this myself — but if you have something simple like “manages the colour of buttons on input”, and instead of a single JavaScript file you have ten or twenty files and dependencies, chances are you’re dealing with vibe coded content.

That’s not to say that sprawl is always indicative of vibe coding — but it’s very common, and unfortunately, it often exacerbates the problem by making the code that much more difficult and time-consuming to review.

The fix here is to just demand size limits for your PRs. A forty-line PR that one human can actually explain and read is worth ten four-hundred-line PRs that nobody understands. At scale, this is significant — and enforcing the standard of smaller units in development is a good habit anyhow.

Become Adversarial in Testing

Just validating that code works is no longer enough — we need to actively try and break it. Unit tests are fine and dandy, but we need to test code to its limit. Vibe coded solutions often deal with the first request fine but then fail when you introduce more complex queries and requests — especially if the code was meant to serve an MVP rather than a full code flow. Accordingly, you need to become adversarial and push each PR you’re considering merging. There’s a million security tools that will scan each commit — and you need to start using them.

And to be clear, this has been the advice for years — but with vibe coding, you need to be targeting different segments. In traditional security scanning, you’re looking for obvious malicious rerouting or dictionary attacks. In vibe coding, you’re looking for loop errors, plausible-looking code that fails with common edge cases, even structures that seem to reference each other but have simple errors that cause the entire house of cards to collapse.

The problem here is that much of our security and adversarial processes defend against purposeful failures with malicious intent — but rarely do they defend against accidental failures without awareness, and that is what we’re trying to solve against.

Normalise Disclosure — And Don’t Punish It

The fact is that AI is everywhere, and in many cases it’s a huge vulnerability for an engineer to not use it.

Here’s a disclosure for you — I use AI quite frequently. Do I want to? 50/50, if I’m being honest. Sometimes it creates more work than it solves. Sometimes it gives me a different perspective than I came into the process with. But always my code and the process of generating it is improved in some way. But even if I didn’t see benefit from it, the chances are that if I were an engineer in the industry with a team using AI, a choice of non-use would have career and code impacts.

So if AI is everywhere — and in many cases, engineers and maintainers can’t get away from using it to some degree — then we need to normalise disclosure. Noting something like “I used Claude for the initial boilerplate and functions then validated X, Y, and Z manually” is a huge step above our current process — but it’s a statement that is incentivised against actively by AI luddites and those who see “AI in code” as an auto-reject button.

The use of AI is no longer a dark secret — so we need to stop treating it like it is. Disclosure is the only path forward. Credit: Ben White

That doesn’t mean I’m advocating for more flexible adoption of AI vibe coded contributions — quite the opposite, actually. What I am advising is that if AI is part of the contribution, contributors must see disclosing it as a step towards acceptance of their code — and maintainers should see declaration of AI involvement as a requirement. To be clear, this is a cultural problem that’s hard to fully fix right off the bat — the people who should disclose are generally the ones least likely to do so — and as such, this is more about reshaping incentives for good-faith actors than trying to make disclosure a detection mechanism for bad-faith ones.

AI as an Accelerator

And to be clear here, I think AI is incredibly important in one area — accelerated time to value. Full disclosure here — I’m the Developer Relations Advocate over at FlowFuse, and I think our AI innovations are exactly what AI should be in the development space.

Of course I’m going to say that, right? Let me explain why:

The FlowFuse Expert connects to documentation via Retrieval Augmented Generation, meaning that flows and structures created using it are necessarily tied to understanding independent of the person using the tool. That sidesteps the understanding and style part slightly, but more than anything, it creates a deep contextual web of understanding that you just can’t value high enough.
The way the AI stack on FlowFuse is implemented is as a tool, not a replacement — meaning that you keep your human in the loop review cycles without losing velocity. That’s a good middle ground between accelerate to infinity through mass acceptance and locking down everything to only a small subset of knowledge-holders.
We develop everything in the open — and invite contributors and reviewers alike to look at each PR. Developing in the open with a culture of honesty and truth is a panacea of sorts for a lot of the issues we’ve discussed herein — and adopting this policy could get you 50% of the way to a good solve by itself.

The Living, Breathing Codebase

Look, none of this is glamorous. But also, nothing short of an AI industry collapse will make vibe coding go away. But that’s also not the goal.

The goal here is to create an approvals process that results in code that is good and useful. And in many cases, vibe coded contributions are good and useful — if naive and incomplete. Accordingly, we need to understand that this AI revolution is as much part of the living, breathing codebase as the development of IDEs, state representation, and so forth.

The tooling has changed, and the review process has changed with them. That’s not a moral failing on anyone’s part — it’s just part of the new contract.