In mid-July, Moonshot released Kimi K3, a 2.8-trillion-parameter open-weight model that beat the flagships from OpenAI and Anthropic on the FrontierSWE coding benchmark. A few days later, Alibaba shipped a new version of Qwen. On July 20, Axios reported that the Trump administration was again pushing for a de facto ban on Chinese open-weight models; the instruments under discussion included Entity List designations, federal procurement restrictions, security advisories, liability rules, and pressure on US companies running Chinese models in production. Four days after that, on July 24, Jensen Huang used the first X post of his life to publish a policy letter titled “Open Weights and American AI Leadership.” The ask: Washington should not impose “premature restrictions” on downloadable AI models. The first version carried 25 corporate signatures, including NVIDIA, Microsoft, and Meta. Within a day it doubled to 50 — OpenAI and Google had signed; Amazon and Anthropic had not. By July 30, the official page hosted by Microsoft listed more than 230 signatories, and Amazon had appeared among them. The roster spans chips, servers, clouds, neoclouds, inference platforms, enterprise software, developer tools, and venture capital. Anthropic is the only frontier lab that has stayed away throughout.

Two ways inference demand can converge

The center of gravity in AI compute demand is shifting from training to inference. At a press Q&A at CES 2026, Huang offered a figure: one out of every four tokens generated today comes from an open model. There are two extreme shapes that inference demand could converge toward:

(1) Concentrated. Demand pools into a handful of closed frontier model companies. Enterprises rent intelligence, and tokens flow out of a few API endpoints.

(2) Diffused. Demand sinks down to tens of thousands of enterprises, inference platforms, neoclouds, sovereign AI programs, and application companies, each running its own specialized model.

Open weights are the condition that makes diffusion cheap and scalable. So this is a fight over market structure. And market structure determines whether NVIDIA faces five buyers or fifty thousand, and whether enterprises have any alternative to bring to the table when negotiating with closed APIs.

What NVIDIA wants is a fragmented buyer base

On the surface, NVIDIA should be neutral on model paradigms — whether closed labs dominate or an open ecosystem does, both sides buy GPUs. As long as AI workloads grow, NVIDIA makes money.

But NVIDIA cannot be neutral on the structure of its buyers. Its customer concentration is rising fast: in FY2026 Q3, four direct customers each accounted for more than 10% of total revenue, adding up to 61%; a year earlier it was three customers at 12% each, totaling 36%. We can only see concentration at the procurement layer, not the names of the end demand. But there is little disagreement in the market about who that procurement ultimately serves: Google, Amazon, Meta, Microsoft, OpenAI. And those same companies are the only ones capable of building an alternative to NVIDIA. Google has TPU, Amazon has Trainium, Meta has MTIA, Microsoft has Maia, and OpenAI is co-developing silicon with Broadcom. The weaknesses of these ASICs — narrow ecosystems, high CUDA migration costs — are not fatal for a hyperscale platform with a fixed internal workload, and those weaknesses are shrinking: both TPU and Trainium are now sold externally. Anthropic, for instance, uses Google TPU, AWS Trainium, and NVIDIA GPUs simultaneously, with the stated rationale of “matching the workload to the most suitable chip” — which is to say, large-scale frontier training can run on non-NVIDIA silicon. (NVIDIA is also one of Anthropic’s investors, so the two are not purely adversarial.) Which is why NVIDIA needs a world with a more fragmented buyer base. Tens of thousands of customers who can neither afford nor build their own chips are a far safer foundation than a few giants who are actively building substitutes. The Nemotron family, and the Nemotron alliance announced at GTC 2026 — with roughly $26 billion of company investment over five years — all indicate that NVIDIA is paying out of pocket to manufacture the fuel for a diffused world.

(That said, as NVIDIA’s own 10-K risk factors note, open-source AI depends on developer adoption, and if it is deployed on competitors’ platforms it could reduce demand for NVIDIA’s products. Open weights push demand downward, but which silicon it lands on once it gets there is not NVIDIA’s call.)

Sovereign AI: a new national-scale demand category

Sovereign AI refers to an AI capability stack that a country builds and controls itself: compute located within its borders, models under its own legal jurisdiction, and training data that includes its own languages, public data, and industrial knowledge. Three forces drive it — data localization (healthcare, financial, government, and defense data not flowing to foreign APIs), national security (critical systems cannot depend indefinitely on foreign companies’ closed models and terms of service), and language and culture (leading frontier models under-serve a great many non-English languages, dialects, and administrative and legal systems).

By NVIDIA’s own disclosure, sovereign AI revenue exceeded $30 billion for full-year FY2026, more than tripling year over year, with the main contributions coming from the UK, France, the Netherlands, Canada, and Singapore; FY2027 Q1 added new AI factory projects in Japan, South Korea, and Germany. The buyers of supercomputers used to be research institutions; the buyers of AI factories are finance ministries, defense ministries, national telecom operators, and sovereign wealth funds. Saudi money is betting on both tracks at once: domestically, PIF-owned HUMAIN is building gigawatt-scale compute and the Arabic model ALLAM, while Aramco Ventures led Together AI’s $800 million round in July, investing directly into the American open-weight inference layer. Nearly all of these countries are US allies, and nearly all of what they buy is NVIDIA. So what “sovereign AI” is actually doing at this stage is trading API dependence for chip dependence — and the chips still come from NVIDIA. For NVIDIA, sovereign AI is therefore a demand category that expands the number of buyers while posing no threat at all to its own moat.

For policymakers, a country that can only call foreign closed APIs does not have real sovereign AI; it needs models it can download, inspect, deploy, fine-tune, and maintain over the long term. Kimi, DeepSeek, Qwen, and GLM are mostly released under permissive licenses like MIT, which is exactly what sovereign programs need. If the US restricts its own open models, sovereign AI programs will naturally turn to Chinese ones.

Inference providers sell model utilization

Fireworks, Baseten, and Together are the most direct beneficiaries in this ecosystem. All three signed the letter. What they sell is the ability to turn a model into a production system: deployment, fine-tuning, adapters, distillation, autoscaling, GPU scheduling, and latency and cost optimization.

Capital markets placed their bets on this layer in a dense three-month stretch:

Company	Round	Date	Amount	Valuation
Baseten	Series F	2026-06-22	$1.5B	$11B / $13B (two tranches)
Together AI	Series C	2026-07-01	$800M	$8.3B
Fireworks	Series D	2026-07-16	$1.505B	$17.5B

What these companies really are is open-weight inference foundries. Fireworks has disclosed that more than 95% of the tokens it serves come from models specialized on customer data: fine-tunes, adapters, distillations, and models customers trained themselves and brought over to be hosted. In that last case, the inference provider takes no part in training and handles only serving — it is paid for the production system after the model goes live.

(A note: the service economics of adapters differ from traditional fine-tuning. Under the traditional logic, each customer gets its own copy of the model, and deployment costs are extremely high. Under multi-LoRA, one base model stays resident in GPU memory while hundreds of customer adapters are mounted on top of it, hot-swapped at the request level. The same fleet of GPUs serves a large number of customers’ “dedicated models,” and utilization is very high.)

