Replacing Low-Code Platforms with AI-Driven Custom Development in Healthcare

A healthcare software solution needs to be developed to aggregate information (e.g., patient data, diagnoses, lab results) from various medical systems and provide it to another component for further processing via a custom-defined API. The system must feature monitoring capabilities and be externally configurable. Thus, the system context looks like this:

In addition to generic technologies (REST, SOAP, files, JSON, XML, SQL), this environment requires support for industry-specific protocols and data formats (FHIR, HL7, MLLP).

The proposed solution must support operations within a complex system landscape and be deployable in multi-tenant configurations across several instances. Each instance demands highly configurable functionality that can be extended via specific plugins. Utilizing a centralized platform for monitoring, deployment, and configuration is an ideal approach to managing this multi-instance environment.

The Lure of Low-Code in Integration Projects

Integration projects are frequently under massive time constraints. At first glance, low-code integration tools seem like the perfect solution: they offer rapid development through visual editors and pre-built connectors. The immediate visibility of data flows and low barrier to entry allow teams to quickly deliver a Proof of Concept (PoC) or an initial production version. Setting up or installing the initial environment is relatively quick and straightforward, particularly with PaaS solutions. The initial focus centers on speed and purely mapping the business logic. In the healthcare sector, notable solutions are offered by vendors such as Mulesoft, Infor oder x-tention.

Another common driver behind low-code/no-code solutions is the desire to shift development into the hands of domain experts rather than internal or external IT specialists. The hope is twofold: to reduce friction between business departments and development, and to shorten waiting times between requirements gathering and deployment.

The Disadvantages of Low-Code Solutions and a Potential Alternative

While implementing a low-code solution enables a rapid start, inherent disadvantages quickly surface as complexity rises and the number of instances grows (though this depends heavily on the specific low-code tool used):

• Lack of Testability: Visually constructed flows can be difficult to test automatically (unit, module, integration, and E2E tests). In critical integration environments, this poses a high quality risk, especially during subsequent code modifications.

• Debugging: Even if some low-code tools provide a debugger for visual processes, capabilities remain limited when troubleshooting things like data mapping, using breakpoints, or inspecting variables.

• Teamwork: Proprietary code and file formats—frequently XML-based—severely hinder modern development workflows and version control. This makes parallel team collaboration or concurrent feature development (branching/merging code) highly challenging.

• Vendor Lock-in: Dependence on the vendor for necessary bug fixes, security patches, or support for new technical standards can cause security risks, higher development costs, and increased training efforts. It can even lead to capacity bottlenecks due to a lack of available expertise in the market.

• Licensing Costs: Vendors typically charge a premium for these tools. For some, healthcare-specific components incur additional fees.

• Lack of Flexibility: A low-code platform binds you to the functionality of its environment. Extended development is only possible if the platform allows the integration of external libraries, for example.

The core question was: Can we retain the advantages of a low-code platform—such as rapid business logic mapping, swift initial environment setup, and robust monitoring—while eliminating its disadvantages through a maintainable, custom-built solution? The use of AI opens up the possibility—similar to a no-code environment—of building a solution simply by describing requirements, without ever interacting directly with source code.

Apache Camel stands out as a well-known, widely adopted framework for integration solutions. Much like commercial integration products, it offers a vast selection of components for protocols, data formats, and runtimes, and even supports graphical designers. Crucially, Camel is Java-based and completely open-source.

The PoC Blueprint: Requirements

A PoC will be conducted to evaluate how effectively Apache Camel can be used for development alongside AI support to build a suitable solution. Beyond pure functionality, the assessment will focus on code quality and testability.

To test this, we chose a business-relevant slice of the existing low-code solution. The implementation goal was to retain low-code benefits while mitigating technical drawbacks.

The functional requirements for the Proof of Concept include:

• HL7 Integration: Providing an MLLP interface to receive HL7 messages containing medical findings (ORU-R01 messages).

• Traceability and Persistence: Storing received raw HL7 messages to ensure end-to-end traceability and enable the replaying of error scenarios.

• Error Handling: If messages cannot be processed (unknown format, missing fields, database unavailable, etc.), the message must be rejected so that the sender can retry if necessary.

• Data Querying via REST: Providing a REST interface to query configurable domain-specific patient information from the persistent HL7 messages.

Additionally, the PoC should fundamentally demonstrate that centralized monitoring and deployment are feasible:

• Centralized Management: The new environment should be easy to set up and provide centralized monitoring, update, and configuration management across various instances.

AI as a Product Engineer: Specification and Implementation with BMAD

