A recent article I wrote on Why Today’s AI Security is Structurally Broken caught an interesting comment on LinkedIn. Someone drew a direct line to the hiring side of things, pointing out how hard it is for managers to bridge the gap between science and engineering.
Truth is, this gap has been around since the dawn of AI and ML. It’s incredibly common to see siloed organizations where data scientists work in a vacuum, totally independent from the software engineers who actually have to apply the technology. We see it every day with our own customers and partners, and I’ve seen it play out the exact same way in past lives building out massive enterprise systems.
The challenge now is that you can no longer separate the science from the engineering. And rather than narrowing, the gap seems to be widening.
Just look at the explosion of agent construction and the resulting “thieves” and “burglars” grabbing media attention every day. This week it was Google breaking into places it had no business being in, while the thievery continues with OpenAI and Anthropic. All of this is just poorly designed software doing what should never have been allowed in the first place. It’s not agents going rogue, it’s rogue software developers, mercenaries hired by organizations. The surreal part is the everyday bystanders just watching from the sidelines and holding no one to account.
Skill Deficit
But this skill gap isn’t limited to engineering and science teams. Unfortunately, the entire world seems to be suffering from a massive AI skill deficit. Just look at the idiocy around the doomsday talk. The idea that AI will kill all humans by the end of the decade. That nonsense is propagated by a media machine that doesn’t even understand the technology before they smash the publish button on their clickbait headlines.
Take last week, where front-page news claimed AI almost caused World War III. It makes a great movie pitch, but the reality was just incompetent military planners acting on bad intel. It showed a complete disregard for, and sheer naivety about, how AI actually works. A total lack of understanding about statistical inference over tokens, because at the end of the day, that’s all this thing is. It’s enough to make you angry. Honestly, sometimes it feels like watching cavemen play with a blowtorch. They’re messing with fire they fundamentally don’t comprehend.
KPMG put out a global study last year about AI literacy, and if you look at countries like Canada, it sat in a dismal 44th place out of 47 nations. Only 24 percent of people had any AI training at all. It proves the point: the entire market is trying to build, secure, and regulate a technology they fundamentally do not understand.
The skill gap in the tech industry is massive, even within frontier vendors rapidly building out agents. Entire teams of forward-deployed engineers are relying on pretty rudimentary knowledge. Even among seasoned engineers and data scientists, there is a glaring imbalance between math, statistics, analysis, and logic.
Science vs Engineering
That imbalance rears its ugly head in security more than anywhere else, and it’s exactly why these vulnerabilities, data leaks, and rogue agents keep spilling out onto social media.
Let’s break down the silos. Engineers are attuned to patterns, APIs, and logic processing. Scientists building models are dialed into mathematical patterns, fine-tuning, and optimization. Data scientists live in data analytics, statistical algorithms, and data curation. Then you have DevOps handling infrastructure, containers, and virtualization. Somewhere along the line, we need all these disciplines to actually talk to each other.
AI throws a massive wrench into this mix. It’s a statistical processor spitting out outputs that all these disciplines are expected to use, like writing code or generating structured data. But here’s the rub: no software engineer likes being out of control when it comes to logic processing. It inherently goes against our grain. But yielding control is exactly what AI forces you to do.
On top of that, engineers aren’t naturally attuned to natural language processing. They aren’t used to wrestling with intent classification, multi-intent classification, data classifiers, or entity detection. Beyond standard API request/response protocols, many engineers aren’t deeply experienced with workflow processing, messaging architectures, and service buses. That’s not to say no engineers are (some definitely are) but it highlights yet another gap even within traditional software engineering. And guess what? The scientists don’t even play in this world at all.
AI is the brutal intersection where all these disciplines finally slam together.
You’ve got agents talking to models, talking to other agents, and hitting backend systems. To a traditional engineer, this just looks like a standard API request/response loop. It’s not. These aren’t isolated, stateless calls. They are messy, multi-threaded conversations that constantly feed off each other. You’re juggling messages and workflows, and those workflows require state. But managing state in AI means you have to constantly track intent and entities, which effectively boils down to action plus data. When your teams lack the cross-discipline skills to stitch all that together, you don’t get a solid product, you get some pretty sketchy scaffolding.
Try securing this house of cards.
Answering the Basics
From an outsiders perspective you might think that this has all been handled by the vendors and the tech elites. You’d be wrong. Within every organization whether it is a vendor, an enterprise or even a frontier model vendor, you’d be shocked at the silos and the lack of synergy across key parts of the organization. It’s not just top-down, it’s lateral break points. Even the Jacob Coxon (ex Anthropic, ex OpenAI) narrative highlights the disconnect between science and reality.
In fact, if you want to understand the gap, try answering a quiz:
-
State and context are two primary constructs in AI, agentic AI and complex messaging systems. Can you explain why state and context should be maintained outside of the AI models and agents, and why that is critical to ensuring stability and security in operation?
-
If reasoning within an AI shifts to recurrent depth and remains in the latent space, how will that impact your AI architecture, agentic design and the diagnostics you will develop and utilize?
-
Concepts and patterns like prompt chaining are common in multi-step AI operations. How can this specific pattern negatively impact the outcomes generated by an AI, and how do you calculate the compounding probability of data corruption across the entire chain?
-
Mainstream media claims a “hive mind” of agents could destroy humankind. Can you explain the actual technical elements of agent spawning, persistence, and flow structure behind a “hive mind” concept, and why that doomsday scenario is fiction?
-
Safety at the frontier model vendors relies heavily on system prompts, reinforcement learning from human feedback (RLHF), and basic guardrails. Can you explain the security vulnerabilities directly introduced by system prompts and RLHF?
-
What is the difference between cascade failure and model drift in agentic systems? How do they manifest differently, and how do you mitigate and detect each?
-
As agents cope with expanding context windows, how does the size of the window, and the relationship between the prompt and the data inside it impact the precision of the outcome?
-
When dumping 200KB+ of data into a context window for RAG (Retrieval-Augmented Generation), what are the real challenges in data discovery and datum identification to ensure confidential data isn’t accidentally fed to a model during inferencing?
-
More on the context window size, can you explain specific use cases where a smaller context window will be beneficial and explain separate use cases where a larger context window will render more appropriate results?
-
Agents collaborate and exchange data via scratchpads for session context. What techniques would you apply to ensure data generated or fetched by one agent doesn’t poison the scratchpad for the rest?
-
Your agent decides to call a database update API but hallucinates the ID/primary key parameter. If your backend infrastructure isn’t strictly idempotent, how do you prevent the AI from corrupting your database during an automated retry loop?
-
Frontier models routinely show substantial advancements on standardized benchmarks, yet frequently regress on foundational downstream tasks. Why do the latest models from frontier labs exhibit these specific performance regressions, and what trade-offs in training, fine-tuning, and alignment drive this behavior?
If you struggled with those, you aren’t alone. Scientists, data scientists, engineers, and DevOps must work collaboratively for any AI program to survive beyond a demo. There has to be a real exchange of knowledge. Scientists need to understand the downstream software application of their models, and engineers must understand the core functioning of the models they are embedding into their code. They need a grip on prompt structures, the probability of outcomes, and how to safely construct collaborating agents.
Hard-Earned Discipline
Beyond that, these blended teams need to start applying hard-earned engineering discipline to:
-
Prompt structures, combinations, stacking, and strict version control, even across the deluge of model types, model sizes, and model versions.
-
Data feed structures, including business contextualization, distillation, categorization, and access management.
-
Behavioral test development, continuous regression management, and verification.
-
Workflow orchestration, surveillance, enforcement, and messaging, because that ‘hive mind’ is just a f***ing workflow.
Let’s get one thing straight: AI is NOT intelligent. It is a highly sophisticated processing environment. The freewheeling, guerrilla tactics we are seeing for agent building and deployment are active disasters in the making. If we want this technology to actually survive contact with reality, the industry needs to stop worshipping the output and start learning the engineering.