On cost: Fireworks CEO Lin Qiao says that at equivalent quality, the cost is 5–10x lower than closed models; Decagon, a Together customer, says its costs after migrating fell to between one-fifth and one-seventh of the closed-model alternative.

The capability gap has also narrowed to a point where it can be negotiated with. Stanford’s 2026 AI Index puts the open–closed gap at 3.3 percentage points. When capability differs by a few points and price differs by a multiple, a large share of workloads will move to open-weight models — though the hardest ones will not.

Inference providers are not the SaaS of a new era. Ordinary SaaS can carry gross margins above 70% because marginal cost is near zero: one more user means a bit more server and bandwidth, not a linear increase in core cost. Inference providers face linear variable costs and cannot amortize fixed overhead through scale. Double the tokens served and the GPU bill roughly doubles too. Sacra estimates Fireworks’ gross margin at around 50%, against a company target of 60% — below SaaS’s 70%+, because GPU cost lands directly in COGS (cost of goods sold, i.e., the direct cost of delivering the product). Margin improvement therefore has to come from three directions: technical efficiency, moving up into customization, and moving down to lock in compute supply.

Progress on the technical efficiency side is genuinely remarkable. Per SemiAnalysis and NVIDIA, Blackwell delivers roughly 30x the tokens/sec/GPU of Hopper a year earlier on frontier inference workloads, and the cost per million tokens is falling by order-of-magnitude increments annually (EpochAI’s figure is about 10x per year). But compute prices are rising at the same time. In April 2026, spot rental for H100s had risen from about $1.70/hour last October to $2.35; the Blackwell spot index went from $2.75 to $4.08/hour in two months. Unit compute prices are rising, but throughput is rising faster, so cost per token continues to fall. This means that even as competition keeps pushing token prices down, inference providers’ gross margins need not compress — as long as costs fall faster than prices. That said, Sacra’s risk assessment of Fireworks notes that if open-source frameworks like vLLM and SGLang close the performance gap, what remains is GPU resale at 50% margins.

Circular capital, courtesy of NVIDIA

NVIDIA sells the cards and also invests in the people buying them. It is a shareholder in Fireworks, Baseten, and Together; it holds roughly 6% of CoreWeave and added a $2 billion private placement at $87.20 per share in January 2026 — and CoreWeave’s single largest expense, by order of magnitude, is buying NVIDIA GPUs. The money NVIDIA puts out comes back as demand for NVIDIA chips. So part of the demand on NVIDIA’s income statement is generated by its own capital rather than being fully exogenous market demand.

The hyperscalers’ three-layer business

Hyperscale clouds operate at three layers:

Layer one: bare GPU rental (IaaS). The customer rents an instance with eight H100s or B200s and installs the OS, drivers, inference framework, and model themselves, billed by the hour. AWS P5 and the Azure ND series sit here.

Layer two: managed model deployment (PaaS). The customer uploads or selects a model, the platform runs it and hands back an endpoint, with autoscaling, monitoring, and operations included. SageMaker and Vertex sit here.

Layer three: model-as-API (billed per token). The customer never sees a GPU and pays only for input and output tokens. Bedrock, Azure AI Foundry, the OpenAI API, the Anthropic API, and the Gemini API sit here.

Each layer up generally produces higher revenue and higher margin from the same GPU. But the clouds’ positions are complicated.

Microsoft is OpenAI’s largest partner: tied to OpenAI on one side, developing its own MAI and the open-weight Phi family on another, and simultaneously selling everyone’s models on Azure rather than betting on a single one. Google has both Gemini and Gemma; it wants to sell closed APIs and also wants Vertex to be the platform where enterprises deploy every kind of model. Amazon is the subtler case. It has no genuinely first-tier frontier model of its own, and it shut down its AGI lab on July 22. Bedrock’s marquee offering has long been Anthropic. Amazon’s cumulative actual investment in Anthropic has reached roughly $13 billion, with up to another $20 billion tied to commercial milestones, for a cap of about $33 billion; in return, Anthropic has committed to spend more than $100 billion with AWS over the next decade and gets access to up to 5GW of Trainium capacity. Widespread open weights would erode Bedrock’s Anthropic-centered differentiation — but Amazon is also an IaaS provider and an aggregator, which is why, late as it was, it signed in the end.

Fragmentation is a survival condition for neoclouds

CoreWeave, Lambda, Nebius, and Crusoe — the neoclouds — operate at layer one: buying GPU clusters at scale, typically financed with debt, then renting out compute on long-term contracts. What separates them from the big three clouds is that they have only GPUs and no full cloud product line — no databases, no decades of enterprise customer relationships, no complete set of compliance certifications. So they can only compete on the price, delivery speed, and availability of raw compute. Open weights expand the number of entities that need to run their own GPUs, which is very much to the neoclouds’ benefit.

But while fragmentation is a long-term survival condition for neoclouds, it is not the current state of affairs. CoreWeave’s FY2025 annual report shows Microsoft alone accounting for roughly 67% of revenue (62% in FY2024), with no second customer above 10%; in Q1 2026 the top two customers together came to about 65%. Its contracted backlog is heavily concentrated in OpenAI (roughly $22.4 billion in cumulative commitments) and Meta (roughly $35.2 billion). At the same time it carries tens of billions of dollars in debt and 2026 capex guidance of $31–35 billion. In that structure, a single largest customer declining to renew could leave it insolvent.

On top of that, its biggest customers are becoming its competitors. Meta, for example, is standing up a cloud business called Meta Compute to sell the surplus compute from its $115–145 billion of 2026 capex, in forms including model access through Muse Spark and raw GPU cycles. SpaceX’s Colossus site was leased in 2026 to Anthropic (roughly $45 billion through mid-2029), Google (roughly $30 billion), and Reflection ($6.3 billion). And OpenAI’s Stargate is the build-it-yourself path itself.

Neoclouds hold no model assets and have nothing to win or lose at the model layer. What they can do is find enough buyers to fill capacity they have already bought with debt — an idle GPU is pure loss. Open-weight models expand the number of long-tail buyers (enterprises, sovereign AI programs, AI application companies, vertical model companies, inference platforms, research institutions), which is the most direct route to de-concentrating their customer base.

Enterprise bargaining power

Enterprises have data concerns, but the overwhelming majority of small and mid-sized companies will not actually buy cards and run models themselves.

The reason is TCO (total cost of ownership). Self-hosting means not just buying GPUs but building and maintaining the infrastructure and employing the engineers to do it. Then there is utilization: an API is a purely variable cost — no calls, no spend — while owned GPUs are a fixed cost billed by the hour. Enterprise traffic is typically high during the day and low at night, so average utilization may be poor. A common industry rule of thumb is that self-hosting only becomes worth discussing once annual API spend reaches the seven-figure range — and that is before accounting for operational risk, hiring difficulty, and opportunity cost.

