Building Your Own AI Studio: Full Automation from Code Generation to Deployment

From "Manual" to "Automatic": The Evolution

As AI-assisted programming continues to rise, more and more developers are no longer satisfied with having AI simply "write code." They want to connect the full pipeline — from code generation all the way to application deployment. Recently, a tech blogger shared their self-built AI Agent Studio (referred to here as Manifest Studio), which automates the entire workflow: coding, building, and publishing. That's the true power of going "automatic."

First, let's clarify an important distinction: AI Agents differ fundamentally from code completion tools like GitHub Copilot in terms of autonomy. Traditional code completion tools are reactive — the developer types, and the tool produces a one-shot suggestion. Agents, by contrast, possess Planning, Tool Use, and Multi-step Execution capabilities. They can decompose a high-level goal into multiple subtasks and autonomously select tools to complete them step by step. This paradigm is typically built on the ReAct (Reasoning + Acting) framework, enabling the model to advance through a "think–act–observe" loop until the goal is achieved.

The developer had previously covered their application hosting platform, App Platform, but the deployment workflow still had obvious pain points: developers had to manually organize the file structure inside a zip archive and write Manifest definition files by hand. These repetitive engineering tasks are exactly what AI Agents are best suited to take over. The core of this article is how Manifest Studio (the Agent workbench) and App Platform (the deployment platform) were fully integrated into a seamless pipeline.

Inside the Manifest Studio Workbench

Manifest Studio has been deployed in a Kubernetes cluster and is integrated with App Platform. Kubernetes (K8s) is an open-source container orchestration system released by Google in 2014 and has since become the industry standard for cloud-native application deployment. Running the workbench inside a K8s cluster means it has production-grade reliability and elasticity: K8s can automatically scale instances as Agent load increases, and automatically restart crashed instances to maintain service availability. The project also supports Docker Compose deployment, providing a low-friction entry point for local development — no full K8s environment required to get started.

Where App Platform previously only allowed "manual deployment via template zip download," developers can now click a button to jump directly into the Manifest Studio workbench to write code.

The workbench UI is clean and intuitive:

• Left panel: Conversation list for managing different development tasks
• Center: Model selection area for switching between LLMs
• Model configuration: Currently supports providers compatible with the OpenAI API protocol (the example uses Alibaba Cloud Bailian)

The OpenAI-compatible API protocol has effectively become the industry-standard interface for LLM services, centered on the /v1/chat/completions REST endpoint specification. Alibaba Cloud Bailian, ByteDance Volcengine, locally deployed Ollama, and the open-source vLLM inference framework all implement interfaces compatible with this protocol. This delivers significant engineering value: application-layer code doesn't need separate adapters for different providers — just update base_url and api_key to switch the underlying model.

The model discovery mechanism is also worth noting: once a provider is configured, clicking "Discover Models" automatically fetches that provider's model list. If a target model isn't in the list, it can be added manually and used directly in the selector. This design balances automation efficiency with flexibility, avoiding the limitations of hardcoded model names. Developers can further implement model routing strategies on top of this — for example, routing code generation tasks to DeepSeek Coder and natural language understanding tasks to Qwen, achieving complementary capabilities through a unified protocol.

Demo: Auto-Generating a Login Page

To illustrate the "automatic" experience, the author asked the Agent to build a simple login page and generate an index.html file — since the hosting environment loads this file by default, no additional path configuration is needed for later access.

During execution, the workbench displays real-time execution logs, clearly showing each step of the model's behavior: which tools were called, whether they returned successfully, and the current progress. Observability is especially critical in Agent systems — an Agent's behavior chain is fundamentally a probabilistic reasoning process, unlike deterministic code, so the same input can produce different tool-call sequences. Execution logs allow developers to trace which tool was called during each reasoning step, what parameters were passed, what was returned, and how the model adjusted its next action based on the result. In production environments, these logs also serve as the foundational data for tracing anomalous behavior, running Agent evaluations, and iteratively improving prompts.

Generated files are stored in the workspace directory. Shortly after, index.html appears in the workspace — without the developer writing a single line of code.

One-Sentence Deployment: The Elegance of the Skill Mechanism

