AI broke cybersecurity: code is written faster than we can review, detection is blind, and patching is too slow. Visual language Pipe fixes all three—code becomes reviewable by construction, and every block stays observable and patchable at runtime by design.

AI shook the very foundation of cybersecurity. It upended established practices and assumptions. Anyone can now use AI to scan code and find vulnerabilities quickly. What’s even worse, bugs found during one pass of AI code scanning might not be reported after rescanning. This is because of the probabilistic nature of AI – it gives a different response to the same prompt. It means that someone can find a zero-day vulnerability that may not be rediscovered on a later scan, even using the same AI model and identical source code. This could let one person discover and exploit a zero-day that others never see.

Cybersecurity problems are quickly growing in many cybersecurity-related aspects simultaneously. Let’s focus on three of them. They are: (1) AI generates code faster than teams can review it; (2) runtime threat detection is unreliable; and (3) patching is too slow. I will divide the analysis into two stages: development (design-time), and production (runtime).

Problem 1 – Development: code faster than review

A problem AI brought to development impacts cybersecurity indirectly, but it is still a significant threat. AI generates code in huge amounts so fast that development teams cannot review it in a reasonable time. Add to this the pressure on development teams to deliver productivity gains due to AI implementation, and the situation becomes even more dire. Teams have no choice but to skip detailed review, approving PRs automatically. This results in bugs slipping into the codebase and eventually causing crashes and vulnerabilities in production.

The most popular proposed solution is using AI for code review. Essentially, we are going to use AI to review code produced by another AI. There are problems with such a solution due to certain properties of AI itself. The main issue is that AI is bad at handling big context: the longer the task or instructions you give it – the more it hallucinates and the more sharply it degrades on a very large context. I face this problem all the time when trying to ask AI to generate code for even a modest, clearly detailed specification - AI skips, misinterprets and deviates from the specification a lot. The workaround is to have AI generate only scaffolding and continue step-by-step in a tool like Cursor – which proves the point: the model can’t handle the whole codebase. A codebase is a very large context for AI. Are we confident enough to trust AI 100% that the quality of its code review will be comparable to a human’s, even after multiple rounds? Probably not, and this is why human eyes are still needed. It means we are back to square one - dealing with an enormous wall of text code.

Now we will look into the production post-deployment stage. There are two closely related problems there: one is about the reliability of threat detection, and the other – the speed of reaction to an attack.

Problem 2 – Production: detection is blind

Let’s start with detection. The single source of information about what’s happening inside the application is log data. Log statements are pre-placed by developers in source code locations where they think it is necessary. Very often, needed log statements are missing and therefore, any threat detection system (no matter if it is AI-driven or not) can be blind to certain types of attacks. We cannot blame developers for that, because they cannot predict the future. This is the failure of the observability process relying solely on logs to get runtime information about application behavior.

Problem 3 – Production: patching is too slow

Another problem is a reaction to a known attack or vulnerability. The standard process is going back to source code, investigating the problem, changing the code, approving/merging a PR and deploying via CI/CD. The whole process might take days or weeks, even if a new deployment starts fast. The deployment itself might take several days, because often, deployment stages have heavy tests attached that need significant time to complete execution. I worked for companies running complete application tests on every deployment stage to ensure the highest quality of the deployment, but at the heavy cost of the speed. The question is what the production team is going to do while waiting for the fix deployment. They have two choices. One is just waiting, assuming that nobody will exploit the discovered vulnerabilities and data will not be stolen as a result of it. This might be true in the pre-AI era. However, the frequency of AI-driven cyberattacks is growing very fast, and we might not be able to afford to wait today – the risk of losing data is much higher. An alternative is shutting down the whole system or a large independent module while we wait for the fix. However, it will break the continuity of the business. As we can see, both options are bad.

So, we identified three problems – one during development (AI code is generated too fast), and two during production (detection is unreliable and patching is slow). There is a variety of tools and approaches trying to solve these problems. However, their reliability and simplicity are questionable. For example, we can try to disable a certain part of the application using feature flags and tools like LaunchDarkly. However, the whole process of feature flag management is complicated, and it gets exponentially complex as the number of feature flags increases. We need to test many combinations of feature flags during deployment so that we can be confident switching them live on production does not break the application. I worked in companies that used feature flags, and they had a policy to remove a feature flag as soon as it is no longer needed to avoid the complexity of deployment tests.

One solution for all three: visual programming

There is one approach that fixes all three problems at once: visual programming – and I am working on such a solution. This is an unusual combination, but such an approach was proposed before. What’s different this time is a more powerful visual language “Pipe” I designed. This visual language combines two properties not usually seen together in other VPLs: generality and power. Usually, relatively powerful visual languages are domain-specific, while general-purpose languages are pretty simple. I spent 7 years closing this gap and designing a VPL that has both properties together. The reason we need a VPL to be general-purpose and powerful at the same time is that all text-based languages have both properties, and that’s the reason they dominate. Just to have a real opportunity to absorb a part of text code (no visual language can fully replace text code, even Pipe), a VPL must have similar properties to text-based programming languages. Let’s see how Pipe solves the three problems outlined above.

How Pipe solves each problem

The first problem is that it is humanly impossible to review huge amounts of AI-generated code in a reasonable time. This application of VPL is obvious – visual logic is much easier to grasp. VPL does not solve the problem completely, but it mitigates it. As I mentioned before, no VPL is able to fully replace text code, so it will be a mix of visual diagrams and text code. The bigger the proportion of logic moved to visual diagrams from text code, the bigger the benefit of reviewing logic visually is going to be. AI will be generating visual diagrams with some code inside, instead of 100% text code as it does now.