The most important value of open weights to enterprises comes down to three things:

(1) Portability. No lock-in to a single API. If a vendor changes prices, retires a model, or changes its data policy, the enterprise has a migration path.

(2) Auditability. Holding the weights yourself means the model will not be swapped out or degraded without your knowledge, and in compliance settings you can reproduce the behavior of one specific version.

(3) Negotiating leverage. Even if the enterprise ends up using a closed API anyway, having an open alternative that is good enough for most tasks puts it in a completely different negotiating position. There is no stable relationship between a closed model’s marginal inference cost and its list price; list price is set mainly by competitors, substitutes, and willingness to pay. The existence of open-weight models effectively caps what closed models can charge.

For an enterprise, if a single vendor controls the model, the pricing, the access, and the institutional knowledge the company has accumulated, then that vendor increasingly controls the company’s business.

Important Note: Although I try to keep academic/technical blog posts serious, I still cannot help inserting some completely unrelated things while writing. To avoid polluting the context, I will use the /btw command to separate them from the technical parts. Readers can skip these “by the way” sections.

Over the past few years, the main thread of progress in large models has mostly revolved around “the model itself”: parameters, data, pretraining, post-training, and reasoning. In the early days, when we talked about agents, the most common definition was also very simple: LLM + tool use. Later, this gradually became context engineering: managing the context the model sees at each inference step, so that multi-turn tool use is not drowned by history, noise, tool definitions, and intermediate results. Later still, as tasks evolved into long-horizon tasks, agent capability became a system capability composed of the model, harness, context, tools, evals, sandbox, and state management together: within a finite context, external tools, and a changing environment, the agent must keep pushing toward a goal and get closer to completion over time.

In this blog, we mainly focus on context engineering and long-running harnesses.

Context engineering grew out of prompt engineering. When an agent changes from a single-turn answering system into a multi-turn action system, the input the model sees at inference time changes too. It is no longer a relatively independent external input, namely a prompt, but a context related to the model’s continuous interaction with tools and the environment. This context may include tool definitions, file contents, web observations, historical messages, test outputs, MCP server descriptions, external documents, progress records, and so on. Context engineering decides which information should be placed in the prompt up front, which should be retrieved on demand, which should be written into external memory, and which should be handled by code or tools rather than stuffed into the model context. Anthropic systematically explained this concept in Effective context engineering for AI agents in September 2025. A concrete context engineering example is: when there are too many MCP tools and too much data, we should not let every tool definition and intermediate result flow through context. Instead, the agent should write code to call tools on demand, filter the data, and bring only high-signal results back to the model. Context engineering also includes compaction, structured note-taking, and even multi-agent patterns, but these mostly serve the question of “how should context be managed?” The long-running agent harness discussed later goes one step further: it does not only manage context, but separates planning, implementation, evaluation, revision, and final acceptance into different processes.

By the end of 2025, as coding agents became able to make longer continuous progress on software engineering tasks, the center of gravity quickly shifted toward long-running agent harnesses: from the initial focus on the model’s coding ability to the ability to continue executing a task across multiple context windows / sessions. In November, Anthropic released Effective harnesses for long-running agents, which can be viewed as the first version of the long-running harness. The system started to shift from “managing one agent’s context” to “managing multiple sessions.” This version of the harness introduced a minimal role split between an initializer agent and a coding agent. The initializer’s role is to establish an external project state that can be handed off: it breaks the task into a smaller feature list, writes a progress file, creates an init script, initializes a git repo, and marks each feature as pending. Later, each coding agent session only advances one bounded increment, such as implementing one feature or fixing one specific issue. The harness requires it to test, update records, commit, and leave the repo in a clean state before ending. That way, even if the next session starts from a new context, it can reconnect to the task through the progress file, feature list, git log, and test results.

In January 2026, Anthropic published Demystifying evals for AI agents. This article systematized agent evals: because agents act in environments, call tools, and modify state over multiple turns, evals cannot only look at the final sentence. They also have to look at the transcript / trajectory and whether the final environment state is actually correct. Roughly speaking, it makes two points. One is task-level: how do we determine that the agent really did the task and did it well, rather than producing something that looks acceptable on the surface but is actually buggy or incomplete? The other is harness-level: we also need to evaluate whether each component of the harness is actually load-bearing, rather than just adding useless stuff.

By March 2026, in Harness design for long-running application development, this idea became the second version of the harness: initializer + coding agent was expanded into planner + generator + evaluator. The evaluator uses Playwright MCP to operate the application like a user, test UI, API, and database state, and reject outputs that fail certain criteria. Whether this evaluator should exist depends on whether the task exceeds the current model’s reliable solo capability. For example, on Opus 4.5 it was clearly useful; by Opus 4.6, the model itself had become stronger, and some scaffold could be removed or weakened. These adjustments and transitions naturally make us think about a longer-term system design problem (see their April post Scaling Managed Agents): a harness is not a fixed structure, but co-evolves with model capability. Earlier Sonnet 4.5 / Opus 4.5 had context anxiety and would under-scope, so they needed more scaffold: context reset, sprint decomposition, evaluator feedback loops. But by Opus 4.6, the model itself was better at long-running agentic tasks, code review, debugging, and long-context retrieval. Some structures that were originally necessary started to become less necessary. For tasks the model can already complete reliably solo, an evaluator may no longer be worth the cost. Of course, for tasks that sit just beyond the model’s capability boundary, an evaluator can still bring real lift. Many designs in a harness essentially contain assumptions about “what the current model cannot do well.” After the model upgrades, these assumptions may no longer hold. So we should not treat one generation of harness as an architecture that can be used forever. Instead, we should split the system into relatively stable abstractions: use sessions to record what happened, use the harness to manage the agent loop and tool use, use the sandbox to provide a controlled execution environment, and so on. This way, the underlying harness can keep being replaced, but the agent product is not tied to one generation of scaffold.

Context engineering

People used to focus on prompt engineering, namely how to write the system prompt. But as agents become more multi-turn and longer-running, the focus becomes: at each inference step, what did the model see? For example, an agent’s context may contain the system prompt, developer instructions, tool definitions, MCP server descriptions, user messages, conversation history, file contents, command output, browser observations, screenshots, errors, progress notes, retrieved documents, evaluator feedback. These things cannot all be blindly stuffed in. Even if the context window becomes larger, we still need to choose selectively, because noise in a long context distracts the model and increases cost and latency. So a good context is the minimal high-signal context that lets the model complete the next step at the current step. In general, we use just-in-time context: instead of stuffing all documents, tools, and history into the model, we keep references, such as paths, URLs, commit hashes, log files, database table names, and so on. When the model needs them, it loads them through tools. In this way, the agent’s working memory keeps indexes and currently relevant fragments, rather than all of the context.

Common context techniques in long tasks include:

• Compaction: When the context is almost full, compress the current conversation trace into a summary, then use that summary to start the next context. Usually this is still the continuation of the same task and the same agent loop. Its goal is to preserve conversational continuity as much as possible. In other words, the model should feel that “what I was just doing is still here”; only the history has been compressed.

