SaaS isn't measured by the number of lines of code delivered
In a custom-built application, the team mainly produces code. The specification describes the expected behavior, agents can generate the components, then the CI/CD chain verifies and deploys the result. This is the principle of Niji ARC™.
A SaaS solution is already built and operated by a vendor. The project team adapts it by combining configuration, metadata, extensions, integrations and, when necessary, custom code. The solution must stay close to the standard to benefit from updates and avoid excessive custom debt.
The point is therefore not to mechanically transpose AI-native delivery practices. It is to adapt them to a platform whose behavior is partly described declaratively and sometimes modified directly in an administration interface.
SaaS and custom-built: two delivery models
A custom-built application lets you decide almost everything, at the cost of a significant design, development and maintenance effort. A SaaS solution provides a rich standard, but imposes its concepts, its security model, its limits and its roadmap.
| Dimension | SaaS solution | Custom-built solution |
|---|---|---|
| Starting point | A standard product already operated by a vendor | A technical foundation to design or assemble |
| Customization | Configuration, metadata, extensions and integrations | Application code, data, infrastructure and integrations |
| Delivery | A platform state and its metadata | Software and infrastructure components |
| Main risk | Configuration drift and vendor dependency | Technical debt and code maintenance cost |
Metadata, the language of SaaS platforms
Metadata describes the structure or behavior of an application: business object, field, screen, rule, workflow, permission or interface component. It does not necessarily contain the business data. It describes how the platform must handle it.
Code expresses instructions. Metadata rather describes a target state or a functional intent that the platform interprets. This is what makes low-code possible, but also what requires changes to be explicit and controllable.
Low-code already brings a productivity gain by reducing the amount of manual development. An experimental study published by the ACM observed, across three technologies and in a controlled environment, productivity roughly three to ten times higher than a code-based approach. This result depends on scope, tools and skills. It is not a universal promise, but it is a reminder that part of the work can be handled directly by the platform.
AI first accelerated pro-code solutions
Why LLMs are effective at generating code
LLMs are particularly good at generating code because it is a structured language, rich in regularities and represented by a large number of examples. Syntaxes, libraries, conventions and architecture patterns give the model a relatively predictable framework.
This capability makes it possible to generate functions, classes, components, tests and documentation from a prompt. It does not mean, however, that the model always understands the business intent or that the code produced is correct. Syntactic plausibility guarantees neither correct behavior, nor maintainability, nor security.
From generation to control
In a pro-code approach, the agent can accelerate several stages of development: file creation, implementation, refactoring, test writing, error analysis and documentation. The risk then shifts from producing the code to verifying it.
Delivery must therefore combine agentic generation with deterministic controls: compilation, linters, unit and integration tests, static analysis, vulnerability detection, code review, coverage and CI/CD.
The principle is simple: AI generates, the pipeline verifies.
Four approaches to producing with AI on a SaaS solution
These approaches can be combined, but they differ in openness, in robustness and in dependency on the vendor.
The vendor adds an agent to the administration interface. The user describes their need, the agent proposes a change and asks for confirmation. The experience is accessible and benefits from the platform's context, but depends heavily on the vendor's roadmap.
The Model Context Protocol lets a vendor expose resources and tools that an external agent can use. The agent can then read a piece of metadata, analyze an impact, run a test or propose a deployment without driving the graphical interface. This approach suits agentic orchestration, but depends on the quality of the tools the vendor provides.
The configuration is retrieved in a project format, stored in Git, reviewed in a pull request, tested in a dedicated environment and then deployed through a CI/CD chain. It is the approach closest to software industry standards and the most favorable to traceability. It does require the platform to expose enough of its metadata, dependencies and deployment mechanisms.
The agent uses the interface as a human user would. This technique can help when the platform exposes no API, no usable metadata and no MCP server. It remains fragile, dependent on the interface and hard to audit. It should be reserved for prototypes or one-off tasks.
| Approach | Robustness | Recommended use |
|---|---|---|
| Built-in configuration assistant | Medium to high | Administration and guided use cases |
| MCP | High if the tools are governed | Agentic orchestration |
| Metadata in Git | Very high | Industrialization, audit and CI/CD |
| Browser | Low | Last resort |
The AI harness is just as essential for SaaS solutions
A SaaS solution can be configured by an agent without delivery being under control. To scale, you need a specification, documented context, a before-and-after comparison, automated tests and human validation on sensitive changes. The CI/CD chain must include linters, quality checks, dependency analysis, security controls and a reversible deployment.
The pipeline becomes the control point between what the AI produces and what goes into production. It verifies that the configuration follows the conventions, that the tests pass and that the change can be promoted without degrading the solution. The goal is not to remove administrators, developers or architects, but to reduce repetitive manipulation and focus human expertise on design, review and trade-offs.
Salesforce, a particularly favorable case
Salesforce has a historical advantage: a large part of its customization is already formalized as metadata. Objects, fields, flows, layouts, permissions and components can be retrieved, structured and deployed with Salesforce DX tooling.
The ecosystem now brings together several building blocks useful for agentic delivery:
- Setup with Agentforce, to assist administration tasks in the org, with confirmation before any change;
- Agentforce Vibes IDE, an agentic development environment available in VS Code and as a hosted IDE;
- Salesforce DX MCP Server, to give agents structured tools for synchronization, testing and deployment;
- Salesforce DX Source Format, to manage metadata in a project and a version control system;
- Code Analyzer and ApexGuru, to strengthen quality, security and performance controls.
For our clients, the challenge now is to connect them within a truly industrialized delivery method.
Conclusion: SaaS solutions must become “AI-operable”
AI lowers the cost of producing a custom solution. With it, the Make versus Buy trade-off becomes central again. The value of a SaaS platform will therefore no longer depend only on the number of features it offers, but also on its ability to be understood and handled by humans and agents, without losing traceability or control of risks.
Vendors will have to document their configuration model, expose APIs, CLIs or MCP servers, make metadata versionable and comparable, and make testing, promotion, controls and rollback easier.
SaaS solutions can thus benefit from AI-driven delivery methods, provided they adapt them to their reality. Salesforce is among the best-positioned platforms for this shift: its metadata model, its DX tooling, its MCP capabilities and its quality controls already provide several important building blocks.
Key takeaway. Configuration and metadata become full-fledged software assets. Success will not come from a simple conversational interface, but from a coherent chain between specification, generation, verification and deployment.
