Your Coding Agent Should Do AI System Engineering

As coding agents become part of everyday software development, what harder engineering problems should we tackle with them? Ben Burtenshaw’s proposal is to move closer to the silicon: use agents for systems engineering and machine learning engineering. That requires more than capable code generation. It also requires standard repositories that make the resulting work accessible and reusable, including repositories on the Hugging Face Hub.

The progression has three levels of increasing autonomy. First, a person works interactively with an agent to write a CUDA kernel. Next, an agent takes a prompt and fine-tunes an LLM using hosted compute. Finally, a team of agents proposes, implements, and monitors research experiments. Each level gives the agent more responsibility while retaining a concrete engineering task whose outcome can be checked.

Custom GPU kernels once looked like an especially difficult target for coding agents. They involve specialized languages, and generated code must reach the relevant hardware before anyone can test correctness or benchmark performance. Burtenshaw points to GPU MODE, a recent AMD hackathon, and KernelBench as evidence that agents can nevertheless produce valid, optimized kernels. That opens a second problem: how do those kernels get distributed and integrated into inference engines?

A kernel performs the actual GPU work behind a model operation. Its implementation can use languages and hardware features specific to the target device. A custom kernel exploits those features for a particular mathematical operation so that model execution can become faster. The difficulty extends beyond writing the code: installation must reconcile GPU hardware, software dependencies, hardware generations, and CUDA versions. A useful generated kernel therefore needs both a tested implementation and a manageable compatibility story.

Kernel optimization starts by separating three costs:

The most visible mathematical work is not necessarily the bottleneck. A GPU can have arithmetic capacity available while it waits for the next tensors to arrive.

Burtenshaw illustrates the imbalance with roughly one petaflop/s of compute and three terabytes/s of memory bandwidth for an H100. These are illustrative figures without a specified precision, sparsity setting, or hardware variant; whether memory dominates depends on the workload. The point is that fast arithmetic does not eliminate the time spent supplying its inputs.

FlashAttention is the example of an optimized kernel organized around this problem. The relevant principle is arithmetic intensity: perform more useful computation per memory read and write. Bring tensors into faster memory, do as much work as possible while they are there, and then write the results back. Custom kernels can improve performance by reducing the movement required for a given amount of computation.

Hugging Face Kernels supplies a distribution layer maintained by kernel writers. A TOML configuration declares supported hardware and required software versions, including CUDA compatibility. The kernel becomes a Hub repository, making kernel publication analogous to model publication. Consumers can inspect compatibility information to determine whether an artifact supports their GPU or laptop. This makes optimization work something another user—or another agent—can discover and use.

The next ingredient is teaching the agent how to work inside that system. Skills are file-based context: examples and instructions that can be opened, closed, versioned, and source-controlled. An agent can load kernel-writing or kernel-use examples when the task calls for them. In Burtenshaw’s description, that moves a task from zero-shot toward few-shot: the agent receives concrete examples instead of having to infer the entire workflow from a bare request.

Ownership matters as much as format. Hugging Face’s approach puts skills inside projects so the project maintainers can maintain the instructions alongside the software. A separate Hugging Face Skills repository accommodates more experimental workflows. For kernels, the skill includes reference examples and scripts for testing and benchmarking. Those scripts connect generated code to evidence about whether it works and how it performs.

Burtenshaw reports a 94% speed-up for an agent-generated kernel for Qwen3-8B on H100. The companion benchmark scopes that result to isolated RMSNorm operations: an average 1.94× speedup versus PyTorch, using BFloat16 on H100 80GB HBM3 across eight tensor shapes. It is not a measured 94% improvement in complete model inference, and Burtenshaw explicitly says it is not a state-of-the-art result.

The opportunity is the compatibility matrix. A model may have well-optimized kernels on one hardware generation but leave performance available on another. That matters when the hardware you can afford—or the hardware cheaply available from your cloud provider—is not the model’s ideal target. Agents make it more practical to investigate these specific gaps.

The skill itself also needs evaluation. UPskill generates skills and evaluations, then lets users compare models on the same skill. In the comparison Burtenshaw describes, GPT-OSS is slightly less accurate with similar token use, while Kimi and Haiku are more accurate with fewer tokens. These are local skill-evaluation observations, not a general ranking of the models or proof that every generated kernel passed execution tests on a GPU. The practical use is to iterate on a frequently used skill and identify a less expensive model that can handle it adequately.

The second level gives the agent a larger task: fine-tune a model from a prompt. Burtenshaw points to Merve’s earlier talk and a Claude fine-tuning walkthrough. His spoken example asks for Qwen3-6B to be fine-tuned on a chain-of-thought dataset. That model name is the example as spoken, not a verified checkpoint identifier; improving chain-of-thought behavior is the intended outcome, not a measured result supplied here. HF CLI skills connect the workflow to the Hub, including hosted GPU execution.