• Structured note-taking: Let the agent actively write task state into persistent external artifacts, such as progress.md, feature_list.json, NOTES.md, or git commits. It is not necessarily only for the same task. A project-level NOTES.md can be read by later sessions, by planner/generator/evaluator, or reused in neighboring tasks.

• Context reset: Use external artifacts, such as files produced by note-taking, git logs, test results, task lists, and so on, as startup material to open a clean new context/session. It does not preserve the full conversation history, and can clear noise and bad assumptions so that a new agent can reorient itself.

• Multi-agent architecture: Do role division and context isolation. Different agents receive different context, do different subtasks, and finally pass only high-density results back to the main flow.

Tool use

There are also some things to watch out for in tool use. For example, the number of tools cannot expand without limit, otherwise the model wastes attention on choosing. Tools should not overlap too much in functionality, otherwise the model does not know which one to use. Tool descriptions should clearly explain when to use them and when not to use them, namely they should make the boundaries clear. Return values should be token-efficient and should not pour irrelevant data into context. Returned error messages should let the model know what to repair next. Names should be clear, so the agent can infer boundaries from the names. Also, tools are preferably not exposed directly to the model as direct tool calls, but mapped into code APIs / a file tree, so the agent can call them through code. This way, the agent can read only the tool definitions it currently needs, filter large data inside the code execution environment, and return only summaries or a small number of results to the model. It can use loops, conditionals, and exception handling to complete complex control flow, or write intermediate state into files instead of stuffing it into context. Tool outputs are deterministic; we should leave deterministic computation to code. Judgment and planning, such as how to call tools, which tools to call, in what order, and how many times, should be left to the model.

The problem of long-running agents

1. Context window

Long tasks will definitely exceed a single context window. Even if the model supports a very long context, context is always a finite resource: every extra piece of information consumes part of the model’s attention budget. This brings three common phenomena:

• Amnesia: A new session does not know what the previous session did.

• Context rot: The longer the context, the easier it is for the model to lose the point; earlier information gets buried by noise.

• Context anxiety: When the model feels that it is approaching the end of the context, it rushes to wrap things up and calls a half-finished product complete.

2. Planning and hand-off

Many complex tasks contain dozens of mutually dependent features, bugs, design decisions, and validation steps. If the model starts directly from a high-level prompt, it easily tries to do everything at once, then runs out of context halfway through, leaving something that appears to have a lot of work in it but does not actually work. Also, even if some things are useful for the next agent, the next agent does not know which things are useful: is something that looks like a bug intentionally made that way, or is it something the previous session did not have time to clean up?

/btw

I believe many of you, in PhD work or at work, have had the experience of inheriting a collaborator’s mess. Although by the late stage of my PhD, around December 2025, agents were developing so fast that I felt a lot of anxiety and insecurity, deeply felt that I could no longer stay in academia, and had completely lost the motivation to keep publishing papers, I also became the kind of person I once disliked: someone who leaves collaborators with a pile of messes.

3. Self-evaluation

The model does not necessarily judge what it generated strictly. It may see that a button shows up and think the feature is complete; see that a page roughly looks right and think the design is good; or run part of the tests and think the whole system is usable. In Anthropic’s long-running application harness post, they mention that letting the same agent be both generator and reviewer often leads to overly lenient judgments. Especially for front-end design, product completeness, and edge interactions, where there is no unit test directly defining the thing, the model can easily convince itself.

/btw

After all, the world is a giant makeshift operation, and models have learned a lot from us. Also, a lot of the time, people only need to convince themselves.

Harness

An agent harness, also called a scaffold, is the system that allows a model to act as an agent. It handles inputs, organizes tool calls, manages state, executes loops, and returns results to the model. It includes the file system, task board, test scripts, browser, shell, git, logs, sandbox, permission system, checkpoints, handoff notes, and so on.

The core design of the first generation of long-running harnesses was quite simple. It mainly used two types of agents:

• Initializer agent: Runs at the very beginning to set up the working framework and environment.

• Coding agent: Makes incremental progress session by session, and leaves structured handoff artifacts before ending.

The initializer agent does several things.

1. Create a task list.

For example, if the user only says “build a claude.ai clone,” the initializer does not let later agents directly start building. Instead, it breaks the task into many verifiable features, such as creating a new chat, entering a message, pressing Enter to send, receiving a response, switching themes, loading historical conversations, and so on. Each feature’s initial status is marked failing.

2. Create a progress file.

For example, claude-progress.txt or a similar file records what each round did, what remains, and what later agents should pay attention to.

3. Create a startup script.

For example, init.sh tells later agents how to install dependencies, start the service, and run basic checks.

4. Initialize a git repo.

At the end of each round, commit. This way, later agents can understand recent changes through git log, and the system can roll back, diff, and audit.

Later coding agents roughly do three parts:

1. Understand the current engineering state they are receiving (orient): confirm the current working directory, read the progress file and feature list, look at the recent git log, and run an end-to-end test to confirm that the basic functionality is not broken.

2. Select and finish one feature (select & implement & validate): choose the highest-priority unfinished feature, implement one relatively independent increment, test it, and evaluate that feature.

3. Hand off a clean state to the next round, so that the current code can be understood by the next agent: for example, update the feature status and progress file and commit. If a new feature is not finished, leave a clear boundary instead of pretending it is done.

A long-running agent is essentially using multiple short sessions to stitch together one long task. If every session leaves behind a small mess, errors compound with interest. So a harness should not only reward “verifiable increments,” but also reward the state of the system it leaves behind. If a session writes three more features but breaks the startup flow, the next round may have to spend a large number of tokens first recovering the environment. In the long run, this kind of progress is actually negative return.

The three roles of planner / generator / evaluator

The first-generation harness solved the context handoff problem, but there was still one big problem: agents are not good at judging themselves. So Anthropic introduced a multi-agent structure in the second generation. The final form roughly contains three roles:

• Planner: Expands the user’s high-level prompt into a specification, feature list, design direction, and implementation plan.

• Generator: Implements features according to the plan: writes code, changes UI, connects the backend, and runs tests.

• Evaluator: Acts like QA, operates the application, checks the result, points out problems, and decides whether it passes.

Different roles correspond to different failure modes.

Planner solves under-scoping. Without a planner, the generator often understands the task too narrowly. For example, for “build a 2D retro game maker,” a single agent might build a page where you can place some tiles and think it is done. The planner expands it into more complete product specifications such as a level editor, sprite editor, entity behavior, playable test mode, animations, export, sound effects, AI-assisted generation, and so on.

Generator solves execution. It is still the main labor force, but it no longer decides the entire product boundary from nothing; it works inside a clear spec and current feature contract. Generator also does not have to be a single agent. It is more like a role: multiple generator sessions or coding agents sequentially hand off execution. Each round of generator reads the planner spec, current code, progress file, and previous evaluator feedback, then completes a bounded increment, writes state back, and exits. The next generator then reads these artifacts and continues. So the continuity of a long-running harness is placed in external project state, such as progress files, feature lists, git commits, and test results.

