I’ve talked to many technical friends, including our shareholders and partners, and most of them are pretty pessimistic about the cloud development environment. In their view, it’s slow, laggy, and full of limitations—only useful for specific scenarios, like occasionally fixing a small bug here and there.

But with over a decade of R&D experience, I’ve seen how flawed local development environments can be. Setting up a local environment is often a painful process—environment isolation and upgrades can turn into a complete nightmare. I’d bet more than 90% of companies have new employees spending way too much time just getting their development environment up and running.

As AI technology continues to evolve, it’s becoming more clear that AI Agents for Coding need a proper development environment. While they can function in a local setup, the complexity of local environments and the fact that they can’t always stay online make them less than ideal for AI Agents to thrive. The natural solution? A cloud-based development environment.

A development environment is not the same as a container deployment environment. At its core, it consists of the following layers:

Operating System Layer → Programming Language Layer → Package Manager → Source Code Layer

Taking Python as an example, the operating system layer might be Ubuntu 20.04, and the programming language layer could be either a direct system installation of Python 3.11 or Pyenv + Python 3.11. Following that, you might use the package manager poetry to manage the code's dependencies, with the source code being the final layer. Although package managers are now striving to be more independent and minimally coupled with the underlying layers, there are inevitably some features that depend on the underlying libraries, which is an inherent layer of coupling.

Under such complex requirements, building a cloud development environment that surpasses the local development experience requires careful resolution of many issues to be feasible.

With the advancement of containerization technology, many companies globally have begun exploring this direction, such as CodeSandbox (established in 2017), GitPod (2020), and Stackblitz (2017).

In the era of AI, AI-Native CDE (Cloud Development Environment) has emerged as the optimal platform for AI-driven programming. Let’s compare the strengths and weaknesses of AI-Native IDE versus AI-Native CDE:

Feature	AI-Native IDE	AI-Native CDE
Human Habits	Excellent	Good
AI Support	Unable to accurately control the development environment, primarily static coding	Precise control of the underlying environment, static coding + runtime debugging
Future Potential	Cannot be online in real-time	24-hour operation
AI Interaction	Architectural burden	Natively designed
AI Avatars	Not supported	Unlimited concurrency

In the early stages of AI development, IDEs will have an advantage due to user habits, but they will be at a disadvantage in the middle and later stages of AI development due to their own limitations.

The formula for the success of a new product, the result must be greater than zero:

Successful Product = New Experiences Driven by Technological Change - (Old User Experiences - New Problems Introduced by the New Product)

Let's expand on the reflections about Clacky CDE based on the above:

• New Experiences:

  Clearly, AI-Native is the focal point in creating new experiences with Clacky CDE. AI structures tasks, provides a visual AI workflow, and features AI snapshots with reversible interaction logic, which maximizes the value of AIAgent in real-time and mitigates issues caused by AI illusions. As the foundational capabilities of AI improve, AIAgent will continuously enhance research and development efficiency.

• Old Experiences:

  This represents the biggest challenge in developing CDEs: building a product that both mirrors the local IDE habits and capitalizes on its own strengths is key. The approach of Clacky CDE is to minimize the learning curve for users as much as possible, which is divided into three parts:

  • Environment Management:
    • Provides preset mainstream programming languages and frameworks.
    • Preset common development libraries, such as libimagick.
    • Each environment is meticulously polished and tested, offering a user experience that is more accessible and enriched compared to local development environments.
  • Technical Design:
    • Minimal configuration required through a .1024 file to declare project initiation.
    • Very low learning curve for understanding and setup.
  • User Interface Habits:
    • Close alignment with local IDE habits.
    • Features such as ctrl+p for file search, providing an experience similar to VSCode.

To speak frankly, it's nearly impossible to fully align user habits with local IDE compatibility. The investment and strength of teams like VSCode and Jetbrains are something we all look up to in the development community. Fortunately, we have a very solid fallback plan for compatibility:

The solution is to ensure compatibility with local IDE products, such as VSCode and Cursor, which can be directly connected with just one click.

Due to constraints in time and technical complexity, the current plug-and-play environment support is limited to web front-end and back-end development.