How we built a production-grade agentic AI system that unified documentation, learning, components, and marketplace discovery into a single developer experience — and what we learned shipping it.

---

---

The Problem​

As our product ecosystem expanded with developer-centric documentation, an Academy, a Storybook of component library, a Marketplace — our knowledge surface grew faster than any developer could navigate.

Finding the right component spec meant visiting Storybook. The tutorial video explaining it lived in the Academy. Checking whether a connector already existed required a separate trip to the Marketplace. Then back to Docs to understand concepts. Four tools. Four context switches. One Product.

Developers were context-switching across four separate surfaces for finding relavant knowledge belonging to one product. There was no unified intelligence layer — fragmented knowledge spread across Docs, Academy, Storybook, and Marketplace, with no thread connecting them.

The team's response was architectural- don't build a better search bar. Build an intelligence layer that understands all four systems and can reason across them.

---

The Architectural Decision: Every System Is Independently Addressable​

The foundation of the system is a deliberate principle — one that shapes every design decision downstream.

Rather than ingesting all content into a single shared index, we built a dedicated Model Context Protocol (MCP) server for each system. Docs, Academy, Storybook, and Marketplace each expose their knowledge through their own server, structured to match the shape of data that system produces.

This matters because Docs are structured differently from video transcripts, which are structured differently from component specs, which are structured differently from marketplace artifacts. A single index flattens those distinctions. Separate MCP servers preserve them.

Ecosystem overview: Data sources, per-system indexing pipeline, and external MCP APIs

On top of those four servers sits a LangGraph powered Ecosystem Agent — a stateful orchestration layer that reasons across all four knowledge sources and synthesizes answers for both human developers and external AI agents. The same MCP layer that powers the user-facing Ask-AI also serves the platform's automated development agents during code generation. One system, two consumers.

Two improve system continuously and enhance the experience, we baked in:

• LangFuse for full trace observability. Every agent invocation is traced. Retrieval quality, routing decisions, failure modes — all visible and actionable. The pipeline learns from production behavior, not from assumptions made at design time.
• Redis for caching. Repeated queries are served from cache, keeping response times fast as usage scales.

Ecosystem Agent flow: LangGraph orchestrator, MCP retrieval fan-out, retrieval fusion, and LangFuse tracing

---

Four Ask-AI Experiences, Each Purpose-Built​

Every surface in the ecosystem has its own Ask-AI, tuned to the knowledge it serves.

Surface	What the AI understands
Docs	Full cross-system synthesis — the only surface that queries all four knowledge stores simultaneously
Academy	Video structure — answers point to the exact timestamp with a thumbnail preview, not just the video title
Storybook	Component internals — props, events, methods, design tokens, and usage examples inform ready-to-use code snippet generation
Marketplace	Artifact landscape — surfaces existing connectors, designs, and apps to reduce duplication across teams

The Docs Ask-AI is the flagship. Every response is structured: a summary, an Academy video with exact timestamp, a code example drawn from Storybook specs, and references to relevant Marketplace artifacts. A developer asking a single question gets an answer that previously required navigating four separate systems.

---

The Data Pipeline Is the Product​

AI is only as good as the data feeding it. We invested in the retrieval pipeline with the same rigor we'd apply to any core product surface.

RAG pipeline: ingestion, vector indexing, query normalisation, hybrid search, re-ranking, and summarisation

Three principles shaped how we built it:

System-specific indexing strategies​

Docs, Academy video transcripts, Storybook component definitions, and Marketplace artifacts have fundamentally different data shapes. We built custom indexing per system — each optimized for the types of questions that system is expected to answer. A single generic strategy would have been a compression of information we couldn't afford to lose.

A continuously evolving RAG architecture​

We didn't deploy a static retrieval system and walk away. The RAG architecture adapts as LangFuse surfaces real usage patterns. Strategies that worked at launch get revisited as the knowledge base grows and question patterns shift. The system is designed to improve continuously, not to be periodically maintained.

Democratized contribution with near-realtime reflection​