Evaluator solves self-evaluation. It is not just reading code and then giving a score or feedback; it operates the application through Playwright or browser automation like a user, checking UI functionality, APIs, database state, and edge cases. So this moves from previous LLM-as-a-judge to agent-as-a-judge.

At the beginning of each sprint, the generator and evaluator first negotiate “what counts as done for this piece,” rather than having the generator finish first and then ask the evaluator to criticize it. Before writing code, both sides communicate and reach consensus. This “negotiation” happens by exchanging structured artifacts through files and the workspace: the generator writes a sprint contract proposal, explaining what this round will do, what the acceptance criteria are, and what is out of scope; the evaluator reads the planner spec and proposal, fills in missing boundary conditions or rejects an overly broad scope; the generator then revises the contract. What they share is the spec, contract, progress, code, test results, and feedback.

In this negotiation process, vague user stories become testable contracts. It is a bit like product requirement clarification + QA test plan in a human team.

However, giving evaluation to another LLM does not automatically solve the problem. Claude was not a good QA agent at first either. It would find real problems, then convince itself that they were not serious; or it would only do shallow tests and not touch edge paths. So the evaluator itself also needs to be tuned. It needs a clear rubric, failure cases, judgment criteria, interaction paths it must explore, and bug types it must not let go too easily. Ideally, we should read its logs, find where it disagrees with human judgment, and update and iterate on the evaluator prompt.

Anthropic’s frontend harness used several scoring dimensions:

• Design quality: Whether the whole thing has a clear character, rather than being a pile of components. Aesthetic quality.

• Originality: Whether there are custom design decisions, avoiding templates, default libraries, and an “AI feel.” Originality.

• Craft: Typography, spacing, color, contrast, and so on. Usability at the craft level.

• Functionality: Understanding and completing the task. The more important functionality side of usability.

So when using a judge, we cannot ask abstractly whether this is “good.” We need to break “good” into multiple checkable dimensions. Similarly, in the application development harness, the evaluator scores dimensions such as product depth, functionality, visual design, and code quality, and every dimension has a hard threshold. As long as one key dimension is below the hard threshold, this sprint fails, and the generator must continue revising based on concrete feedback.

When evaluating, what we evaluate should not be “the agent says it is done,” but the final environment state and outcome. A flight-booking agent saying “I booked it for you” is meaningless; what matters is whether there is actually a reservation in the database. A coding agent saying “bug fixed” is meaningless; what matters is whether the tests pass (outcome), and whether it damaged the original code (state).

/btw

Many life lessons can apply here. For example, when evaluating a person, what the other person did matters more than what they said. Because of my unique “therapist trait,” I often end up talking about related topics when discussing relationship problems with the girls around me. Processing and analyzing other people’s dilemmas is much easier than walking out of my own life difficulties. On one side I am being other people’s therapist; on the other side I need to find a therapist myself, but it is hard to find one I trust. After I started trying to write blogs, I actually felt much calmer. Maybe I am my own best therapist. Writing lets me quiet down and talk to myself. Before, I gave all my time to other people and almost did not allocate any time to myself. Also, although I have been anxious about finding a job, and about being replaced by LLMs as a researcher in the near future, I still think I am better at therapy than the most state-of-the-art LLMs. Unfortunately, this trait cannot make me a living and was never on my career-planning path. I have wandered too far.

Some points worth noting: the planner usually mainly solves initial under-scoping. For example, a user’s one-sentence prompt is often too broad, such as “build a 2D retro game maker,” and the planner can make it concrete: what core modules should this product have, which are must-haves, which can be done later, and how each feature should be accepted. After the project moves forward, the evaluator takes on part of the local planner role and does feedback-driven replanning. The evaluator modifies artifacts left by the planner. For example, the planner initially wrote sprite editor, only requiring draw and save. After real testing, the evaluator may add new acceptance criteria: brush size must work, transparent pixels must be preserved, saved sprites must appear in the entity palette, and state must not be lost after reloading the project. The planner can implement replanning by modifying external files such as feature_list, sprint_contract, known_issues, and next_actions.

So a multi-agent harness puts planning, execution, evaluation, and revision into external artifacts, so each round of agent can take over with limited context.

More durable design

Every component of a harness implicitly contains assumptions: assumptions about what the model cannot do well by itself. As models become stronger, these assumptions may no longer be valid. For example, if a model has context anxiety, the harness adds context reset. Later, if the model no longer has this problem, reset may turn from a necessary structure into latency and cost. If a model cannot plan, we add a planner. Later, if the model’s planning ability improves, the planner may only be valuable on large tasks. If the generator can already reliably complete a task by itself, the evaluator may become unnecessary overhead; but on tasks that sit just beyond the model’s capability boundary, the evaluator can again bring a large lift. So a harness is not better just because it is more complex. We should start from the simplest workable system, use evals to identify failure modes, then add corresponding structure for these real failure modes, and as models upgrade, periodically remove components that are no longer load-bearing, rather than building an overcomplicated agent framework from the beginning.

An agent system can be split into several relatively stable abstractions:

• Session: an append-only log of what happened.

• Harness: the control layer that calls the model, routes tools, and executes the agent loop.

• Sandbox: the environment where the agent can run code and modify files.

After decoupling them, the underlying implementation can keep changing while the external interface stays stable. Because the harness of long-running agents will keep evolving, stable abstractions let agent products avoid being tied to one generation of harness.

Agent Eval

Agent behavior is nondeterministic. Running the same prompt twice may succeed once and fail once. A task passing once does not mean the system is reliable; a task failing once may also mean the grader was wrong, the environment had a problem, or the task itself was ambiguous. Compared with ordinary LLM evals, for agent evals we should not only look at output text, but at the result that a sequence of actions causes in the environment. So we need sandbox, database, browser, file system, mock API, resettable environment, and so on. Different tasks may care about different metrics. For a coding agent, if we allow the agent to try multiple times, pass@k (the probability that at least one of k attempts succeeds) is a relatively suitable metric, because as long as one patch is correct, it can enter review. But for customer service, reimbursement, flight booking, and other agents used directly by users, pass^k (the probability that all k attempts succeed) is more important, because users expect reliability every time, not “one of ten attempts is right.”

There is also the difference between capability eval and regression eval. Capability evals contain some tasks the current system does not do well. Regression evals evaluate “can it still do what it used to know how to do?” This should be close to 100% pass, and is used to prevent regressions after system upgrades, model switches, or prompt changes.

Agentic Safety (the importance of a good RL environment)

