Full article with diagrams: https://medium.com/@toplinesoftsys/security-armageddon-is-here-e44141fb3914

The Problem

AI reached a level of code analysis sophistication where it can find software vulnerabilities in seconds. Developer and content creator Theo (t3.gg) explains the problem in vivid detail: https://www.youtube.com/watch?v=M_HxHr7du5M. The short version: three assumptions that kept software security working for decades are now dead.

The first assumption: only well-paid experts could find exploits. This was always what limited the number of attackers. AI killed this barrier entirely. Anyone with enough compute and a model can now find vulnerabilities in real software in a matter of minutes.

The second assumption: the 90-day coordinated disclosure window was long enough. When a vulnerability was found, maintainers had 90 days to patch, distribute, and get most users updated before public disclosure. This relied on the first assumption. Without it, the window collapses. Two independent researchers found the same massive Linux kernel exploit within 9 hours of each other.

The third assumption: going from a patch to a working exploit was difficult. Maintainers used to quietly merge security fixes with nondescript commit messages, buying time before attackers figured out what was being patched. AI ended this too. Feed a four-line code diff to any major AI model and ask if it looks like a security patch. Two out of three major models get it right from the diff alone, without even reading the commit message. The pipeline from patch to working exploit is now automatable.

The result: every piece of software, and especially open-source software, is now exposed to zero-day attacks at a speed and scale the industry has never seen before. Further AI improvement will only make this worse. The speed of vulnerability discovery keeps rising. The speed of patching stays roughly constant. The gap between them is widening every month.

Why Conventional Responses Are Not Enough

Patching Faster

The most obvious response is patching faster. If AI can find vulnerabilities faster, use AI to patch them faster too. This helps at the margins. But it does not change the fundamental dynamic: the attack surface stays the same size. Every patch closes one vulnerability. AI scanners immediately move to the next one. Patching faster is running harder on a treadmill, not getting off it.

Getting Rid of Open-Source

A more drastic option: end open-source. If source code is not public, AI cannot analyze it directly. In the very short term this might slow things down.

It would not stop AI for long. Without source code, AI can reverse-engineer binaries. Obfuscation can slow that down, but then we are in a perpetual race between AI obfuscating code and AI deobfuscating it, with no clear winner. If software runs only on the backend and is never distributed at all, the attacker’s last resort is probing the backend through its public interface with specially crafted requests. AI is extremely good at this too.

We all love open-source. It is one of the most productive forces in the history of software. Closing it would be a massive sacrifice with limited security gain. The answer is no.

The Root Cause: Too Much to Attack

Patching faster and hiding source code both try to win the same race against AI. Neither addresses why the race is so difficult to win in the first place.

The real problem is the size of the attack surface. A typical production application imports hundreds of third-party libraries. Each library imports dozens more. The total code surface available for AI to scan is orders of magnitude larger than the code the developer actually wrote. Most of it has never been read, much less audited, by anyone on the development team. It is all publicly available, continuously scanned, and growing with every npm install.

Attackers are not primarily targeting code developers wrote. They are targeting code developers trusted. The 84 Tanstack packages recently compromised in a supply chain attack, the CopyFail exploit distributed through Python libraries, the CI pipeline attacks: all of them exploited the dependency supply chain, not the application logic.

If we cannot win the race by running faster, the answer is to shrink what we are racing to protect.

Making Software Easier to Patch: The Visual Programming Direction

One practical step is making applications easier to patch by splitting them into small, independently replaceable components. Plugin architectures do this. Smaller components have smaller attack surfaces and can be patched without touching the whole system.

This helps, but it has limits. Plugins still depend on third-party libraries, so the attack surface does not actually shrink. And plugin systems carry their own costs: cognitive overhead, compatibility management between plugin versions, and debugging complexity that grows with the number of components.

Visual programming languages (VPLs) are the logical extreme of this idea, and they solve the problems plugin architectures create.

