Back in January, our CPO pinged me showing me how our Sales Engineers had started "vibe coding" (AI-assisted software development) a bunch of tools to make POVs easier and demonstrate the full power of our platform. His ask: "we need more of this in engineering."
Twelve months earlier, I, a Software Engineer for over a decade, had been using zero AI coding tools. Now, our CPO was showing me Sales Engineers building more UIs, workflows, and tools with them than our own engineering team was building into the platform.
Those Sales Engineers are a leading indicator.
The customers watching those demos see exactly what's possible, and they want to do it themselves, on their own data, against their own workflows. The Sales Engineers were quick to adopt the AI tooling, which is a signal that our customers are close behind. We need to acknowledge that they won't wait for our roadmap to catch up.
So when the CPO pings, your first reaction might be to shoehorn more AI tools into the development, review, and release cycle to ship faster, but that ends up being a trap. You’ll never be able to add every single customization that every customer to ever use the platform would ever want. You’d just have a mess. What customers want is room to build their own stuff against a vendor they can trust.
The opposing forces: AI velocity vs. platform stability
The most important features for a platform that serves thousands of customers are reliability, performance, and scale. When customers put us in the critical path, guaranteeing these traits requires the utmost rigor, and we cannot compromise on them.
But this necessity for rigor is fundamentally incompatible with the fluid, immediate nature of AI-assisted development. We are looking at two diametrically opposed forces:
To solve this, we had to architecturally separate these two forces: keeping the core platform solid and stable, while giving customers a highly flexible, sandboxed surface to build on.
The customization spectrum
Platform customization exists on a spectrum where on one end you have a “free-for-all” and on the other you have a “walled garden”, and the goal is to find an ideal balance that plays into the strengths of AI-assisted development.
Extreme 1: The "free-for-all" (arbitrary code execution)
In this model, the platform lets you upload and execute custom code directly within the platform's core execution environments without a clear trust boundary.
The problem here is it co-locates untrusted, rapidly iterating code with high-privilege platform infrastructure. Historically, trying to secure this model has meant imposing restrictive runtimes, complex deployment steps, container packaging, and slow pipeline reviews. This operational overhead completely destroys the rapid, frictionless "vibe coding" experience.
Extreme 2: The "walled garden" (pre-built widgets)
Alternatively, the platform restricts you to a narrow suite of pre-built UI components, drag-and-drop builders, or basic configuration toggles.
The problem with this approach is that, while highly secure and stable, it is far too restrictive. The moment your business logic deviates from the pre-built templates, you hit a wall. In the age of AI, where you can generate an entire custom UI in seconds, being limited to a static set of widgets feels like an antiquated bottleneck.
Introducing Apps within Cribl’s AI Platform for Telemetry: The three core principles
We designed the App framework at Cribl to break this trade-off. Our goal is to give you a secure sandbox to run apps while exposing minimal, secure primitives you can compose.
This approach lowers the abstraction level, allowing domain experts to build "full apps" using standard web technologies the AI already knows, rather than forcing you to learn a complex, proprietary platform. You can iterate locally and package the result without fighting the platform.
We built this strategy on three core principles:
1. The trust boundary (core principle)
The platform strictly owns and enforces the security surface. Apps never run with internal platform privileges like auth tokens or API keys. Instead, they interact with the Cribl Platform strictly across a secure boundary, composing our existing public APIs.
2. Sandboxed execution
Customer-written code is completely restricted to a secure, zero-privilege execution sandbox. This is a fundamental principle that ensures any failure of a customer-written component is contained, without threatening the latency, security, or availability of the underlying platform. While our first iteration uses a sandboxed iframe to leverage the browser's mature security primitives, this core principle of isolation is foundational for all future execution environments.
3. Managed backend primitives
Instead of forcing customers to build and maintain custom backend infrastructure just to handle simple app state, we provide built-in primitives out of the box such as state persistence and secure API proxies. By abstracting the underlying backend operational complexity, the platform allows customers to focus exclusively on developing the core logic of their solution. This approach is key to mitigating common pain points around latency and simplicity. For example, many platforms that embrace webhooks force the customer to stand up their own infrastructure, which impacts latency. Our model, however, is a serverless model from a customer perspective, eliminating the need to deploy infrastructure and still offering low latency. This ensures you get the full velocity of vibe coding, while we maintain the absolute stability you put us in your critical path for.
The bet
AI-assisted development is changing customer expectations of what is possible, and when it should be possible.
Platforms that cannot adapt to AI-speed iteration will feel increasingly like antiquated bottlenecks, and our customers shouldn't have to fight us to be fast.
The shift from "we build everything" to "we enable everything" cedes control to you, our customer. But one way or another, you will build what you need. As a platform provider, we have two options:
Ignore it and hope the backlog catches up.
Architect for it. Give you the surface area you need to build on, and trust you with your own work.
The platforms that win the next decade will be the ones their customers built on, instead of around.
We can't wait to see what you build!