In the non-agentic era, because the model could only answer text, the blast radius of mistakes was small. But now agents can run shell, modify files, access databases, call SaaS APIs, send Slack messages, and open PRs. The cost of mistakes can be much larger. For safety, we cannot rely only on “the model will judge whether a command is dangerous” to protect the system. The safer approach is to restrict what the agent can access, where it can write, what networks it can reach, which tools require approval, which state can persist, and which secrets are never visible. But this requires a good RL environment. Of course, once we mention RL environment, we have to mention reward hacking: we should not put shortcuts we do not want the agent to use into its environment. For example, in a coding eval, future commits should not be placed in .git/objects, hidden tests should not be placed inside the container, and secrets that can access production systems, such as API keys, OAuth tokens, cloud provider keys, and SSH keys, should not be directly exposed to the agent. We can instead use controlled tool capabilities, and implement permission checks, parameter constraints, and auditing inside the tool.

(Translated from the Chinese version by ChatGPT.)

The dust of the times, when it settles on any single person, becomes a mountain. Over the course of a life, one will most likely live through many great, era-defining changes. My own social circle is small, and I hardly know anyone from other generations, so I can’t say whether, somewhere in their lives, there was a historical stretch that could rival the hurricane AI has stirred up over these past two or three years. Every generation, meeting the great upheaval of its own time, probably laments the misfortune of being the generation it is. And yet, seen along the timeline of modern human history, even if a single life is only a tiny segment of that long river, it seems no generation ever passed through a plain, uneventful life without living through some great historical upheaval.

Times of great upheaval: the shifting of thought, the reshaping of values, always come with pain. We were raised inside a system that reveres knowledge (the law-abiding, by-the-book traditional Chinese education system), taught from the very beginning to study hard, to become knowledge workers, to have “a respectable job” and a stable life. And so, along a path already laid out and validated by many, our life choices were shaped for us: go to college, earn a master’s, earn a PhD, then become a professor or a research scientist — the stable, relatively well-paid job. It was the predictability of this path that gave us our sense of safety. And then one day, the path collapsed. Because it was so stable: we had been walking it from the moment we were born, we had long taken its existence for granted, and had never once imagined what our Plan B would be if it ever gave way. To survive, to feel safe, people keep a Plan B for all sorts of things; but in this one thing, for most of us, our past trajectory was never enough to instill any sense of crisis, until, at a certain point, it did.

Value has always been the product of a particular historical moment, not a constant law of how the world runs. But life is short; our experience lets us witness only a single stretch of history, and then we take that stretch to be the world’s constant law. This makes sense, too: across a short enough span between two points, even a curve can be approximated as a straight line — how much more so across the whole long river of time.

In the age of agriculture, safety came from land; in the industrial age, from physical strength; in the modern world before AI, from knowledge. For many of us, our sense of self-worth is built on “difficulty.” Things are prized for their scarcity: the harder something is, the fewer the people who can do it, and the more it grants us the safety of being “not easily replaced.” AI has made knowledge suddenly cheap, and “knowledge changes your destiny”, once engraved in our minds, is no longer a truth.

Over these past few months, I’ve spent a great deal of time studying and cultivating myself, stealing a few moments of calm from an anxious age. I’ve kept up with much of the latest technical progress in my field. I’ve convinced myself that the joy learning brings me comes from my appreciation of beauty: the beauty of algorithms, of mathematics, of scheduling and optimization, of logic. And the other things, the ones not technical or logical enough, strike me as not beautiful enough. Until now, the skills that earned my living, the things I spent my time on, and the things that made me happy were all aligned; I didn’t have to think, to weigh trade-offs, to analyze. Now a rift has opened. What others value, the thing that keeps me in a decent living, and what actually makes me happy are no longer aligned, and I have to decide where my time should go, how to balance spiritual needs against material ones, or else change my own perceptions and the way I see certain things, so that all of it can be made consistent again.

Uprooting something deeply rooted always hurts. I keep tracing back to find where my reverence for technical skill comes from. If I can find its source, and alter it, and through that alter the way I understand things, then perhaps I can complete this remaking of my mind more quickly and more easily.

(Translated from the Chinese version by ChatGPT.)

Although I have not officially graduated yet, my internship at Meta should be the last internship I ever need to do that involves research. I have also cleaned up all the things I worked on before into preprints or blog posts. It feels as though I have cleared out all my old clutter, and my heart has become unbelievably light. Every time I clean my room and let go of a pile of things, I feel this same kind of relief.

It has been more than seven years since I first came into contact with research. Research certainly brought me many things: it let me break out of the circle I originally lived in. Even if the junior-year version of me had exhausted every bit of her imagination, she could never have imagined that I would make it here.

But everything has two sides. The negative effect research had on me was that I began to feel very tired. Gradually, I could no longer feel the joy of learning new knowledge. Many people can handle multi-objective optimization: they do research while learning new things, and optimize both very well. But I find it difficult to balance both at the same time. Research is about solving a problem, but very often, under time constraints, it is possible to solve a problem without learning anything. The two are not always consistent. This happens if I set the wrong reward for myself. For example, suppose that, during an exam, my optimization objective is the final score, and I clearly cannot finish the entire test. When I get to the true-or-false section, randomly guessing an answer might be more cost-efficient than completely understanding each question and working out the correct answer bit by bit. I can use that time on other questions and end up with a higher overall score.

For me, research is exactly this kind of exam. And just like a test that cannot be finished, in research I do not know what standard I am supposed to reach. I can always write more papers and do more projects. So I can only use the people around me as my baseline and hope that I am roughly on par with them. Perhaps part of the exhaustion of doing research comes from this. Under the previous system of evaluation by grades, because the maximum total score was only 100, even if my peers were very strong, the most they could do was score 100; there was no higher score. I could set my own standard at 90, so there was no peer pressure. I might not be the best person in an environment, but I would not be eliminated by that environment either. A person’s first instinct is survival, and after that comes dignity. I do not want to be the very best person in an environment; it is lonely at the top. If scoring 60 is enough to satisfy the need for survival, scoring 90 is enough to satisfy the need for dignity, and the very best people score 100, then I feel that scoring 90 is enough for me. This was roughly how exams used to feel. And because I genuinely enjoyed the process of learning, I could occasionally score even higher, which formed a positive feedback loop.

Research, however, is very different. The greatest difference is that research has no verifiable reward, and there is no upper bound on the total score. I do not know the minimum score I need in order to satisfy both my need for survival and my need for dignity. I do not even know what score range I am currently in. Am I on the verge of being eliminated? Or am I at the critical point between survival and dignity? The fear brought by this uncertainty means that I do not know when I am allowed to stop. This time, I am still doing constrained optimization: both the objective and the constraints are clear, but I do not know when to break the loop: if eps < 1e-7: break. In this problem, I do not know how to measure eps.

This week I spent some time learning things, and finally felt again the “joy of learning” and the peace that I used to feel before I encountered research. For so many years, it has been such a long, long time since I had this sense of peace. During undergrad, at the end of each semester, I would temporarily throw research aside completely for two weeks in order to review for exams. In those short final-exam weeks, I would feel this kind of peace too.