The chosen methodology goes beyond mere "vibe coding." In line with Spec-Driven Development, an AI-driven approach was used in collaboration with the AI to automate the entire lifecycle—from requirements gathering to fully functional, deployable code. The goal was to accelerate time-to-market without compromising on code maintainability. BMAD combined with Claude Code was used as the tooling. Apache Camel provides an MCP-Server that assists during implementation.

Specification and Epics: First, managed by BMAD, requirements were gathered, a detailed technical specification and architecture were drafted, and the epics to be implemented were generated. This established a clean, comprehensive foundation for the subsequent implementation phase. During this stage, BMAD highlighted ambiguous descriptions and open points, occasionally offering alternative solutions. This phase consumed a major portion of the project time.

Implementation – The Ralph Wiggum Loop: The actual development using Apache Camel (with Spring Boot) occurred within an iterative loop known as the "Ralph Wiggum Loop." This concept is well-described here. Within this loop, AI agents systematically process tasks until none remain. Two implementations are available for BMAD: BMAD-Automate and BMALPH. These define the high-level tasks (breaking stories into tasks, writing tests, implementing, running tests, code review, committing) executed by the respective agents, and control the loop itself. During execution, the respective tool also manages context handling and occasionally allows the selection of different AI models for different tasks.

The Result and the Role of the Human Architect: The outcome was a complete implementation including specifications, documentation, and a suite of well-tested code. All code corrections and adjustments were performed autonomously by the AI. Nonetheless, crucial insights emerged regarding the ongoing necessity of human expertise:

• Architecture and Subject Matter Expertise: Although the AI provided highly sound recommendations, an experienced architect was still required to identify functional and technological improvements (the AI overlooked a few viable approaches) and enforce best practices. However, these inputs can be efficiently integrated via dialogue with BMAD.

• Quality Assurance and Clean Code: The generated code did not always comply with predefined guidelines (e.g., using YAML DSL instead of Java DSL) and tended toward unnecessary complexity. Unit test quality was particularly critical; the AI frequently cloned routes directly into tests—an anti-pattern that creates maintenance liabilities. While manual review was not needed to verify functionality, it was essential for improving readability, maintainability, and ensuring clean code principles.

Conclusion: AI Shifts the Make-or-Buy Decision Toward Custom Implementation with Apache Camel

The experience with BMAD and Apache Camel demonstrates that AI utilization fundamentally alters economic considerations in integration projects. The initial speed advantages of low-code platforms are neutralized by AI, while their drawbacks (technical debt, poor testability, vendor lock-in, licensing fees) are avoided. This shift is likely to accelerate as AI models continue to evolve.

As a proof of concept, a solution was implemented that includes the required features and satisfies enterprise integration standards:

• Quality: Secured by strong test coverage with tests that can be automatically executed within a CI pipeline.
• Maintainable: Clean, readable code aligned with coding guidelines.
• Standardized: Java/Spring Boot leveraging standard frameworks.

AI is not (yet) a replacement for domain experts, architects, and developers. It is, however, an exceptional tool that drastically accelerates execution, empowering us to meet complex integration demands sustainably. Domain experts define business requirements, architects and developers establish technical boundaries and evaluate generated architectural designs, code, and test quality. AI agents can be integrated into organizational structures as team members, supporting all the aforementioned roles in their respective responsibilities.

Through this process, I have identified several key takeaways that a developer should keep in mind — particularly when working with Camel — though many apply to "standard" development projects as well:

• A baseline understanding and prior knowledge of Apache Camel and Java should be present.
• Define architectural and coding guidelines, and verify that the AI complies with them (e.g., package structure, route design, and modularization). These should be enforced via tooling (linting, ArchUnit, etc.).
• Determine and inspect the mapping strategies required in the processes (e.g., Jackson, DataSonnet, Java code) to ensure appropriate tools are chosen, mappings remain legible, and tests exist for mapping logic where applicable.
• Conduct code reviews on the generated code and assess the complexity and quality of tests. Code coverage metrics should be utilized to gauge test depth.
• Have technical documentation generated and kept up to date (e.g., via hooks). Individual artifacts (mappings, processes, adapter configurations) tend to be harder to locate than in dedicated low-code solutions.
• Utilizing different models (e.g., Claude Sonnet vs. Opus) yields significantly different code, primarily regarding structure, generality, and readability (I prefer the code generated by Opus).

Out of the box, low-code integration solutions frequently provide features that Camel does not offer standalone (e.g., monitoring, deployment, API gateways, high availability, third-party adapters). It is therefore essential to evaluate which of these features are required for the solution and how they might need to be co-developed within the project.

An intriguing idea for future projects of this nature is to build one or more specialized skills for an Apache Camel developer and integrate them directly into BMAD.