Are We Programming Wrong?
The case for ditching the list and for building a digital
There’s a question I keep coming back to, and it’s uncomfortable enough I suspect it’s worth asking out loud.
What if the way most of us write software is fundamentally misconceived? Not wrong in a “you’ve got a bug on line 42” sense. Wrong in that way some start insisting the Earth is flat, is wrong: structurally, philosophically, and at the level of how we’ve framed the problem from the start.
Ok so bear with me in this.
The list problem
Walk or stumble into any codebase and you’ll find the same code skeleton underneath the framework, the abstraction layers, and whatever clever architecture the team is proud of, notes, code fragments, etc. At the base, it’s a list. Do A. Then B. Check C. Call D. Return. Even when we dress it up with objects and functions, when the coder invokes modules and spins up services, the soul of the thing is still sequential. One instruction following another, marching down the page like a ledger.
We programme in lists because lists are how humans made complex systems legible, we all agree on this. It’s baked into our DNA. Forms. Procedures. Authorisation. If this, then that. It’s the syntax of bureaucracy, and bureaucracy is genuinely useful. It’s how you stop things going wrong when thousands of people need to follow the same process without understanding why. (Stupidity not with standing.)
But here’s the thing: bureaucracy is not how cognition works.
Your brain is not executing a queue. Right now, as you read this, you’re running something more like a barely-controlled riot. Visual cortex, language centres, memory systems, threat-assessment loops, emotional registers — all of it firing in parallel, competing, cooperating, feeding back on each other. Partial answers forming. Odd song fragments , shopping list. And it results in the strongest or most coherent signal winning. Nobody’s issuing a `do_next()` call.
The sames true of immune systems, ant colonies, markets, fungal networks, and cities. They work not because something at the top issues sequential instructions, but because local systems react to local signals in ways that produce coherent large-scale behaviour. No conductor. Just a lot of very opinionated musicians who’ve figured out how to listen to each other.
So what I’ve been quietly building towards
Here’s the strange thing: parts of the programming world have been edging towards this for decades, largely without naming it as a coherent alternative model.
Dataflow programming where nodes fire when their inputs are ready rather than when the scheduler reaches them , has existed since the 1970s. Actor systems gives you independent workers that communicate by message rather than by being called and killed. Behaviour trees, common in game AI, let an agent weigh competing priorities rather than crawl through a fixed conditional ladder. Blackboard architectures allow multiple specialist systems to write partial conclusions to a shared workspace and let a resolver figure out what to believe.
Yet none of these replaced list-based code. Each got siloed into its own domain: shader graphs here, game AI there, distributed telecoms over there. We kept the list as the default and used the interesting stuff for niche problems. While ironically putting the interesting systems into organised lists for ease of classification.
Meanwhile, the problems that software is being asked to solve has become genuinely cognitive in nature. Autonomous agents. AI systems that need to explain their reasoning. Robots navigating real environments. Creative tools that adapt to context. These are not list problems. They’re cognitively ecology problems.
What graph-actor-blackboard programming actually looks like
Yet the alternative isn’t exotic. It’s a set of ideas that already exist, that work well individually, and that nobody has quite committed to assembling into a first-class programming paradigm.
The structure would have roughly four layers.
A dataflow layer handles movement. When new information arrives, it doesn’t go into a queue , it activates whatever nodes need it. Perception module, memory search, risk checker, domain specialist: they all wake up together. The program becomes with memory, inboxes, and defined responsibilities. A `ThreatActor`. A `MemoryActor`. A `TacticsActor`. Each one has a clear job and keeps its own local state.
A behaviour tree layer gives each actor judgement. Inside the actor, you still need structured logic. If this threat pattern is known, escalate. If evidence is weak, request more data. If uncertainty is high, hold position. Behaviour trees are excellent for this: they encode priorities cleanly without the fragility of nested conditionals.
And a blackboard layer gives the whole system a shared mind. Not random memory. Structured, typed memory where different actors post their partial conclusions:
CombatActor: attack, confidence 0.62. SurvivalActor: retreat, confidence 0.91. TacticsActor: move to cover, confidence 0.87.
Then a resolver looks at all of it and makes a decision. And here crucially, the resolver writes down why.
Get TABARC-Social’s stories in your inbox
Join Medium for free to get updates from this writer.
And here this last part isn’t a nice-to-have. It’s the whole point.
The explainability problem with magic-box architecture
One of the genuine and biggest failures of modern AI systems I think is they produce outputs from processes that are effectively unauditable. The neural net pushes numbers through a billion weight matrices and here’s the answer. Why? Unclear. Is that right? Well check for yourself, we have libraries full if books.
This isn’t inevitable. But it’s a consequence of architecture.
If your system has a blackboard with a structured record of competing claims, confidence levels, evidence sources, and resolver decisions, you can inspect what happened. You can ask: what made the system recommend this action? What were the competing interpretations? Which evidence dominated?
That’s not digital wizard magic. That’s just the engineering discipline applied to cognition.
I mean the legal system already figured this out centuries ago. Courts don’t just announce verdicts. They require the reasoning to be written down and survivable to appeal. The insistence that intelligent systems explain themselves is not a philosophical nicety. It’s a load-bearing requirement if these systems are going to be trusted with anything that matters.
Especially as it impacts so much of our life and systems.
The dangerous part
Ok so I want to be honest about the failure modes, because well this architecture can also become a spectacular mess.
Parallel systems racing to update shared memory without any conflict rules us a recipe for disaster, and absolutely will corrupt each other. Accidental and deliberate threat actors that spawn further actors without limits will consume all available resources. Resolvers that don’t have real diversity in their inputs — different data sources, different models, different verification methods — will give you ten voices saying the same thing with an AIs absolute misplaced confidence. That thought is not intelligence, human or otherwise. That’s a HR committee of people who’ve all read the same brief.
The biggest trap then is what we might call performative architecture. So you build twelve agents, name them all impressively, connect them with arrows, and feel like you’ve built something smart. But if they’re all powered by the same underlying model with the same trainings blind spots, then no you’ve built an echo chamber with extra steps. Again it’s not actually intelligence, it’s just a magic mirror on the wall.
Real diversity requires genuinely different organs: different tools, different data sources, different computational approaches, hard rules that certain actors cannot override. The ethics layer isn’t advisory. It’s a veto.
So where this leaves us
Linear code isn’t wrong. Tax calculations should not have moods. Banking transactions should not emerge from a negotiation between competing interpretations. Some things need to be exact, deterministic, and auditable in the traditional sense.
But for adaptive systems like AI, robotics, games, creative tools, automation that has to handle a messy world , the list is a category error. You’re not writing instructions for a machine to follow. You’re trying to build something that responds intelligently to a world that doesn’t hold still.
The shift is this. Traditional programming asks: what instruction comes next? The graph-actor model asks: what parts of the system should wake up now?
That second question is the right one for complex problems. It’s how brains work. It’s how immune systems work. It’s how every genuinely adaptive system in nature is organised.
The neural nets powering modern AI are already more like this internally than their external pipeline suggests. Input goes in, model processes it, output comes out. That’s linear framing. But underneath, attention mechanisms and mixture-of-expert architectures are already doing something more like a parliament than a procedure.
The next step is making the parliament visible. Auditable. Editable. Honest about when it’s uncertain.
Less magic box. More a working multi agency committee with a whiteboard and someone quietly checking the maths.
— — — — —
The ideas in this piece draw on established areas of computer science research: dataflow programming, actor systems, behaviour trees, blackboard architectures, and neuro-symbolic AI. And yes none of them are new. The argument is that we haven’t yet assembled them into a coherent alternative paradigm for the problems we’re now asking software to solve.
