Opening | From “Citizen Development” to “AI-Assembled Applications”
Over the past several years, we have been advancing our product around a clear and consistent goal:
to provide non-developers with truly usable, enterprise-grade application-building tools.
Our vision has been that business users, managers, and even frontline employees should be able to build application systems tailored to their own work through configuration and composition, rather than by writing code. Looking back today, this goal may appear superficially similar to “AI programming,” but from the very beginning, we chose a fundamentally different technical path.
We do not ask users to produce frontend or backend source code. Instead, we help them construct structured models — data, rules, permissions, and processes — around real business scenarios. These models can be directly understood and executed by the platform, with rendering and execution handled automatically by the system. This is what we define as a model-driven application platform (APaaS).
As we enter early 2026, one judgment has become increasingly clear to me:
over the next one to two years, as AI engines are systematically embedded into APaaS platforms, the way users build applications will change fundamentally, and the commercial value these platforms create for enterprises will undergo a step-change.
I. The Era of Manual Modeling Is Coming to an End
APaaS enables non-developers to build enterprise applications through visual configuration rather than code. Even on its own, this is already an order of magnitude faster than traditional development. AI will push this process one step further.
In the past, even when using no-code tools, users building a CRM application still had to make a large number of design decisions:
- What data tables are required?
- What fields should each table contain, and how should their types be defined?
- How should relationships between tables be established?
- What roles are needed, and what data access permissions should each role have?
- How should analytics dashboards be designed, and which management roles should receive them?
- How should each business process be decomposed and configured into automated workflows?
All of these decisions rely heavily on the user’s own understanding of the business, accumulated experience, and real-time judgment.
AI is now gradually changing this reality.
Users can describe their requirements in natural language, supplemented by necessary business materials, and an intelligent agent can directly generate the complete underlying model structure for a no-code application.
For example, when a user wants to build a management application for a dental clinic, the AI assistant can generate, in one pass, the required list of data tables, field structures, and attributes. Once confirmed by the user, these tables can be created automatically within minutes. This capability was already partially realized in the 7.0 release of Nocoly HAP last month. Over the coming year, building applications with AI will become the core development direction for no-code products.
More importantly, the role of the assistant will not stop at “replacing operations.”
It will gradually evolve into an application analyst and planner — helping users assess requirement completeness, identify omissions, and propose more reasonable structural designs. Users’ primary responsibility will increasingly shift toward describing business problems and providing business context, rather than struggling with configuration details. Ultimately, applications built by AI are likely to exceed the quality of what most ordinary users can achieve manually.
These intelligent agents typically model with the “end state” in mind. They reason layer by layer around business objectives and cover many configuration details that are easy to overlook. Compared with inexperienced users, they often produce more rigorous and complete data models.
Unlike AI coding, all results of no-code modeling are always presented to users through visual editors. Any deviation can be inspected, modified, and corrected at any time, avoiding the sense of uncontrolled acceleration often associated with “Vibe Coding.”
If a metaphor is needed, no-code automated modeling is more like slow-motion autonomous driving:
humans can always see the system’s intent clearly and have ample time to decide whether to take over.
II. The Inevitable Convergence of Agents and Workflows
Until recently, agent platforms and enterprise workflow platforms were almost entirely separate categories of software. Choosing one typically meant solving only one class of problems.
In theory, agent platforms should focus on model invocation and agentic workflows. In practice, due to the complexity of enterprise requirements, these platforms have had to add large amounts of rule-based functionality, such as branching, looping, and interruption handling.
Conversely, automation workflow platforms such as Nocoly HAP and n8n have begun introducing agent capabilities to support scenarios driven by intelligent decision-making.
At a fundamental level, both types of platforms share the same objective:
the automation of enterprise operations.
Artificially separating them only increases the cost of selection and integration for users. From a trend perspective, their convergence is nearly inevitable.
In reality, it is often easier for existing enterprise workflow platforms to introduce agent capabilities. Their process nodes, execution engines, and exception-handling mechanisms are already mature, and enterprises can experiment with agent-driven decisions within a controlled environment.
After adding agent nodes, the open-source workflow platform n8n quickly became one of the most popular open-source projects in the agent space — clear validation of this direction.
Some in the industry envision a fully “agent-driven” enterprise, where numerous agents communicate and collaborate autonomously to complete complex tasks. This vision is not wrong at the goal level, but it often conflates means with ends.
Enterprise automation and intelligence do not rely solely on agent collaboration. They must continue to depend on rule-orchestrated process engines over the long term. The relationship is more like that between the brain and the hands. The more complex the task, the more both are required.
Agent platforms often assume that “hands” can be solved through tool invocation. In reality, few enterprises possess a complete, plug-and-play tool ecosystem. These tools themselves must be orchestrated, either in advance or on the fly.
For example, an agent may determine that inventory for a certain material needs to be increased. Executing that decision still involves a full set of traditional processes: document creation, approvals, budget balancing, supplier inquiries, and procurement.
These processes may already exist, or they may be missing. To close the loop between intelligent decision-making and execution, enterprises must have a workflow toolbox that is always available and extensible. This is precisely why I emphasize that the integration of traditional workflows and intelligent agents is unavoidable.
III. AI Reshaping Application and Data Integration
Application and data integration has always been a critical supporting capability of APaaS, and AI will have a profound impact in this area.
In real integration work, the biggest obstacle users face is not technical difficulty, but understanding the data semantics and structural meaning of heterogeneous systems. Integration specialists often have to repeatedly consult incomplete documentation and confirm details through messaging groups just to complete a barely correct mapping configuration. Even minor errors can lead to serious data quality issues.
As the agent concept becomes more widespread, more applications are paying attention to open APIs and semantic quality. Combined with MCP and rapidly standardizing Agent Skills, agents theoretically already have the ability to accurately read and write upstream and downstream data on demand.
In practice, however, most enterprises are still uncomfortable with fully improvised data movement. External APIs rarely support fine-grained differentiation of internal enterprise roles and permissions, and cross-system data usage still needs to be built on synchronization and transformation frameworks in most scenarios.
Applications built with APaaS already have clear data structure context. When combined with data structure information from external systems, AI can infer highly accurate data mapping and transformation logic, expressing it as standard ETL configurations for users to test and confirm.
For example, a user can simply describe a requirement:
“Fetch order data from Salesforce and write it to HAP’s order table. If a new customer is encountered, synchronize the customer data as well. Map the customer industry field to the closest available option.”
Based on such a prompt, integration tools can automatically complete a large amount of tedious configuration work.
In many cases, once a data source is selected, AI can even proactively recommend common synchronization scenarios.
By empowering integration with AI, APaaS makes this complementary work significantly easier, thereby greatly increasing the overall commercial value of applications.
IV. Vibe Coding Becomes a Friend of APaaS
Over the past year, I have often been asked: will Vibe Coding make no-code APaaS irrelevant?
For a while, this was not an easy question to answer. Today, however, the boundaries and complementary relationship between AI coding and APaaS have become much clearer.
In short:
- Vibe Coding needs APaaS to truly enter production environments.
- APaaS becomes more open and more capable because of Vibe Coding.
This month, Nocoly HAP published a set of Agent Skills (essentially a collection of Markdown files) that users can install into any AI coding tool such as Cursor, Claude Code, or TRAE. These skills describe HAP’s application API structure, plugin development specifications, and how to obtain application structure context.
As a result, users can develop HAP plug-ins directly through natural language, or generate corresponding backend data tables in HAP based on Vibe Coding instructions.
For example, when building a marketing website, this mechanism can simultaneously generate the required frontend pages and the complete backend content management data structure. One effort solves both frontend and backend requirements.
Without such integration, users typically end up generating static files, or they need to introduce additional database products such as Supabase.
Users can also generate entirely non-standard data views, building any form of presentation layer on top of HAP worksheet data. They can even sketch a “hypothetical” dashboard first; AI will analyze the required data structure and generate both frontend chart components and backend worksheets.
When a stable HAP application already exists, this process becomes even more direct. In every conversation, the coding agent clearly understands the current application’s structural context.
As a result, the combination of Vibe Coding and APaaS produces complete, controllable, production-ready applications with both frontend and backend included. This represents a completely different value tier compared with using Vibe Coding alone.
For this reason, APaaS can avoid endlessly expanding its own complexity just to cover every long-tail requirement. This is a classic example of user value created through “openness with boundaries.”
V. Freedom of Model Choice and Model Separation
Finally, I want to address the issue of model separation.
Many applications initially adopt a closed model approach when introducing AI, sparing users from model selection. For APaaS, this is far from sufficient.
The reason is simple:
AI may process an enterprise’s most critical data assets, and users must have the right to choose the model.
This requires APaaS platforms to provide comprehensive model management capabilities:
supporting public models, models accessed via user-owned API keys, and privately deployed open-source models. Different models must be abstracted behind a unified invocation interface.
On this basis, platforms must also impose appropriate constraints on multimodal capabilities and parameter scale for different application scenarios, ensuring that each scenario uses a model with “appropriate capability.”
Even this, however, is still not enough.
Application platforms must also support the selection of model providers. Model providers refer to cloud platforms such as Azure, while model developers refer to companies such as OpenAI. The separation between the two has become a clear trend.
The lifecycle of models and applications is fundamentally different.
Models pursue rapid capability leaps and have low requirements for forward compatibility.
Applications pursue stability and continuous evolution, and vendors must guarantee compatibility over long periods.
The relationship is much like that between an aircraft and its engine.
As “aircraft builders,” application vendors must always be prepared to replace engines for their users.
Conclusion | The Year Ahead for APaaS
Taken together, AI has not diminished the value of APaaS. It is pushing it into a new phase:
less manual modeling, more intelligent process decisions, lower-barrier integration, more open development boundaries, and genuine respect for users’ right to choose models.
Over the coming year, these changes will not appear as isolated features. They will emerge through continuous iteration and systemic integration.
If you would like to experience this transformation firsthand, you are welcome to try Nocoly HAP as it continues to evolve. In the year ahead, you will consistently see the tangible evolution brought by the combination of AI and APaaS — and the long-term business value it unlocks.
