Situational Awareness from ICML: About Coding Agents

Code Agents at ICML: unusually concentrated consensus

Seoul in July was hot. The air had a damp coastal smell, mixed with conference-room air conditioning and coffee. Inside the ICML hall, people moved from the poster area into the corridors, then back to small tables that looked temporarily assembled for one more conversation. Some people were explaining evals over laptops. Some were drawing RL pipelines on whiteboards. Some were standing near the escalators, trying an unfinished thought on someone they had just met.

Inside that noise, one signal became clearer: the conversation kept returning to Code. Developer-tool teams were talking about Code Agents. Model companies were talking about Code RL. Conversations about model capability, evaluation, infra, quant and finance workflows, and research automation all tended to land on the same question: if we want to train a specialized Agent that can actually do work, is Code the most certain entry point right now?

This degree of certainty feels rare. Over the past two years, many Agent narratives were large: universal assistants, AI employees, automated companies. In real conversations, people cared about a more basic question: can it create value reliably inside one task domain first? Code Agent feels grounded here. Software engineering is already high-value work. Quant, finance, enterprise infra, and internal toolchains are full of code and glue workflows. If a specialized Code Agent works reliably, it becomes productivity directly.

One conversation with someone from a quant firm stayed with me. He said his boss was entering the space very directly because the current stage has an unusually clear path from spending to profit coverage: how much to invest, how quickly the cost can be covered, and whether the output can turn into profit. Many Agent stories still sit at the level of vision. Code is closer to production systems, research workflows, and trading infra. Once part of the engineering, research, debugging, and maintenance chain can be automated reliably, the math becomes visible, and money and teams move faster.

What I heard at ICML was a kind of convergence. Many previously scattered routes are beginning to recognize Code Agent as a sufficiently concrete task template. It has commercial value and training value. It does real work and leaves trajectories. It serves a clear task domain and also pressures models to develop long-horizon execution capability.

New tasks are also growing along the capability surface of Code Agent. Cybersecurity, EDA and circuit design, science and research tasks, biopharma, and Auto Research are all trying to organize their work into executable, verifiable, replayable forms. For now they look like application surfaces. If the tasks become long enough and the feedback becomes clear enough, some of them may grow into new training frontiers. The important part of Code's heat is that it gives people a more concrete picture of what an Agent task should look like.

The training frontier and application surface of Agent tasks

I now find it more useful to view Agent tasks through a training-frontier / application-surface frame. The training frontier asks about the model intelligence ceiling: can this task continuously train long-horizon execution, tool use, state tracking, error recovery, and verification awareness? The application surface asks about economic value and task depth: does this domain have real demand, real budgets, real workflows, and a path to sustained productivity?

Code is special because it stands on both sides. On the application surface, software engineering, quant, finance, and enterprise infra all contain real high-value tasks. On the training frontier, Code is also verifiable, long-horizon, feedback-rich, and scalable as a training environment. Its application value and training value are both strong.

Code sits on both the training frontier and application surface

The most interesting thing about Code is that it stands in both places. As a training frontier, it is an environment for training Agent capabilities. As an application surface, it is a real, expensive, frequent production task domain. That is why people in different ICML conversations kept returning to Code: it explains both training and business.

Start with the training frontier. A good training field needs to be long-horizon and easy to verify. Code is strong on both. Real tasks require reading the repo, understanding context, modifying across files, running tests, debugging, rolling back, and checking whether other paths broke. Every step tests planning, state tracking, tool use, and error recovery. A model will not reliably grow these capabilities through single-turn chat. In an engineering environment, it has to act and revise itself through feedback.

This is why Code is attractive for training. It gives the model a changing work site. Which files did the Agent change today, why did it change them, why did the tests fail, should the next step be dependency repair, logic repair, or rollback? All of this becomes trajectory. For training, this is more valuable than a final score because the intermediate process shows where the model is stuck.

The application surface is just as important. Code is a thick commercial task domain. Software engineering, quant, finance, enterprise infra, data platforms, and research toolchains all involve reading code, changing code, debugging systems, connecting tools, and maintaining workflows. These jobs already happen inside organizations, and organizations already pay to solve them. If a Code Agent can reliably absorb part of this work, the value is direct.

