제품은 에이전트를 위한 런타임이어야 합니다. 래퍼가 아닌 컨테이너여야 합니다.

Last week we presented our new implementation to make engineering, operating and managing machine learning systems easier by using popular tools such as Claude Code, Codex or Gemini. We wanted to deep dive a bit further on what makes it so different and what this could mean in the AI and data infrastructure field. Figure 1. "Hey Claude, make me an AI pipeline - no mistakes!" A view of the Shell interface in Hopsworks using Claude for building ML pipelines. The Oh Shit Moment for Data and ML Engineers? Some time in the middle of last year, Jim Dowling, co-founder of Hopsworks, came enthusiastically to show me how he launched Claude Code from within a Jupyter terminal that we deploy with Hopsworks. It was the first moment we realised the implications: we could combulate / tabulate / fingulate / gesticulate with Claude Code within the platform while it could eventually have access to the whole platform (which is fully available via APIs), including the file system (we FUSE mount S3 via our tiered file system HopsFS), source code (we support GitHub/Lab/etc), authentication, the data sources, and so on. Since then, we engineered relentlessly - and yes, we leveraged Claude Code as well - a new shell interface for Hopsworks that would allow users to interact and make your coding agent interact with the platform from the inside. At this point we had been working on an alternate coding agent called "Brewer" for specification-driven development of pipelines. But when we realized Claude now writes the specifications (plans) for you, we quickly pivoted Brewer to become a general purpose platform for any coding agent (not just Claude Code, but even sovereign AI solutions such as Mistral's Devstral). Our reasoning was essentially that it is now the data platform's job to provide a secure, governed environment for building the AI and data pipelines that power AI and analytics products. Why run a coding agent inside a data platform? You don't strictly need to run a coding agent inside a data/AI platform. However, it can reduce large amounts of friction in ensuring access to data (sorry, context!) within the platform, and ensuring sensitive data does not leave the platform. Claude Code and other coding agents work by navigating directories and reading files (e.g., source code and documentation) from the directory within which they are launched. In Hopsworks, all data/code is encapsulated in a project (think of a project as a Github repository with members and code, but a project can also store data and run compute). The project provides API access to all its data sources, files, compute capabilities, and platform capabilities. We make access to the API available via a CLI tool (we support MCP as well, but CLI tools work better with coding agents). Another advantage of running an agent inside your Data/AI platform is that you can lock it down. You can launch a coding agent in Hopsworks that uses a LLM that is hosted in Hopsworks - all inside an air-gapped environment. Hopsworks provides vLLM/KServe support for LLM serving, and open-weight models like Devstral 2 and Qwen3-Coder are catching up fast with the frontier models. Figure 2. "Hey Claude, show me the architecture." A Shell is not all you need To operate effectively within a project, the agent needs more than a shell; it needs the ability to execute commands and take actions. The shell is just the first step; it is the sandbox from which the agent can exist and that sandbox can exist within the boundaries of the projects or, for admins, beyond; in that case, it could access the details of the underlying data infrastructure that the platform operates on; memory, compute capabilities etc. and could even review and send alerts - but more on that later. As already mentioned, we also chose to move from MCP to CLI, seemingly because it just worked better and faster. The agent seemed to lose less time trying to understand the underlying commands and what they meant to achieve; less back and forth trying to force an output that didn't work. Coding LLMs have been trained on bash and CLI tools and can compose commands, the Unix way. With CLI tools, agents can use CLI switches and command line tools (e.g., head/tail) to retrieve just the context they need for their task, while MCP can overload the context window if you need to load complete tool descriptions for your platform. The shovels for coding agents now appear to be the container and the CLI tools. You can even ask your coding agent to fix your CLI tool's code. A simple "debug the CLI by trying this action" became a way to test the CLI during its development but also find and fix obscure or not yet discovered issues in the backend. Now - this does not suffice either; as the tooling and the container do not provide context efficiently; Claude Code has not been trained on / or does not inherently recognise, all the aspects of a platform like Hopsworks; with its quirks and edges that come from a near decade-long of implementa