Over the past month or two, I have begun to change my mindset completely and gradually shift my focus onto learning rather than doing research. But at the time, I still had a few unfinished projects, so I did not yet have the lightness that comes from having thrown away all the things and burdens I was carrying. Before, I knew almost nothing about coding or many fundamental technical concepts. This was entirely because my base model was not very good to begin with, and on top of that I did not handle reward and optimization very well, so I completely trained myself into collapse, lol. The other people I observe around me can do research, coding, technical skills, and engineering all very well. This month or two of review has brought a great improvement in my technical and coding skills. At last I no longer feel insecure about them. With competence, I have become much more confident too. These things were never difficult in the first place, but before, because I did not know when research would ever end, I had no way to rationally balance out time for learning them.

I had never before considered that my anxiety and unhappiness might have been brought by research. It is like how, when people are suffering in a toxic intimate relationship, it may be hard for them to realize that the relationship is causing their pain. Only one day, after going back and forth many times, do they finally make up their mind to end the relationship; only after truly leaving it can they discover that the relationship may have been the source of their pain. Actually, this reminds me of many experiences of being PUAed during undergrad. Although several years later I would ask why my younger self could have been PUAed, I also know that without those experiences, I could never have understood that the people who PUAed me were wrong, or grown into the person I am now, completely unruffled by PUA. In the same way, although doing research really did make me unhappy, without these seven years of research experience, I would not be who I am now. Perhaps by now I would already be a civil servant in China, or a primary, middle, or high school teacher, urged by my parents to get married, trapped in the trivialities of daily life, and turned into exactly the kind of person I least want to become.

Update: May 25, 2026

After discussing with a friend the impact that AI coding has had on him, I suddenly realized that I did not dislike research from the beginning. Although research brought me a great deal of uncertainty and anxiety, sometimes I was also able to find peace in the process of doing it, such as when I was working on theory before. But just as AI coding has affected software engineers, once most of what goes into research is no longer my contribution, but the agent’s contribution, I can no longer find any joy in research. This feeling only started in 2025.

(Translated from the Chinese version by ChatGPT.)

Today is May 20th. Meta had layoffs. The company was almost empty, dead silent (I later found out it was because today people could work from home, not because everyone had been laid off). In the morning, because I had to prepare for an interview, a lot of thoughts I had never made it onto the page, and by evening, the various threads in my head had already drifted away.

Over the past few weeks, I have often gone to the 8th floor in Sunnyvale. Every morning, when I arrive at the office around 7 or 8, I see this guy sitting in a corner seat. He always arrives very early and starts working. Today he was there too, just as early as ever. In fact, today, there were only a few people on the entire floor, so that guy who arrived before 8 stood out even more than usual.

A lot of people in the WeChat groups received news in the morning that they had been laid off. They said goodbye to others and then quietly left the group. Some others were reassigned to AAI — I even went and looked up what AAI was. Over the past week, I had been drowning in my own pain and forgot that everyone else has their own pain too. Pain, when it sits on you, tends to get magnified.

After hope was broken again and again, I actually started to be kinder to myself. I used to comfort myself by thinking: once I find a job, everything will be okay. My life will become stable and peaceful, I will have time to learn new things, do what I want to do, and pay attention to my health. So I placed every joy-worthy thing into the bucket of “after I find a job.” I allowed myself to stay in a long-term state of unhappiness, because “it’ll be fine once I find a job.”

But is life really like that? Before my PhD, I also thought everything would be fine once I got admitted. And then? In the six months after I got my PhD admission, I was happy — maybe the happiest stretch of my life. I did not have to worry about the future or the present. But six months later (in the month before the PhD actually started), I became extremely negative, because I knew that happy life was about to end. And sure enough, in the three years that followed, there are almost no happy moments I can clearly recall. Before getting into the PhD, even though I did not have a long uninterrupted stretch of happiness like Feb–Aug of 2023, I could still pick up bits and pieces of happiness from ordinary days. Three years later, after finishing the PhD, I have even lost the ability to find happiness in ordinary days. (Compared to three years ago, my life has objectively gotten better — so why can I no longer feel happy?) The pain I went through during the PhD has permanently changed the way my neural signals travel. (People often use “permanent head damage” as a joke, but for me it is not a joke. I really do feel that certain parts of my brain have been fundamentally altered.) I once watched the movie If Voice Could Remember (the plot itself I really do not recommend), but apart from the plot, as someone who has been depressed almost every winter since coming to the U.S., I could really relate.

(Note: pain and depression are not the same thing. For example, I can be in pain because of many things, but I still know I am not in a state of depression. Pain and happiness/hope can coexist, but depression and happiness/hope cannot coexist at all. Before the PhD, there was also a lot of pain, but it was mixed with a lot of happiness. Now there is more pain or stillness, but no happiness. As long as I am not in a depressive state, I can still see hope. When depressed, it is like falling into an abyss — you do not know when you will come out, it is dark, and you cannot see hope.)

I have drifted off topic. Back to May 20th. I do not know what will happen with AI in the future. In the past, my worry about AI was simply that all the impressive people had moved into this direction, and I do not really like crowded fields. For example, I could have made my career into a hobby, but because there are so many people, I had to follow the wave and compete with everyone else, and the things I used to enjoy stopped being enjoyable. (Two years ago I did not want to work on what was hot at the time, for the same reason. I am too free-spirited, and being pushed by others is exhausting. But later, when there was no other choice, I fully switched to application, and now I have gotten used to it.)

Now, even though I have run into a lot of setbacks in the job search and still have not found a job, I still do not think this is AI’s fault. It is purely because I am not willing to put in the same number of working hours as others in the same field. (Somehow, what I like to do and what I am actually doing are still aligned.) But what about everyone else? People who love CS but do not particularly love AI — they have been forced by this wave to give up what they love and force themselves to adapt.

I have thought about this: life should work like this. First there are basic survival needs. On top of survival needs, we can then talk about higher-level spiritual needs. Before, many people had already met their survival needs, and they were even lucky enough to find something they enjoyed doing — writing code — so their work also satisfied their spiritual needs. Now, because of AI, more and more people are being pushed back down to just meeting basic survival needs, with no room left for spiritual ones. When the cost-effectiveness of a human is lower than that of an AI, in a place that only values efficiency and output, the human gets ruthlessly replaced. But will this behavior really not backfire on those few who hold the power and the wealth? If the bottom of the pyramid disappears, can the top of the pyramid still exist? Or is it that everyone is running toward the top, until the entire pyramid disappears? The fact that we are running toward death from the moment we are born is already a sad enough thing. If, on this journey toward death, we do not even have time to admire the scenery, and everything we do is just to satisfy “survival” — is that really reasonable?

(Translated from the Chinese version by ChatGPT.)

Let’s continue talking about the issue of reward that we discussed in the previous post.

My emotions are easily affected by small things. In the past, I was very easily controlled by my emotions. After several years in college, after seeing a lot of data, I gradually became less naive and less immature. I started to see the two sides of almost everything, and I became more rational in how I think about problems. But many times, there is a huge gap between thinking and acting. Knowing how to think does not mean that the rational side of my brain can completely conquer the emotional side, or that I can always act in the way I know I should act.

