From open source alternatives to Adobe and Microsoft to applications developed in just a few hours with artificial intelligence: software is entering a new phase. But as code becomes accessible to everyone, who guarantees quality, security, and accountability? And will the Cyber Resilience Act be enough to contain the risks?
The new frontier of software: you no longer need a large team to get started
For decades, developing a complex application required specialized skills, time, financial resources, and a structured organization. Creating a photo editor, a word processor, or a CAD tool meant facing a long development journey made of design, programming, testing, bug fixing, and maintenance.
Artificial intelligence is profoundly changing this scenario.
Today, a single developer can use an AI assistant to generate code, build interfaces, implement features, and accelerate tasks that in the past required significantly more manual work. In some cases, even those without traditional IT backgrounds manage to build working applications simply by describing what they wish to achieve.
It is the phenomenon known as vibe coding: a development approach in which natural language and generative tools take center stage in software production.
The trend no longer concerns only small websites, prototypes, or independent video games. It is beginning to affect applications that aim to replace established professional tools as well.
An emblematic example is ArtCraft, an open-source project that offers a suite of native applications written in Rust, aiming to cover areas ranging from photo editing to personal productivity and technical drawing.
The issue, however, goes far beyond a single project. ArtCraft is symptomatic of a broader transformation: the cost of producing code is decreasing, but the cost of verifying, securing, and maintaining it does not necessarily follow the same curve.
It is precisely within this gap that one of the most critical challenges for the future of software lies.
ArtCraft: from Adobe to Office, up to CAD
The ArtCraft project is interesting because it demonstrates how wide the scope of AI-assisted development tools is becoming.
The official catalog lists twelve applications, including:
- PhotoCraft, dedicated to photo editing;
- VectorCraft, for vector graphics;
- FilmCraft, for video editing;
- LightCraft, for photo management and processing;
- EffectCraft, for visual effects;
- DesignCraft, for page layout;
- PdfCraft, for PDF management;
- WordCraft, for word processing;
- GridCraft, for spreadsheets and data analysis;
- DeckCraft, for presentations;
- SoundCraft, for audio production;
- CADCraft, for technical drawing.
The project claims availability for Windows, macOS, and Linux, alongside WebAssembly versions in the browser for numerous applications. The choice of Rust aims to deliver native programs without relying entirely on a web container like Electron.
The documentation for CADCraft, for example, describes support for formats like DXF and reading specific DWG versions, alongside tools for layers, dimensions, blocks, and technical drawing.
These features make the project interesting, but they should not be interpreted as proof of equivalence with AutoCAD or other industry-standard professional applications.
As of October 12, 2026, the official catalog notes that several tools are still under development or in early alpha. The availability of a feature, declared support for a format, and the maturity required for production work are three distinct matters.
An editor that opens an image is not necessarily capable of properly handling all color profiles, layers, metadata, and professional formats. A spreadsheet is not equivalent to Excel unless it guarantees compatibility with complex formulas, macros, and business templates. And a CAD program does not become a full replacement for AutoCAD simply because it reads certain DWG or DXF files.
The official website also specifies that the applications are designed to run locally on the user’s files and to be controllable through automation tools.
The significance of the project, therefore, is not that legacy products have already been rendered obsolete. It is that a small entity can today attempt to build an entire family of applications across multiple operating systems at a speed that would have been far more difficult to achieve without AI.
For Adobe, Microsoft, Autodesk, and other vendors, this could become a new competitive factor. For users, it could translate into more choice, reduced reliance on subscriptions, and greater technological freedom.
However, the speed at which a product is born is not a measure of its reliability.
From gaming to professional applications: AI accelerates development
This phenomenon did not begin with ArtCraft.
In the video game industry, generative tools are already used to speed up code production, prototyping, content creation, and feature development. The result is a lowering of entry barriers: smaller teams and independent developers can attempt projects that previously would have required substantial investment.
This transformation is extending to management software, web applications, enterprise tools, plugins, automations, and desktop software.
The turning point is that AI is no longer used merely to suggest a function to a programmer. It can participate in building entire modules, edit across multiple files, fix errors, and utilize external tools to verify its work.
In other words, development is shifting from manual code writing to the supervision of an increasingly automated process.
This can yield enormous benefits. Enterprises can experiment faster, professionals can automate repetitive tasks, and small entities can gain access to tools they previously could not afford.
There is, however, a structural problem: generating code is increasingly easy, whereas proving its correctness still demands methodology, expertise, and time.
A program may work in a demonstration and fail under real-world conditions. It may correctly handle the standard case and behave unpredictably when receiving anomalous inputs. It may present a convincing user interface while containing authorization flaws, vulnerable dependencies, or inadequate data management.
That is the difference between a prototype and a professional software product.
Vibe coding: the problem is not AI, but the lack of control
Vibe coding is not inherently a flawed approach. Utilizing artificial intelligence to program can significantly boost the productivity of even experienced developers.
The risk arises when the ease of obtaining a result is confused with the ability to understand and control it.
An enterprise application is not just a collection of screens and functions. It must manage authentication, authorizations, sessions, errors, data, backups, updates, dependencies, and unforeseen conditions. Furthermore, it must be maintainable over time and patchable when security issues are discovered.
A particularly significant result comes from academic research.
The study Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, published in the proceedings of the ICML 2026 conference, evaluated twelve programming agent configurations on a benchmark of 186 development tasks drawn from real-world open-source projects.
The authors found worrying results regarding security: in one examined configuration, SWE-Agent with Claude 4 Sonnet, 57% of the solutions were functionally correct, but only 11.8% were secure according to the benchmark criteria.
These numbers do not mean that AI-generated code is always vulnerable, nor that the same percentage applies to every project. However, they demonstrate that code capable of fulfilling the requested function can still be insecure.
The risk increases when those using AI lack the skills to identify errors, do not subject the output to adequate testing, or deploy the product online without a verification process.
The problem, therefore, is not enabling everyone to program. It is confusing the ability to produce an application with the capacity to assume responsibility for what that application will do.
When software becomes a risk to users
A vulnerable application is not merely a mediocre product. It can become an entry point to steal data, compromise systems, interrupt services, or expose confidential information.
The issue is particularly relevant when software handles financial data, corporate documents, credentials, personal information, or critical processes.
In an ecosystem where thousands of applications, plugins, and components can be generated rapidly, it becomes difficult to know which were properly designed, which are maintained, and which were abandoned after the first version.
There is also an often overlooked aspect: an application is not composed solely of the code written by its author. It relies on libraries, frameworks, packages, APIs, build tools, and distribution systems.
Even a carefully developed project can be compromised by a vulnerable dependency or a malicious update.
Security must therefore be considered across the entire software supply chain, from design to distribution.
The Ledger case: security does not end in the code
News from October 2026 regarding Ledger hardware wallet devices highlights how important this perspective is.
According to The Verge, devices sold through a reseller were tampered with using unauthorized hardware components capable of intercepting sensitive information during setup. Reported losses exceed $86 million in cryptocurrencies. The same account reports that Ledger considers the reseller supply chain compromised, with no evidence that its own systems or devices purchased directly from the company were affected.
It is important to clarify that this episode does not demonstrate AI involvement. However, it is a concrete example of a general principle: trust in a product can be compromised at a different point from where it was designed.
In AI-generated software, the problem can manifest in different forms: a spoofed library, a malicious package, a tampered installer, a compromised update, or an agent authorized to perform excessive operations.
As the volume of produced software and the number of components used grow, so must the ability to verify the origin, integrity, and behavior of the product.
It is not enough to ask whether the program works. One must ask who built it, with what components, how it is updated, and who intervenes when something goes wrong.
SaaS and local software: is server-side really safer?
A widespread belief is that SaaS applications are inherently more secure because the code runs on the provider’s servers and is not distributed directly to users.
The issue warrants a distinction.
In a desktop application, part of the logic is distributed to the user’s device. This makes it possible to analyze binaries, observe program behavior, and, under certain conditions, reverse engineer part of its functionality. Reverse engineering can therefore be more accessible.
In SaaS, code remaining exclusively on the server is not normally delivered to the customer. This can better protect intellectual property and make it harder to replicate internal implementations.
However, code opacity is not a guarantee of security.
A cloud service can suffer from API vulnerabilities, authentication flaws, misconfigurations, multi-tenant isolation issues, compromised credentials, or data management defects. The fact that users cannot read the code does not mean they cannot exploit its vulnerabilities.
Local software, on the other hand, can be designed with robust architectures, restricted permissions, verifiable updates, and rigorous security controls.
The SaaS model offers tangible benefits in centralized patch management and infrastructure control. However, it also introduces greater dependence on the vendor, its systems, and service continuity.
Security depends on the threat model, architecture, and management processes, not merely on where code is executed.
For local applications, source code availability can also foster independent review, but only if someone possesses the skills and resources to examine it.
The legal core: is recreating Photoshop or Office legal?
The ability to develop alternatives to commercial products also raises intellectual property questions.
The answer cannot be reduced to a simple yes or no.
The European Directive 2009/24/EC on the legal protection of computer programs protects software through copyright, but distinguishes the expression of a program from the ideas and principles underlying its elements.
This means that independently recreating a functionality is not automatically equivalent to copying original code. The assessment changes, however, if protected code, graphic assets, documentation, or other protected elements are reproduced.
The Court of Justice of the European Union addressed these issues in Case C-406/10, SAS Institute v World Programming, distinguishing the functionality of a program from its protected expression.
Trademarks, licenses of component libraries used, and commercial presentation of the product must also be considered.
In the case of ArtCraft, the fact that an application positions itself as an alternative to Photoshop, Word, or AutoCAD does not in itself establish an infringement. Similarly, stating that code was written from scratch is not sufficient on its own to resolve every legal question automatically.
Specific evidence regarding code, assets used, licenses, and development methodologies would be needed to formulate a legal conclusion.
The most interesting point is that AI can make independent implementations of existing software cheaper to build. The technical possibility of doing so, however, does not eliminate statutory legal obligations.
Cyber Resilience Act: the European response to software proliferation?
This is where the discussion connects directly to the Cyber Resilience Act, the European regulation on the cybersecurity of digital products.
The CRA represents one of the European Union’s most significant attempts to address digital product security across their entire lifecycle.
The Regulation (EU) 2024/2847 entered into force on December 10, 2024. Reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026, while most requirements will apply from December 11, 2027.
The European Commission specifies that, when conditions are met, manufacturers must submit an initial notification within 24 hours of becoming aware of the event, and a full notification within 72 hours, followed by final reports as required by the regulation.
The principle is clear: security cannot be treated merely as a post-distribution fix. It must be integrated into design, development, vulnerability management, and maintenance.
For covered products, manufacturers must also determine and communicate a support period during which vulnerabilities are effectively handled. Generally, the period is at least five years, unless the expected operational lifetime of the product is shorter.
This is a significant shift for a market accustomed to delivering software that, in some cases, comes without a credible maintenance plan.
The CRA does not ban vibe coding
It is essential not to attribute goals to the regulation that it does not have.
The Cyber Resilience Act does not ban the use of artificial intelligence in software development, nor does it introduce a general licensing requirement for software developers.
Instead, it acts on products falling within its scope and on responsible economic operators, imposing security requirements and vulnerability management duties.
Code generated by an AI model enjoys no special exemption: if it forms part of a product subject to the regulation, its generation process does not remove the applicable product obligations.
At the same time, not all software is automatically subject to the CRA. Scope depends on the regulatory definition of a product with digital elements, how it is made available on the market, and potential exemptions. An evaluation must therefore be made case by case, without asserting that every website, internal script, or custom application must follow the exact same compliance pathway.
The connection to vibe coding is nonetheless obvious: as software production accelerates, the capability to document, verify, and maintain products becomes even more critical.
For this reason, the CRA could contribute to reshaping the market, placing greater weight on security skills and process quality rather than sheer development speed alone.
To explore the regulatory framework in detail, the official text of the regulation can be consulted on EUR-Lex.
How to stem the risk without stalling innovation?
It would be unrealistic to attempt to stop AI in software development. Nor would it be desirable to forego the benefits it offers.
The answer lies in a combination of technical, organizational, and regulatory controls that make it harder to distribute vulnerable products without penalizing those who use these tools properly.
- Independent testing and review. AI-generated code should be subjected to automated testing, static and dynamic analysis, dependency checks, and, where risk warrants it, independent security audits.
- Supply chain management. It is essential to know which components are used, where they originate, and how they are updated. Software bills of materials, digital signatures, and verifiable release procedures can reduce tampering risks.
- Least privilege for agents. AI agents that read files, execute commands, or modify code should operate with minimum required permissions. Potentially destructive or sensitive actions should require explicit approval and safeguards.
- Real maintenance. A product should not be considered finished upon initial release. Procedures are needed to receive vulnerability reports, patch security flaws, ship updates, and communicate end-of-support schedules.
- Transparency for buyers. Users should be able to assess maintenance commitments, security policies, update mechanisms, and vendor accountability.
These principles align with the CRA approach and research recommendations regarding agent-generated code security. The goal is not to slow down every project with disproportionate bureaucracy, but to match controls to product risk.
A personal prototype and an application managing healthcare data or financial transactions should not be subject to the same level of auditing. However, even an apparently simple product should not be distributed without considering the risks it introduces.
The future: code will become a commodity, trust will not
ArtCraft may not become the new industry standard. Some applications may mature, others stall, and still others be overtaken by competing projects.
Its significance, however, does not depend on the commercial success of a single suite.
If increasingly capable AI tools allow small teams to build complex applications, the market could witness an explosive growth of vertical software, open-source alternatives, automations, and custom products.
This could put pressure on traditional subscription models and reduce lock-in to a few large vendors.
Yet it could also multiply abandoned, duplicated, or unmaintained products. Source code availability does not guarantee that anyone inspects it, just as the ability to generate an application does not ensure an organization exists to sustain it.
Professional value may therefore shift further from mere code writing toward architecture, system integration, verification, security, risk management, and long-term maintenance.
The Cyber Resilience Act fits into this landscape as an attempt to make security an integral part of product responsibility. It will not solve all vibe coding risks on its own, but it introduces a principle destined to weigh heavily in purchasing and development decisions.
The challenge will be avoiding two extremes: on one side, choking innovation with onerous burdens; on the other, accepting that easy software production justifies distributing unverified products.
And what awaits us tomorrow?
Artificial intelligence could eventually build increasingly complete applications, autonomously correct some of its own errors, and manage entire development workflows. It could also enable single individuals to launch products that currently require structured organizations.
But will it really be possible to entrust the independent security verification of generated code to the exact same AI?
And who will guard the guards?
A potential direction is the systematic integration of verification agents, automated testing, dependency scanners, provenance checks, and independent audits. These tools can mitigate risk, but they do not remove the need for clear accountability and verifiable acceptance criteria.
The issue is not preventing anyone from creating software. It is ensuring that anyone can experiment, while those distributing products for public use can prove their quality and stand behind issues that arise.
ArtCraft demonstrates how low the barrier to entry for production has dropped. Vibe coding research reminds us that functionality and security are not the same thing. The Cyber Resilience Act attempts to translate this awareness into concrete requirements for products within its scope.
The question, then, is no longer merely who will be able to write the next program.
When anyone can create software, who will be able to guarantee its security, quality, and long-term sustainability?
It is likely on this answer that a major part of software’s future will depend.