The other two problems (observability and patching) rely on the same property of Pipe – its powerful semantics allows it to keep the visual graph not only during development, but also on production. The reason semantics needs to be powerful enough for this is that otherwise a VPL needs to be translated to a text language to fill missing details in text code, because the VPL itself is not powerful enough to cover it with visual code. So, the deployment chain in this case goes via text, losing the visual graph.

Having a full visual graph on production allows direct access to visual blocks. This has profound consequences both for observability and patching. Observability can be dynamic by tapping monitoring directly into the inputs and outputs of any block at any time right on production, in real time, replacing or complementing log data. Patching also becomes faster because the block can be patched, disabled or rerouted directly, right on production.

A concrete example: a payment-validation block starts leaking customer data. Today a team files a ticket, changes the code, runs the full test-and-deploy cycle, and hopes no one exploits the hole in the meantime. With Pipe, an operator taps that block’s inputs and outputs, confirms the anomaly in real time, and reroutes traffic to a safe fallback block in seconds – while the permanent fix goes through normal CI/CD. The vulnerability is contained immediately; the business keeps running.

Isn’t changing production live dangerous?

I anticipate a very reasonable objection that direct modification of application behavior on production is dangerous and it can cause cascading failures. This is an absolutely legitimate concern. There are two possible solutions.

One solution is separating eventual problem solving and immediate reaction. For example, we can disable a single block or a group of blocks related to just one application feature, not impacting the rest of the application. At the same time, we ask developers to start working on a fix that will go via a normal CI/CD cycle. This way, we do not have to choose between two bad options: shutting down the whole application or assuming nobody will hack the system while a fix is in the works. What Pipe offers is the third option – shutting down or rerouting a vulnerable or dangerous part of the application temporarily, while we wait for a fix. Having such abilities requires a prepared manual giving clear instructions on what to disable in specific situations – developers must prepare such manuals. The good news is that it should not be a burden as AI will be able to help here.

Another solution is building a more sophisticated delivery process with testing right on production, leveraging direct access to blocks to tap the test suite into inputs and outputs, sending testing data to inputs, and analyzing responses from outputs. This process does not necessarily have to fully replace a normal CI/CD deployment – it can complement it to ensure the quality of the direct fix until a new CI/CD deployment arrives.

The key idea of defense against AI-driven cybersecurity attacks is also using AI. However, AI for attack is different from AI for defense. AI for attacks must exploit just one vulnerability – a physical analogy is a sharp, pointy spear. AI for defense must be solid and without holes (a shield), because we do not know beforehand where precisely an attack (a spear) is going to hit. However, AI built on top of existing systems will have lots of holes in the shield, and patching these holes will be slow.

The hot trend today is self-healing engines – an intelligent AI layer on top of the application, detecting attacks and reacting to them automatically. There are two key requirements for such an engine: reliable detection and real-time reaction. However, it is very hard to satisfy these requirements in current systems due to the reasons outlined above: detection is unreliable as the engine can use only fragmented data from logs (shield holes), and reaction is slow as the fix needs to go via the full CI/CD deployment (slow patching of shield holes). What Pipe offers is a solid foundation for such self-healing engines providing reliable detection and fast reaction.

Doesn’t this mean rewriting everything?

The most frequent argument I hear against Pipe is that it requires rewriting existing applications – it is true. However, Pipe only complements text code, mixing visual logic with text. It means that migration does not need to retire the existing codebase immediately. Instead, the migration can be gradual – starting by encompassing the whole application or module in one root Pipe block. Then, whenever ready, moving one step below and distributing text code inside the root block between visual blocks of a second-level workflow, etc. You can stop subdividing blocks at any point, so it's entirely your decision which parts of the system become visual and which remain as text. Pipe provides a complete API for integration with text languages as part of the specification. Also, AI can automate workflow generation, text code distribution between visual blocks, connectivity, and layout of all visual components.

Like everything else in engineering, Pipe has its upsides and downsides. The biggest downside is the need to rewrite existing applications. However, there is also a significant upside – solving three critical cybersecurity issues all together, by the design of the solution. Considering the explosion of AI-driven cybersecurity threats, the current security model might already be outdated and we need to change it. So, weighing upsides against downsides, the upsides definitely win.

Can we create runtime components from text code?

Yes – and it has been tried many times. But every time, managing those components gets complicated: the more you have, the more complex the web of their interactions becomes. The winning combination isn’t just highly granular software in production – it’s also a visual representation that makes all the relationships between them visible. This matters for both observability and patching: the visual graph shows you exactly which components to tap into, and which blocks to patch, disable, or reroute.

Why now

Computers of the 1970s and earlier had only a text-based terminal interface requiring knowledge of specific commands, so the UI was very unfriendly. The GUI revolution brought windows, icons, buttons, and other graphical elements. This made computers much more accessible to users. However, programming did not make this transition, and we still program using text only. AI is the catalyst that finally forces the move to visual programming – not because it’s nice to have, but because we no longer have a choice.

Website: https://pipelang.com

Pipe IDE URL: https://www.pipelang.com/pipe/v1/

Tutorials:

  1. Data Swap – https://www.pipelang.com/assets/tutorials/v1/tutorial1.mp4
  2. Reusable Sum – https://www.pipelang.com/assets/tutorials/v1/tutorial2.mp4
submitted by /u/PurpleDragon99
[link] [comments]