Any developer writing documentation — even a brief note on how to switch themes — sees that knowledge reflected in AI responses within minutes. The pipeline is open and fast. Knowledge latency is measured in minutes, not deployment cycles. The AI improves as the team builds, with no dedicated curation team required.

---

What Production Taught Us That Testing Couldn't​

We shipped this into production from day one rather than running it as an internal prototype. That decision created pressure that no review process can simulate — and generated feedback that fundamentally changed the system.

1) Academy indexing was completely redesigned​

Initial video-level retrieval pointed developers to a video. That turned out not to be good enough. Real usage showed that pointing to a 20-minute video is barely better than not pointing anywhere at all. We rebuilt the entire Academy indexing layer — moving to segment-level transcript indexing with thumbnail-level timestamp precision. It was a significantly more complex engineering investment. It was fully justified by production signal.

2) Agentic orchestration revealed edge cases invisible in testing​

LangGraph's stateful orchestration surfaced routing ambiguities and retrieval failures that no synthetic test suite predicted. LangFuse observability was the instrument that made these visible and actionable — turning production incidents into architectural improvements rather than support tickets.

3) Multi-system synthesis required structured answer design​

Synthesizing across four knowledge sources without a consistent answer structure produced incoherent responses. The answer was a deliberately structured output format — summary, video timestamp, code example, artifact references — that imposes order on multi-source answers and meets developers exactly where they work.

---

Impact: What Actually Changed​

This system replaced a fragmented, passive documentation landscape with an active, unified intelligence layer. The before-and-after is not incremental.

	Before	After
Developer workflow	4 surfaces, 4 context switches per question	Single Ask-AI interaction, structured multi-source answer
Knowledge latency	Deployment cycles — documentation changes required a release before they influenced AI	Minutes — any contribution reflects in AI responses within minutes
Video discoverability	Searchable by title only	Segment-level indexing makes every moment in every video findable
Agent integration	Development agents had no ecosystem knowledge	Agents query ecosystem knowledge via MCP during code generation

---

Closing Thought​

We built this to solve real problems in production — not as a demo. Running it in production gave us actual experience and compelled real improvements. That is the only honest way to build AI systems. — Engineering Team

The instinct when building internal AI tooling is to keep it in prototype mode until it's "ready." What we found is that ready only comes from shipping. The Academy indexing redesign didn't come from a code review — it came from watching developers use the system and seeing where it fell short.

Build for production. Learn from production. Everything else is just guessing!

---

Stop thinking about guardrails. Start thinking about the AI assembly model.​

The real shift in enterprise AI app generation isn't better validation — it's reducing how much needs validating in the first place.

---

As AI-generated code becomes the norm, the review gap is growing faster than the tooling to close it. Sonar's State of Code 2025 — surveying over 1,100 developers — found that 42% of code committed is already AI-assisted, and around 29% of it is merged without manual review. The problem is not AI — it's the approach: generate everything, then check everything.

Guardrails in this model become a perpetual catch-up game. WaveMaker takes a different position. With the AI assembly model, the focus shifts from fixing generated code to not generating the wrong code in the first place.

---

The problem with generate-then-check​

When AI generates a UI component from scratch — a data table, a form, a navigation bar — the output is probabilistic. It might be correct. It might also carry a missing auth check, a hardcoded colour value that bypasses the design system, broken accessibility markup, or a state pattern that breaks under load.

So platforms add guardrails: static analysis, token linting, visual regression, accessibility audits, code security scans. Each is a reasonable response to a real problem. Together, they describe a system permanently compensating for its own unreliability. The output is checked — not prevented.

Dimension	Generate → then check	Assemble → quality inherited
Output quality	Probabilistic — varies every time	Deterministic — same component, every time
Quality enforcement	Downstream checks per component, per app	Baked in once, inherited by every app
Security posture	Caught after code exists	OWASP compliance lives inside the component
Design consistency	Token drift risk on every generation	Token bindings verified once at certification
Scale	More apps = more checks = more cost	More apps = same cost, more leverage

---

The AI assembly model — how WaveMaker works​