In a VPL, every block on a diagram is effectively its own independently replaceable component. But unlike text-based plugin systems, a VPL provides full transparency: the logic of the program is the diagram. Any developer can look at it and understand what the program does without reading code. Replacing a block requires no recompilation. It only needs to be compatible with the blocks immediately connected to it. In terms of patching speed and ease, drag-and-dropping a new block into place is as good as it gets.

The same independence that makes blocks easy to replace also makes them easy to isolate. If a component is found to be compromised, the affected block can be disconnected or disabled immediately and interactively without recompilation, limiting the impact to the rest of the application while a fix is prepared.

Transparency also matters for security beyond patching. In a text-based system, the logic connecting components is itself code that must be read to understand. In a visual program, the connection logic is the diagram. It cannot hide. There is no ambiguity about what connects to what.

Composable Blocks and the Visual Hierarchy

A well-designed VPL goes further than a flat diagram of blocks. Blocks are composable: any block can contain other blocks inside it, forming a hierarchy of arbitrary depth. High-level business logic sits at the top. Each block can be opened to reveal its internal workflow. The hierarchy goes all the way down to the bottom level, where blocks contain no further sub-blocks. These are called leaf blocks, and they are the only place in the hierarchy where code lives.

This composability is what makes a VPL suitable for large, complex applications rather than toy examples. The top-level diagram stays clean and readable. Complexity is encapsulated inside blocks. Any level of the hierarchy is independently replaceable without touching the rest.

The VPL Security Model: Shrinking the Attack Surface

Third-Party Libraries as Visual Workflows

The conventional assumption is that a visual application replaces all third-party libraries with AI-generated code. This is unrealistic. Libraries contain too much accumulated functionality to regenerate from scratch.

The realistic model is different: third-party libraries are themselves visual workflows. A library in the VPL ecosystem is a visual workflow with a thin layer of code at the leaf blocks for OS interaction. The application is a mix of its own visual workflows and the visual workflows of the libraries it uses.

This changes the security picture dramatically. When a vulnerability is found in a third-party library, the developer has two options. The first: go directly into the library’s internal visual workflow and fix or isolate it in-place. The library is fully transparent as it is built using VPL, so the problematic location is immediately visible and the change is auditable. The second: wait for the library maintainer to release a patched version, then update by dragging and dropping the new block into place. No recompilation, no regression risk in unrelated code.

Either way, the process is faster, more transparent, and more controlled than patching text-based library dependencies where the internals are opaque and touching one thing risks breaking another.

The Leaf Code Layer: Where Vulnerability Lives

At the bottom of the visual hierarchy sit the leaf blocks. This is where code lives rather than sub-blocks. Leaf code is responsible for low-level operations: interacting with the operating system, reading files, opening network connections. This is the only place in a visual application where text code is strictly necessary.

Leaf code can call third-party text libraries, as any code can. But developers should minimize these dependencies wherever practical. The thinner and simpler the leaf code, the smaller the attack surface.

The first level of dependency reduction is AI code generation. If a potential third-party dependency is simple enough, AI can generate the equivalent code directly rather than importing an external library. This eliminates that dependency entirely: the generated code is purpose-built and never publicly available, giving AI scanners nothing to analyze.

The second level, as AI capabilities grow, is direct visual workflow generation. Rather than generating text code, AI will be able to generate complete visual workflows with a thin leaf code layer. This makes dependency self-production an even more attractive option: the generated component is not just functional but transparent, composable, and fully auditable as a visual workflow.

Where third-party dependencies are unavoidable, developers should prefer VPL-based libraries over text-based ones. A VPL-based dependency is itself a transparent visual workflow, patchable by drag-and-drop. Its attack surface is significantly smaller than an opaque text library of equivalent functionality.

When all these practices are applied together, the application approaches the ideal state: no or minimum third-party library dependencies and maximum use of VPL-based libraries, with the attack surface reduced to the operating system or close to it.

Why Pipe Is the Right VPL

The Gap No Existing VPL Has Closed