The most impressive part of this system is the deployment step. Once the app is built, the developer simply tells the Agent "deploy" — and almost nothing else is needed. Two key parameters are worth noting:

slug Subdomain

Each app requires a slug (subdomain) for access. If none is specified, the system randomly assigns one. Since domain mapping is configured, the example explicitly sets the subdomain to app-test.

Network Constraints for Image Builds

When using Kaniko for container image builds, if external image registries are unreachable, the Dockerfile must specify an available base image to avoid network issues. Kaniko is a container image build tool open-sourced by Google, specifically designed for unprivileged container environments like Kubernetes. The traditional Docker-in-Docker (DinD) approach requires containers to run in privileged mode, which introduces host escape security risks in multi-tenant clusters. Kaniko, by contrast, parses the Dockerfile and builds images layer by layer entirely in user space, without requiring access to the Docker Daemon — making it safe to run in ordinary, non-privileged containers. Since Kaniko cannot dynamically switch image registries during execution, base images must be pre-synced to an internal registry in offline or restricted network environments. This detail reflects the infrastructure constraints that must be considered when embedding CI/CD capabilities into Agent workflows.

The core deployment logic relies on a carefully designed Skill, which handles two responsibilities:

1. Organizing the directory structure: Completes the workspace directory into the zip format required by App Platform
2. Calling the deployment API: Executes the actual publish request to App Platform

From an engineering perspective, the Skill mechanism is built on top of the LLM's Function Calling capability. Developers describe available tools — their names, parameters, and functionality — to the model using JSON Schema. During inference, the model decides whether to invoke a tool and outputs a structured call instruction, which the application layer captures and executes before feeding the result back to the model to continue reasoning. Skill is a higher-level abstraction over this mechanism, allowing the model to recognize and trigger compound operations semantically: the model doesn't need to know the deployment API's exact URL or authentication method — it only needs to recognize that the user's intent is "deploy" to trigger the correct Skill. This reduces prompt engineering complexity and allows skills to be iterated independently without affecting the model interaction logic.

When the LLM determines the user's intent is "deploy," it automatically reads the Skill and executes it step by step. From the execution logs, you can see the Manifest was automatically generated, the slug was correctly set to app-test, and index.html was properly placed in the web directory — the entire directory structure organized entirely by AI.

Closing the Loop: Studio and App Platform in Sync

After deployment completes, refreshing the page shows the application status as "Live," with an access URL attached. Opening the link, the login page is up and running.

Checking App Platform, the application appears in the list: build logs, marketplace ID, and the slug — all set to app-test as specified. At this point, the complete pipeline between Manifest Studio (the Agent workbench) and App Platform (the deployment platform) is fully connected.

Developers can write code and then deploy to the hosting platform with a single sentence — directory structure, Manifest authoring, all of it handled automatically by AI.

Technical Value and Engineering Insights

The value of this self-built AI Studio lies not just in the fact that it works, but in the Agent engineering practice pattern it demonstrates:

• Skill abstraction: Encapsulates complex deployment workflows into reusable skills, allowing the LLM to invoke them at the right moment via Function Calling — a critical design for building reliable Agents, and one that decouples skills from model interaction logic for independent iteration
• Observability: Complete execution logs make Agent behavior transparent rather than a black box, enabling debugging, troubleshooting, and trust-building; this is also the core problem addressed by observability platforms like LangSmith and Langfuse, designed specifically for LLM applications
• End-to-end pipeline: Full automation from code generation to application deployment is what "automatic" truly means; the combination of Kaniko image builds and K8s orchestration provides production-grade infrastructure support

The project is currently used primarily for understanding Agent internals and is not publicly available, though it supports both Docker Compose and K8s deployment. For developers who want a deeper understanding of how Agents work, building something like this from scratch is more valuable than using off-the-shelf tools — you'll truly understand the engineering decisions behind each component: why Kaniko instead of DinD, why the OpenAI-compatible protocol instead of a proprietary interface, why Skill abstraction granularity should align with user intent.

As Agent technology continues to mature, "describe what you want — get it delivered automatically" will become the new normal in software development. And building such a system yourself is the best path to deeply understanding and staying ahead of this trend.

Key Takeaways