The most reliable code is code that was never generated on demand.

Rather than prompting AI to write a component, the AI assembly model maps developer intent to a pre-built, tested, certified component from the library — then configures it. The component code is never on demand. Where generation does occur — custom logic, backend services, new integrations — guardrails are applied precisely there, not spread thin across everything.

Component mapping zero generation Intent — via prompt, canvas, or Figma import — is matched against the component library. If a certified component exists, it is selected. No generation fires.

Props and data binding minimal generation The AI configures: properties, data connectors, navigation, auth wiring. Schema-bounded, enumerable, verifiable.

Generation for gaps only targeted generation Custom logic and novel integrations with no library match are generated. This is where AI is genuinely needed — and where guardrail checks stay focused.

The guardrail isn't a check that fires after generation. It's the rule that routes intent to a pre-built artifact instead. If the library has the answer, generation never starts.

WaveMaker Markup Language (WML) is what makes this enforceable. Each component and design token in WML resolves to a pre-built artifact before any code is generated. Match found — artifact used. No match — generation scoped to that gap only. WML is the guardrail — and what makes code generation deterministic.

When the library does not have an answer, open standards ensure there is no dead end. AI generates the missing capability directly into the same framework the rest of the application is built on — no proprietary layer to work around, no lock-in. The result is standard code that teams own, can extend, and can promote back into the library for every future app to inherit.

---

What pre-built components guarantee​

Every component in the enterprise library is a certified artifact — not a reusable snippet. Quality is a property of the component, not of the app that uses it.

Visual consistency — design tokens, dark mode, responsive behaviour, and brand compliance are verified at component build time. Every app inherits them. No per-app visual regression for the assembled portion.

Security — Auth scaffolding, CSRF protection, and OWASP compliance are baked in. You cannot assemble an insecure version of a secure component.

Accessibility — WCAG AA compliance covers a broad set of requirements: colour contrast, ARIA roles, focus management, keyboard navigation, screen reader compatibility, and interactive component behaviour. These are validated once at component build time. Every consuming app inherits the result.

Cross-platform fidelity — one component declaration produces a tested web and a tested mobile component. Parity is a property of the component, not a testing burden repeated per app.

---

Backend microservices — where guardrails matter most​

The real challenge in enterprise app development is not how to generate code — it is how to build a system. Scalability, security, data integrity, and service independence are architectural decisions, not code generation choices. When these are left to developers to figure out on a per-project basis, they get inconsistent results — especially under the pressure of AI-assisted speed.

Backend services are where the most code is generated — persistence layers, API endpoints, security filters, service integrations. They are also where the architectural stakes are highest. WaveMaker embeds architectural guardrails here as structural properties of every generated service, so developers focus on what the system needs to do, not on re-solving how it should be built.

Stateless, freely scalable services. No session state. Any instance serves any request. Scaling is an infrastructure decision, not an application change — the same architecture handles a pilot and a rollout of millions. (12-factor: stateless processes)

Safe, cached, auditable data access. All data access runs through a generated persistence layer. Unguarded database calls are not a pattern the platform produces, eliminating the injection vulnerabilities that top the OWASP Top 10. Frequently accessed data is cached consistently; every write carries an automatic audit trail — who changed what, and when.

Secrets isolated from code. No credentials in generated services. API keys, database passwords, and encryption keys are injected at deployment from a secure secrets vault — never written to source control. Rotating a credential needs no code change. (12-factor: externalised config)

Role-based access control, end to end. Most platforms define access at the UI and leave the rest to developers. WaveMaker generates RBAC as one continuous constraint — declared once, enforced at every layer. A user sees only what their role permits in the UI. Their API calls are validated before any business logic runs. Their data access is filtered at the database layer. One definition. No gaps. No drift between layers.

API-bounded service contracts. Every service exposes a typed, versioned API. Services communicate through contracts — never through shared data stores or direct coupling. Each API service can be changed and redeployed independently.

Security validated against industry standards. Generated applications are tested against the OWASP Top 10 and verified under real-world conditions through dynamic application security testing (DAST). Compliance teams get independently auditable evidence of security posture at every release.

