
Organizations adopting flexible, cloud-native infrastructure can reduce deployment lead times by up to 40% while improving operational efficiency. This is not an incremental gain. It reflects a structural shift in how applications are built and deployed. Legacy systems, constrained by manual configuration and fragmented tooling, cannot sustain the speed required for modern AI integration. When backend setup takes days instead of seconds, the friction alone becomes a barrier to adoption.
Lei Lei, Founder and CEO of Actionbook and former Co-Founder and CPO of AirCode, has built his work around removing that friction. AirCode, his zero-configuration developer platform, unified code editing, database management, and deployment into a single browser workflow, attracting over 15,000 developers and supporting more than 20,000 projects globally. Backed by GGV Capital and Future Capital and selected for the inaugural AWS Startup Accelerator, the platform demonstrated that infrastructure complexity could be abstracted without sacrificing capability.
We spoke with Lei about why zero-configuration environments are emerging as the default integration layer for AI-powered systems, how they expand the developer base building LLM applications, and why infrastructure trust signals increasingly shape adoption decisions.
AirCode provided a zero-configuration browser-based workflow for AI integrations. What specific problem did this solve for developers building LLM-powered applications?
In my experience, the constraint is not model capability. It is configuration friction. A developer trying to connect GPT to Slack still has to provision APIs, configure authentication, set up databases, manage environment variables, and deploy infrastructure. That process introduces delays before any meaningful integration work begins.
At AirCode, we removed those dependencies entirely. A developer wrote a function inside the browser IDE, connected to a built-in database, and published a live endpoint instantly. There was no server provisioning, no configuration files, and no command-line overhead. The system collapsed what used to be a multi-day setup into a single, continuous workflow.
The broader trend supports this shift. 82% of enterprises now use serverless functions in production, with AI and API integrations driving the fastest adoption. Once teams experience deployments measured in seconds rather than days, the expectation changes permanently. Configuration is no longer seen as necessary overhead. It becomes a problem to eliminate.
Can you give a concrete example of how AirCode unlocked new kinds of developers?
This shift becomes visible in who is able to build. Previously, creating a GPT-to-Lark integration required coordination between backend engineers, DevOps specialists, and product teams. Each step introduced dependency and delay.
With AirCode, that same workflow was built by a product manager with basic coding knowledge. She implemented a Node.js function that monitors a Lark channel, sends messages to GPT for summarization, and stores outputs in a database. The entire system, from code to storage to deployment, existed within a single browser environment. No external infrastructure was required.
This is the developer expansion that zero-configuration enables. It does not replace experienced engineers. It removes the infrastructure barrier that prevents others from participating. AirCode demonstrated this at scale with 20,000 projects and 15,000 developers, enabling real-world use cases such as translation bots, moderation pipelines, and enterprise integrations that would otherwise have remained unbuilt due to setup complexity.
Third-party validation signals like venture capital and accelerator selection are often dismissed as marketing. Why do they matter to developers?
Developer infrastructure depends on trust. A developer investing time into a platform needs confidence that it will persist, remain supported, and evolve. Without that assurance, adoption stalls regardless of technical capability.
External validation provides that signal. When AirCode was selected for the inaugural AWS Startup Accelerator and raised $2M from GGV Capital and Future Capital, it communicated durability. Developers interpreted that as evidence that the system had undergone scrutiny beyond internal claims. They do not focus on funding size. They focus on whether someone credible has already assessed a platform’s long-term viability.
These signals create a reinforcing cycle. Validation drives adoption. Adoption generates usage data. That data improves the platform. The improved platform attracts more developers and further validation. In infrastructure products, this feedback loop is not incidental. It is foundational.
What was the measurable impact created after eliminating manual configuration on developer behavior?
The most direct evidence is behavioral absence. Developers no longer perform the steps that previously defined deployment workflows. There is no need to start local servers, run migrations, configure cross-origin policies, or manage environment variables.
On AirCode, the average time from writing code to generating a live endpoint was five to six seconds. That consistency is critical. Every deployment follows the same path, producing predictable outcomes regardless of developer experience level.
AirCode validated this at scale. With over 20,000 projects, infrastructure tasks such as load balancing, scaling, and backups were handled automatically. Developers did not interact with these systems directly. Instead, they relied on a standardized execution layer that removed variability from deployment.
This predictability is what enables AI integrations. Large language models cannot debug misconfigured infrastructure, but they can interact reliably with stable endpoints. Eliminating configuration is not just about speed. It is about creating an environment where systems behave consistently enough for automation to function.
From a business perspective, the impact extends further. Removing configuration overhead reduces the need for dedicated DevOps resources within each team. For enterprise customers, this translates directly into cost savings, making zero-configuration environments not just a developer preference but an operational decision.
How does zero-configuration infrastructure fit into the broader trend of AI systems requiring reliable execution layers?
Large language models excel at reasoning but lack execution capability. They can generate plans, but they cannot provision infrastructure, maintain connections, or ensure system reliability.
AirCode addressed this gap by acting as the execution layer between AI intent and application output. Developers defined logic, and the platform provided the infrastructure (databases, file storage, deployment endpoints, and scaling) without requiring manual configuration.
This separation is critical. Without it, AI integrations remain fragile, dependent on infrastructure that can fail due to configuration errors or environmental drift. By abstracting those concerns, AirCode enabled AI systems to operate within a stable, predictable environment.
The demand for this layer is increasing rapidly. As enterprises move from experimental AI usage to production systems, integration complexity becomes the primary bottleneck. 71% of AI teams report spending over 25% of their implementation time on data connectivity and integration tasks. That effort does not create new functionality. It supports infrastructure.
Zero-configuration systems collapse that overhead. What previously required weeks of setup can now be reduced to a single endpoint, allowing teams to focus on application logic rather than environment management.
What advice would you give to founders building developer platforms today?
The critical shift is to optimize for production, not initial onboarding. Many platforms make the first interaction easy but introduce complexity when developers attempt to deploy real systems.
The focus should be on removing friction at the point where developers transition from experimentation to production. Every abandoned workflow represents a missing capability or unnecessary complexity. That signal should be captured and fed back into the system.
Platforms should be designed to absorb complexity rather than expose it. If a developer is repeatedly configuring the same element, it indicates an opportunity for automation. Over time, this approach compounds into a system where deployment becomes predictable and repeatable. External validation should also be treated as part of the product. Investors, accelerators, and public benchmarks provide signals that reduce perceived risk. In developer infrastructure, trust is not separate from functionality. It is part of the offering.
Zero-configuration environments are not a passing trend. They reflect a structural recognition that developer time is finite and that AI systems cannot depend on fragile infrastructure. Every manual step introduces delay, inconsistency, and potential failure. Across AirCode, Lei followed a consistent principle: remove every configuration step that does not create unique value. The result was not only faster deployment but more reliable systems, where integration became the default rather than the exception.
That principle now drives the next phase of his infrastructure work. With Actionbook, an open-source browser execution layer backed by $1.7M in pre-seed funding led by Surface Ventures, Lei is moving from zero-configuration backend development into reliable browser execution for AI agents. Where AirCode removed the friction of deploying code, Actionbook removes the friction of AI agents operating a real browser, translating model intent into precise, dependable web interactions. The integration layer is evolving, but the philosophy remains the same: infrastructure should disappear so that building does not.
The persistent, isolated environment per customer is compelling, but the 1,000+ integrations create an important verification question.
When an agent performs a scheduled or background action through Gmail, Slack, Notion or another connected service, what evidence establishes that the resulting external state matches the agent’s authorized intent?
Isolation can demonstrate that one customer’s state did not cross into another environment, but it does not necessarily prove that an old retry, revoked instruction or delayed tool call did not execute downstream. I’d be interested in how you distinguish successful execution, confirmed non-execution and an unresolved outcome when the provider’s final state cannot yet be established.