An Unsloth-based route, maintained with Hugging Face, uses optimized training implementations and is presented as a cheaper alternative. The accompanying promotional credits were an occasional offer, not a standing guarantee. The transition from the first level is straightforward: skills now guide a complete training workflow instead of an interactive kernel-writing session.

AutoLab extends the idea to coordinated research. Its starting point is Andrej Karpathy’s autoresearch, which Burtenshaw situates in the lineage of nanoGPT and nanochat. An agent using Claude Code modifies the training script and runs successive experiments. The repository identifies the direct training-code basis as simplified nanochat. Its validation bits-per-byte metric measures predictive quality—lower is better—under a fixed training budget, rather than raw execution speed. The run shown improves its best result over the course of the experiment sequence.

A single agent must alternate between finding an idea, implementing it, and checking the result. AutoLab distributes those responsibilities:

The researcher can use HF Papers or arXiv. HF Papers supplies a CLI for searching and retrieving papers, so literature discovery can become an agent task. The resulting hypotheses enter a queue; workers turn them into changes such as a different architecture or parameter setting, and the reporter follows the jobs.

The lab works inside a Git repository. It preserves an original training script, maintains the evolving training code, and uses branches for experiment changes. A data structure on main holds the scores. The demonstration uses OpenCode; Burtenshaw also describes Codex and Claude implementations in the repository, with a separate Gas Town experiment. The architecture is a way to organize work, rather than something inherently tied to one agent interface.

Researchers and planners feed work into the system, while workers launch HF Jobs on the required hardware and submit patches back to the repository. The complete diagram connects those roles to remote execution and the return path for code changes. Experiment outputs therefore have places to go: code returns through Git, and results feed the shared record.

The reporter uses Trackio. In the demonstrated setup, Burtenshaw describes its underlying metrics data as Parquet, accessible independently of the dashboard. Current Trackio documentation describes a broader persistence interface, so the historical storage description should not be treated as a current schema contract. The architectural benefit remains: an agent can inspect the data directly and build a different view, such as a Gantt chart, when the default dashboard is not the right tool.

In OpenCode, the selected AutoLab configuration supplies the skills and agent roles. The request bounds the work instead of simply asking the system to improve the model:

1. Run one autonomous research pass in the repository using the defined roles.
2. Have the planner propose up to two fresh experiments, each making a single change.
3. Use a reviewer to reject duplicate or stale ideas.
4. Keep storage in a shared HF bucket to avoid repeatedly uploading and downloading training scripts.

The bucket supplies a common storage location; the experiment limits define how much new work this pass should propose.

Opening the planner sub-agent shows how that request becomes actionable. Its configured template includes the current state, the job history, successful experiments identified by the reviewer, and the hyperparameters available to change. The planner uses this context to define proposals for the shared job list. These are candidate experiments at this stage, not completed improvements.

The reviewer then receives the candidate jobs through a similar template, with a working reference and the latest score for comparison. It considers both failed and successful experiments when deciding what belongs in the next queue. Its tables communicate decisions back to the other agents, but Burtenshaw cautions that this example is verbose: the useful content is the shared comparison context and decision, not the amount of tabular output.

The agents can run in parallel for hours, pushing their runs to Trackio. Monitoring has to expose more than a final score. The demonstrated workflow includes filterable events and warnings from different agents; Burtenshaw also describes notifications, including email, as a way to request intervention. Freeform tables let the reporter include information that does not fit a single fixed reporting structure.

On the compute side, the jobs are visible in Hugging Face. Labels let users sort and inspect what the agents are running. Reading the underlying metrics data produces another view: a Gantt chart of experiments over time, with overlapping bars and scores beside them. The chart connects a named agent’s activity to when it ran and the result it obtained, making the parallel execution easier to inspect than a job list alone.

The condition that makes a small automated lab useful is a verifiable experiment. Training a model or writing a CUDA kernel gives the agent an outcome it can measure and compare. That makes it possible to connect proposals, implementation, execution, and evaluation into a research process that can teach its operator something.

The infrastructure should leave its underlying primitives accessible. A dashboard is useful, but the metrics data should remain available when an agent needs a different visualization. An abstract API is useful, but an inaccessible layer behind it can become a ceiling on what the agent can do. The design task is to expose the tools well, without requiring every useful action to pass through a predetermined interface.

The Hub supplies the storage, tracking, and compute needed to connect these workflows. Together with standard repositories and maintained skills, those foundations let engineering effort move from setting up each task toward testing harder ideas. Burtenshaw closes by pointing to the posts and attached repositories for the examples: the next step is to work through an actual experiment with an outcome that can be checked.