Guardrail	Standard	Business outcome
Stateless services	12-factor	Horizontal scale without architecture changes
Generated data access layer	OWASP Top 10	Injection safety and audit trail by default
Secrets at deployment	12-factor	No credentials in code; rotation without redeployment
RBAC across UI, API, database	OWASP	One definition enforced across all layers
API-bounded contracts	12-factor	Independent deployability per service
OWASP + DAST validation	OWASP / Veracode	Auditable security posture per release

The cost argument — honestly​

The AI assembly model carries a higher context overhead. Teaching the platform your component library, binding syntax, and WML structure takes more input than a bare "generate this component" prompt.

But that overhead is more than offset by what doesn't get generated. In a generate-first model, every component is produced in full, every time. In the assembly model, the component code already exists — the AI configures, not constructs. A fraction of the tokens, a fraction of the self-correction loops, a fraction of the output to validate.

Context overhead is paid once per session. Generation savings compound across every component assembled — and compound further with every additional app built on the same library.

Cost dimension	Generate-first	Assembly-first
Context per session	Low	Higher — library schema required
Code generated per component	Full implementation every time	Props and bindings only
Self-correction loops	High — probabilistic output	Low — configuration against a fixed schema
Quality audit per app	Full — every component, every app	Minimal — component is pre-certified
Defect remediation	Recurs with every generation	Near zero for the assembled portion
Cost at scale	Grows linearly	Amortises — savings compound

The real advantage isn't token cost. It's defect cost — developer hours diagnosing wrong output, QA cycles catching it, production incidents when it slips through. A pre-built component absorbs that cost once. Every app that uses it inherits the saving.

---

Five things worth taking away​

1. Guardrails that check output are necessary. The better question is how much output needs checking.

2. The AI assembly model shifts quality from something you verify to something you inherit — compounding across every app built on the same library.

3. Backend guardrails are structural: stateless services, safe data access, isolated secrets, and end-to-end RBAC are properties of the generated architecture, not developer choices.

4. Context overhead in assembly is real but offset by dramatically less code being generated. It is not about cost but more about determinism in code.

5. For regulated deployments, certified-by-construction is a stronger and more durable compliance approach than verified-by-testing.

---

---

Fast-paced AI code generation​

AI generated code is taking over the developer written code, almost 40% of code is generated by AI coding tools & vibe coding platforms today. As more code gets produced faster, reviewing and validating its production readiness becomes a huge challenge for development teams.

While skilled developers, experienced in building frameworks and those who imbibed architectural best practices over the years are able to achieve dramatic gains in productivity, the rest of the developer community has mixed reactions with AI. Prototypes get built lightning fast, but to take these to production is a bohemeth task in getting the architecture and alignment to existing organization principles right.

At WaveMaker, we are focused in creating the right foundation for AI-accelerated development, with an Architecture First approach and achieving deterministic outcomes with LLMs.

Built on a strong foundation​

Over the last decade, WaveMaker helped development teams to modernize their app solutions and products which needed experience-driven pixel-perfect UI, heavy customization for each deployment, high scalability and rigid security for regulated industries like BFSI, telecom, supply chain, healthcare etc.

WaveMaker enabled large organizations to build several multi-platform web and mobile app solutions, which require collaboration across engineering, design, customer implementation and partner development teams.

In such highly collaborative and cross-functional environments, WaveMaker platform provides alignment in terms of:

1. Technology stack
2. Design systems
3. Composability & Reusability
4. Enterprise guardrails & best practices
5. Seamless integration with existing SDLC processes

WaveMaker AI​

WaveMaker AI is a step forward to bring design systems, proven architectures and enterprise guardrails into development projects, with significant boosts in developer productivity when using AI.

Three Pillars of Development​

Platform focuses on 3 key approaches to provide acceleration to the development teams:

1. Design to code automation, creates a working Design System for developers
2. Squad of AI Agents for SDLC workflows, with standards based app generation
3. Integrated Studio experience to develop, test, configure & deploy apps