Visual programming languages are not new. LabVIEW has dominated engineering for four decades. Simulink is standard in aerospace and automotive. Node-RED is widely used in industrial IoT. Unreal Blueprints works for game development. None of them can serve as the general security architecture described above. They are either domain-specific, too limited for production software, or both.

A VPL that can meaningfully reduce the attack surface of production applications must satisfy two requirements at the same time: general-purpose to be applicable to any domain, and sophisticated enough for real-world production code.

Pipe (pipelang.com) is a general-purpose visual programming language designed from the ground up to satisfy both requirements simultaneously. It is a VPL built to be both general-purpose and sophisticated enough for production-level software across any domain. Seven years of architecture development and ten provisional USPTO patent applications underpin this design. The complete language specification is freely available at pipelang.com.

How Pipe Implements Block Interfaces: Domains and Overlaps

In Pipe, each block input is analogous to an independent API endpoint. The interface of that endpoint is defined by a domain: a hierarchical data structure, a tree where each node can have both a value and children, similar to JSON but more expressive. Domains are assigned to block inputs and outputs. When two connected Pipe blocks have different domains, Pipe resolves this through overlaps: it finds matching tree paths between the output domain and the input domain, and transfers only data where paths match. Unmatched nodes take explicitly defined or implicitly assumed default values.

The result is that almost any two Pipe blocks can be connected regardless of interface mismatch (with some exceptions such as data type compatibility between source and destination domain nodes). The domain overlap mechanism provides the flexibility of connectivity that makes Pipe practical at scale. And because Pipe enforces this at the structural level, no developer validation code is needed at block boundaries. The interface contract is guaranteed by Pipe itself.

Addressing the Drawing Effort Concern

A common concern about visual programming is that drawing diagrams takes more effort than typing code. This is worth addressing directly.

Pipe diagrams are more compact and expressive by design. A block requiring multiple input parameters does not need a separate connection for each one. Each block input is a single domain connection that carries all relevant parameters together. A block with seven input parameters still has one input connection, not seven - the domain provides all seven values through that single connection. The diagram stays clean even as the underlying logic grows.

Beyond compactness, Pipe diagram modifications can leverage AI directly. Workflow changes - adding blocks, rerouting connections, restructuring logic - can be expressed in natural language, typed or spoken, and applied to the diagram without manual drawing. The effort of diagram maintenance converges toward the effort of describing what you want, which is not fundamentally different from writing text code.

The Security Spectrum

Not every application can immediately adopt Pipe with thin leaf code. But every step toward that architecture is a genuine security improvement.

• Step 1. Open-source text code with libraries: entire source code and all dependency sources available for AI analysis. Maximum attack surface.
• Step 2. Closed-source text code with libraries: source hidden but binaries reverse-engineerable, APIs probeable. Libraries still fully exposed.
• Step 3. Pipe with some traditional text libraries: attack surface dramatically reduced. Remaining text code libraries still represent risk.
• Step 4. Pipe with visual library workflows and thin leaf code: no or minimum third-party library dependencies, only VPL-based dependencies where they are present. Attack surface reduced mostly to the OS.

The last step is the target state. It is not necessary to reach it immediately or completely. Moving partway toward Pipe with thin leaf code is a meaningful structural improvement over a conventional text-based architecture.

Conclusion

AI made vulnerability discovery fast, cheap, and accessible to anyone. Patching faster helps but is not a structural solution. Getting rid of open-source would be a sacrifice not worth the limited gain. The real answer is to reduce the attack surface itself.

Pipe, with third-party libraries also represented as visual workflows and a thin leaf code layer for OS interactions, achieves this. It makes the logic of the program transparent and auditable at every level. It makes isolation immediate, and patching faster and safer. It eliminates third-party library supply chain risk. And it shifts the remaining vulnerability to the OS layer, where it is maintained by the OS vendor.

As AI generates more code faster, the need for VPLs such as Pipe will grow. The goal is not to eliminate all vulnerability. The goal is to make software structurally harder to exploit. When the only attack surface left is the operating system, that goal has been achieved.