In fact, in the past, these two parts of me felt almost completely disconnected. Most of the time, I was lost in abstract thinking, but rarely translated it into action. During undergrad, I tried many times, but I could never really move from theory to application. I felt that the gap between theory and practice was huge, and I did not know how to close it. For example, when doing theory, I could write a rigorous proof with no holes, and that kind of “perfection” made me happy. But when doing application, I could already find countless flaws during the planning stage — that is, during the “thinking” stage — to the point where I completely lost the motivation to take action.

Over the past few years, I have intentionally trained myself to become more accepting of imperfection. I can still think comprehensively and see all sides of a problem, but I am no longer as picky or perfectionistic as before. I no longer expect theory and application to match perfectly. In this way, for the theoretical part, I can still see everything, but I will not become paralyzed just because I have seen too much. I used to be an extreme idealist. Now I am in a more balanced state.

When it comes to job searching, putting aside the technical rounds, the rest is almost entirely outside of my control. Much of it is about “vibe.” If someone wants to hire me, they may still hire me even if my presentation is bad, even if I did not do any special preparation. If someone does not want to hire me, then even if I prepare a lot and rehearse many times, I may still receive a rejection for reasons that are never made clear. What remains is endless self-consuming rumination: Was one of my answers wrong? Was my presentation not clear enough?

This kind of vibe should be mutual. But in an employment relationship, when I really want to find a job, the relationship between me and the other side is no longer equal. I often forget my own feelings and start hoping that even places that did not feel quite right will still give me an offer.

In relationships with people, I think I also went through a similar stage. For many, many years, I had almost no friends, so I wished I could become friends with the people around me, even with some people who did not feel quite right. At that time, I was not on equal footing with them. In order to please others, I kept changing myself, trying to fit in. But I later realized that if I had entered the wrong group, no matter how much I reshaped myself, I would never truly belong. After coming to the U.S. and making some friends, I finally started to pay attention to my own feelings, instead of hoping that everyone would simply not dislike me. I later learned that in the right “group,” I do not need to change myself.

In my previous work experiences, I was in an unequal position most of the time — for example, when looking for internships. As long as someone wanted me, I was happy. Even when something felt a little “off,” I still went, because I did not have many better options. And in the end, the experience often turned out to be not very good.

During my first year of PhD, I consciously trained myself to be rational instead of making decisions purely based on feelings. Now, I have learned to accept the emotional side of myself more peacefully. In the past, I made decisions as if I were solving a math problem, trying to organize my entire chain of thought into something perfectly coherent. At that time, my decision-making model prototype was also very primitive: either accept everything, reject everything, or use some rule-based method to make decisions. Later, I realized that whether I set the threshold to 1 or 0, my classification model was still bad. Eventually, I started relying more directly on feelings — making friends based on vibe. Now, I rarely feel troubled by interpersonal relationships anymore.

After writing all of this, my emotions have mostly calmed down. Perhaps I can face the upcoming interviews and results with a more peaceful mindset.

If I get rejected, then maybe fate is telling me: this is just not the right place. Just like relationships between people, forcing something that is not meant to be will only lead to bad consequences.

Fate, coincidence, probability — does God play dice?

(Purely human written, then translated by ChatGPT.)

I have always had some difficulties with communication and expression. There are many things in my mind that I cannot quite put into words, which is why I have always resisted writing. Whenever I write, the result often feels messy, scattered, and lacking in logic. But perhaps this is not entirely my fault. Human language itself was designed for the majority, and not everyone is neurotypical. Even if my writing is chaotic, even if many things remain inexpressible, some words will eventually click with some people.

Late at night, half asleep and half awake, I suddenly realized how to solve a problem I had failed during an interview the day before. I had not had this kind of Eureka moment for a long time. When I was an undergraduate, this used to happen often: after an exam, at some completely unexpected moment, I would suddenly understand how to solve a problem I had missed, and I would feel an immense sense of joy. But later, as I entered research and began my PhD, the objectives and rewards became increasingly vague. Little by little, the joy that learning once brought me disappeared. For the past four or five years, I have hardly had the time to sit down and learn quietly. I also forgot how to design rewards and do optimization for myself.

Compared with research, exams in school had a much clearer and more immediate reward structure. In order for most students to achieve reasonably good grades, the evaluation set was often not too different from the training set. I did not even need RL. Simple SFT on ground-truth answers was already enough for me to get a good score.

Research, however, is much trickier. First, I do not know what the reward function is. I can only design a proxy reward using heuristics, optimize it, and then gradually adjust the reward function itself. This creates two problems. The first is reward hacking: I may achieve good-looking metrics, while the actual performance in the real world remains poor. Yet I cannot simply avoid optimizing the reward. Optimization is almost an instinct of human beings. Every problem can be turned into an optimization problem; the only differences are the objective and the constraints. The second problem is that the true reward I receive is extremely noisy, so I do not know whether the reward function I defined is actually a good one.

Recently, while preparing for interviews, I developed some new intuitions about the training pipeline of LLMs. Since I had not taken exams for years, I had forgotten many of the fundamentals, or only retained a vague impression of them. So when I tried to solve problems directly and realized that I could not do them at all, I felt extremely frustrated. Even after spending a lot of time, I still could not solve them. This felt like doing RLVR directly on a very weak base model.

At that point, SFT became necessary. I needed to first look at the correct answers, review the relevant knowledge, and memorize or imitate the right solutions. However, merely looking at the correct answers was not enough to help me achieve a high score. In particular, because my time was limited, my number of SFT steps was also limited. I did not even overfit; I could not even memorize the correct answers.

Then came RL: putting the answers away and trying to write code and solve the problems by myself. Only then did I discover many problems that never appeared when I was simply “copying from the answer.” This is very similar to LLM training. With SFT alone, we only learn how to predict the next token given the correct previous tokens. But if we need to solve the problem from scratch, there are far too many possible trajectories, and far too many places where things can go wrong. During inference, when there is no correct answer to refer to at every step, even a small mistake somewhere in the middle can cause the final result to be wrong. But with RL, we are forced to explore different paths. Sometimes we make new discoveries, and through this process, we gradually learn to generalize.

These reflections have given me more passion for the work I am currently doing. To be honest, I have never felt a strong attachment to computer science as a discipline. Compared with discrete things, I have always preferred continuous ones. Although I am pursuing a PhD in CS, what I actually chose was ML and AI. Compared with computers, I am more interested in studying things related to human beings, such as psychology and philosophy. These are things I can “experiment” with directly in life. Although I have never studied them systematically, life itself is the best classroom.

The emergence of LLMs has completely mitigated the gap between “what I want to do” and “what I am doing.” As a person, I feel that one eternal mission is to figure out your own life. Curiosity about life is such a beautiful thing. No matter what I do, I hope it is centered around human beings. When I find traces of life in my work, I feel that I am not merely working; I am exploring life itself.

Many things are abstractions of life. Gradient descent, constrained optimization, and RL all reflect life in their own ways. These ideas attract me with a unique kind of beauty.