A hybrid development environment that combines autonomous design to code AI that converts Figma designs to a working application, Agents that carry out development tasks enforcing architecture, enterprise guardrails, and an integrated Studio environment for developers to fine-tune and override.

1. Design to code Automation​

WaveMaker Design to Code converts Figma designs to a working application using AI, by creating a Design System for developers which comprises of the following:

• Layouts are recreated from design using Container Auto Layout
• Components are identified and mapped to the WaveMaker component library, and
• Design Tokens are generated mapping the styles from the Figma Variables

Design System​

Design Systems provide a single source of truth for design decisions that are made as part of the digital transformation and UI modernization projects. As the organizations grow and scale, development teams need to deal with:

• very complex UI screens
• intricate component customization
• high expectations on UI experience and performance
• heavy integrations to support security and scalability needs
• frequent rollouts (or point-releases)

Layouts & Design tokens​

Platform provides advanced layouting capability using Container Auto-Layout, UI Components provide design tokens to style every aspect and Components adhere to the Material Design principles. All these capabilities enable seamless conversion of Figma designs using AI, at a granular level and with high fidelity.

UI Components​

WM UI component library has evolved over the past decade supporting complex customization, security, accessibility and modern experience needs. Components are built for popular UI frameworks such as Angular, React for web & React Native for mobile.

The two-pass approach​

WaveMaker uses a highly sophisticated 2-pass generation technique to make AI conversion deterministic and repeatable.

• 1st pass: Figma designs are translated to an intermediate WaveMaker meta markup language (WML), which identifies UI Components, properties and design tokens using AI/LLM
• 2nd pass: WaveMaker Markup (WML) is then converted to working Angular, React or React Native app code, using WaveMaker code generators and LLMs

2. Squad of Developer Agents for App Generation​

WaveMaker AIRA Agents brings AI-driven speed to enterprise application development with developer control and transparency without compromising on code quality, security, or architectural integrity. Every agent workflow is reviewable, reversible, and fully traceable, giving teams the confidence to adopt AI at scale.

Developer agents in WaveMaker generate predictable code output due to the 2-pass technique, reducing the cognitive load for developers to deal with huge amounts of AI-generated code.

MCP framework​

Built on Model Context Protocol (MCP) framework, AI agents operate with deep, real-time application context providing access to relevant code, app artifacts, platform knowledge, and enterprise standards ensuring accurate, governed, and production ready outcomes

Multi-Agent System​

Each developer task is broken down into sub-tasks, orchestrating task completion across multiple agents and generating coherent output. Agents retain context and make it easier to build apps through simple prompts, to complete both common and complex development tasks, without compromising quality or control.

Architectural integrity​

Developer Agents operate inside your application and are made aware of Design System, separation of UI layers, API and backend microservices, scalable architecture principles and secure practices. These Agents generate production-ready and open standards code while keeping developers in control of every decision.

3. WYSIWYG Studio for Authoring and finer control​

WYSIWYG Studio offers visual validation of development activities and better collaboration across design, engineering and business teams. WaveMaker focuses in reducing the developer skills needed to build complex, scalable, multi-platform applications in large organizations.

WaveMaker Markup Language (WML)​

WML not only simplifies AI code generation, it has enabled developers to visually create layouts, drag-n-drop components and fine-tune their look-n-feel requirements. Over the years, WML evolved and enabled developing highly customizable ISV solutions and enterprise applications.

Human-in-the-loop​

Visual canvas for page editing, Style workspace for editing the Design System and code editors for manually writing code. Studio provides human-in-the-loop control for developers to fine tune and refine AI generated output, while simultaneously taking advantage of automation with LLMs and agents.

Paving the way for future of app development​

In the era of AI code generation, developer ecosystem really needs a much stronger foundation in terms of architecture, design principles, open standards based frameworks and well-adopted industry trends to build app solutions.

WaveMaker empowers developers to really focus on their business objectives and goals for app modernization, while the platform takes care of architecture and guardrails, bringing true AI transformation to scale developer productivity.