So Code occupies a rare position. It can become a training field for Agent capability, and it can cover real production workflows as an application surface. Many directions can answer only one side: commercial value may be clear but the training signal is weak, or evaluation may be clear but the task is far from production. Code currently answers both sides, which is why it became the most concentrated consensus in this round of Agent discussion.

New application surfaces are growing out of Code

The application-surface change is also visible. Many tasks are learning Code's way of organizing work. They are taking loose business processes and reshaping them into something more like engineering tasks: an environment, tools, intermediate state, result checks, and repair paths after failure. This shift matters more than placing a chatbot on top of an industry.

The spillover I saw most clearly falls into several groups. First is Auto Research: people are trying to break research into executable, traceable, verifiable Agent workflows. Second is Cyber: security already has scanning, exploitation, repair, verification, and reproduction, making it naturally close to the Code Agent loop. Third is EDA and circuit design: RTL, simulation, synthesis, constraints, timing, and verification already live inside a strong toolchain. Fourth is Bioscience, especially biopharma, with experiments, data, scripts, metrics, and reproduction chains. Fifth is broader Science, where many research workflows are being reorganized into executable, traceable task environments.

1. Auto ResearchThe interesting part is turning topic selection, search, experiment scripts, data analysis, figures, reports, and reproduction into a workflow. It is closer to research-process automation; one-shot Q&A only covers a small part.
2. CyberSecurity tasks naturally have toolchains, sandboxes, scanning, exploitation, repair, and verification. The chain is long, and the feedback is clearer, so it maps well to the Code Agent work loop.
3. EDA / circuit designCircuit design has RTL, netlists, simulation, synthesis, constraints, timing closure, and formal verification. If an Agent can enter this toolchain, the feedback is harder than many open-ended tasks.
4. Bioscience / biopharmaBiopharma involves experiment design, data processing, scripts, metrics, reproduction, and compliance constraints. Once these processes are organized into environments, they become close to new Agent task fields.
5. Other ScienceBroader scientific research is moving in the same direction: literature, data, experiment logs, simulations, analysis scripts, and reports can be chained into longer execution paths.

These directions currently look like application-surface spillover. They first absorb real demand and solve efficiency problems in specific scenes. The real question is whether they can produce stable task distributions. If a field has high-value tasks happening every day, and the task process can be recorded, verified, and replayed, it will begin to move closer to Code rather than remain a demo scene.

That is what I mean by growing out of Code. New task domains are being reorganized by Code's format. They do not all need to become software development. The key is whether the domain can become an environment where Agents can work for a long time.

Situational Awareness (I): more tasks joining the Code Agent application surface

Over the next few months, the application surface will heat up first. More tasks will join the Code Agent application surface: Auto Research, Cyber, EDA and circuit design, data analysis, scientific experiments, biopharma, GUI and browser tasks. They may not become new training fields at the beginning. They will first learn Code Agent's task organization method: split work into executable steps, expose environment state, and connect feedback and verification into the workflow.

This kind of joining requires taking real workflows apart and placing them inside an environment where an Agent can continue working. The task entry needs to be clear. Tool calls need to be stable. Intermediate state needs to be visible. The final result needs to be checkable. Only then does the Agent move from one-time answering into repeated action inside a task field.

This line is about whether real task domains can be reshaped into Code-like environments. GUI needs state representation and replay. Cyber needs safety boundaries and reproducible environments. EDA needs toolchain access, simulation feedback, constraint generation, and timing closure. Bio and Science need experiment workflows and metric verification. Data analysis needs a loop across data, scripts, charts, and conclusions. These sound like engineering problems, but they are the gate that determines whether an application surface can enter the Agent system.

The thicker an application surface becomes, the more it provides real demand, real budgets, and real workflows. It also becomes more likely to feed model capability growth. In the short run, these tasks will enter as tools, MCP surfaces, workflows, and harnesses. In the long run, a small number of them may accumulate stable environments and stable feedback, then continue moving toward the training frontier.

This is also why MCP and Tool Use matter. They are more like application-surface infrastructure: wrap external systems as typed tools so non-code tasks can enter a Code Agent style loop. Valuable application expansion lets Agents work in more real environments, instead of merely knowing more industry nouns.

Situational Awareness (II): today's application surfaces may become tomorrow's training frontiers

The second line is more important: can today's application surfaces grow into new training frontiers? Code Agent has already demonstrated one version of this. A high-value application task can become a main field for training model Agent capability. The next crossing point may come from Auto Research, Cyber, EDA and circuit design, biopharma, scientific research, or another task domain.

The key question is which direction can move from application into training environment. Application surfaces first solve business problems. Training frontiers then lift the model capability ceiling. For a task domain to make that upgrade, it needs to continuously produce high-quality trajectories, provide automatic feedback, support repeated training, and scale with data and environment expansion.

The filter is hard. The task must be verifiable, the chain must be long enough, and failure must be attributable. Verifiable means the result can be judged through tests, replay, metrics, rules, or external environment state. Long enough means the task spans multiple steps and exposes planning and error recovery. Attributable failure makes it possible to turn one failure into training material for the next round.

This upgrade usually will not happen in one step. An application surface first appears as a product or tool that solves efficiency in one concrete scene. Then it gradually grows harnesses, task generation, environment replay, verifiers, and data logging. Only after that can it become a training field. The real dividing line is whether it moves from helping a person do one task to continuously producing a trainable task distribution.

These are the same categories as the earlier application-surface observations, but now viewed through a readiness lens: who is closest to becoming a training frontier, and what bottleneck still blocks that upgrade? Cyber and EDA look closer because their feedback can be hard. Auto Research has long chains but softer task definitions. Bioscience has thick value but slow, noisy feedback. Broader Science remains uneven until task definitions and verifiers harden.

So I would look past the LLM demo and check for environment engineering: standardized task entry, stable reproduction of the same scene, the ability to locate whether failure came from planning, tools, data, or verification, and trajectories that can be kept for training. Without this, a hot application surface stays at the application layer. With this, it can become fuel for the training frontier.

Over the next few months, I will pay more attention to these signals: stable environments, stable verifiers, and stable trajectories appearing inside an application surface. When all three appear together, the task may move beyond application opportunity and grow into a new training frontier.

Competitive strategy: stand 15 degrees away from consensus

This judgment eventually becomes practical: if Code Agent is already consensus, where is the new position? I think the better position is 15 degrees away from consensus. Stay close enough to Code to inherit its task template, toolchain, and training signal. Stay far enough from the most crowded center to build differentiation in a new task domain.

Code Agent has shown that a real task domain can have both commercial value and training value. Software engineering is the first mature example because it has real budgets, strong toolchains, hard feedback, verifiable results, and long-chain trajectories. Once this pattern is visible, competitive strategy splits into two lines: one line searches for the next training frontier capable of lifting the Agent capability ceiling, and one line connects more real tasks into Code as a general Agent / environment template.

The training-frontier strategy is to press on the next task that can scale up Agent intelligence. This task must be long enough to expose planning, tool calling, state tracking, and error recovery. It also needs a stable environment, hard verifiers, and replayable trajectories. Without those, it is hard to become a training field. SWE is the clearest current template. The next candidates may be Cyber, EDA and circuit design, Auto Research, or other science tasks.

Directions that can continuously produce high-quality training signals are worth watching more closely. If Cyber solves compliance and reproduction, it has a long chain of sandboxing, scanning, exploitation, repair, and verification. If EDA connects into toolchains, it has hard feedback from RTL, simulation, synthesis, constraints, and timing closure. If Auto Research standardizes research processes, it can turn search, experiments, data, figures, and reports into replayable trajectories. The valuable part in these directions is the environment, task construction, and verifier.

The application-surface strategy is to connect more real tasks into Code as a general Agent / environment template. Each industry needs to reshape tasks into executable, stateful work loops with tools, feedback, and verification. A chatbot layer only solves the surface. The real opportunities in MCP, GUI, data analysis, research workflows, enterprise systems, and biopharma sit in this transformation.

The most important application-surface variable is task depth. Are real users doing this every day? Is there budget? Are there existing digital environments and tool interfaces? Can the result be verified? Industry knowledge Q&A can easily stay at the demo layer. Industry workflows that become Code-like tasks can let Agents enter production.

For an individual or a team, the center of consensus is not always the best place to stand. The more valuable question is whether your task domain has unique data, toolchains, customer workflows, or verifiers. Can it stay close enough to the Code trunk and be organized into an executable, observable, verifiable, replayable environment? If yes, that 15-degree angle may be a better bet than the crowded center.