At 10:17 on a Tuesday morning, an engineer opens an issue that looks almost insultingly small: a settings page saves a value, reloads, and displays the old value. The first guess is a stale cache. The second is a form library. The actual cause turns out to be an old API client, generated from a schema that no longer names the field.

That little sequence is useful because every step has consequences. A file changed. A request returned a payload. A browser showed a state. A test passed for the wrong reason. The engineer can revise a hypothesis instead of merely producing a more convincing explanation. This is the quality that makes software such a compelling environment for AI systems.

It is tempting to call a repository a "world model" for agents. The phrase reaches for something real, but it can also overstate the case. A production system is not contained in its source tree. It includes people with partial information, customers who use features in unexpected ways, legal and commercial constraints, incident response, and choices that have never been written down. A test suite cannot represent all of that.

Still, software provides an unusually good place to study action, feedback, and recovery. A dependency either resolves or it does not. A service starts, returns an error, or exceeds a latency budget. A screenshot exposes a broken layout. A migration applies, fails, or leaves a database in a state that needs careful repair. Those are not simulations of consequence. They are consequences, bounded enough to inspect.

The distinction matters. Generating plausible code is a language problem. Improving a living system is an epistemic problem. It requires an agent to make a claim about the current state, take a limited action, observe what happened, and update its next move. Good infrastructure should make that loop possible without hiding the evidence from the people responsible for the system.

A repository is not a miniature universe

The useful claim is narrower than "software is the world." A repository is a constrained environment in which state is partly explicit and actions can be checked. That makes it valuable for training, evaluation, and product design.

Some of the state is visible:

• the code and configuration on a branch;
• the package versions, generated artifacts, and environment variables used by a process;
• the commands that were run and their exit conditions;
• test output, logs, previews, and request traces;
• a diff that records what changed between two points in time.

Some of the state remains outside the repository:

• why a request matters to a customer;
• whether a surprising behavior is acceptable product behavior or an unnoticed bug;
• which maintenance cost a team is willing to accept;
• whether a temporary workaround is appropriate during an incident.

An agent should not pretend the second category has disappeared merely because it can read the first. The purpose of a work environment is to make the known facts legible and to surface the unknown facts early enough for a person to decide.

This is why an agent that confidently edits code after a quick scan is less interesting than one that can say: the change appears local, these two tests cover the primary path, the preview confirms the visible behavior, and the caching assumption has not been checked against production traffic. The second agent has done more than produce a diff. It has separated evidence from inference.

The loop that teaches something

Consider a routine maintenance task: remove a deprecated configuration option from a web service.

An effective workflow is not "search, edit, run tests, announce success." It begins by locating the option in the public schema, runtime configuration, deployment scripts, and documentation. It makes a hypothesis about which references are authoritative and which are historical. It edits the smallest safe surface. It runs the checks that can falsify that hypothesis. If a snapshot fails, it determines whether the snapshot revealed a real contract or an obsolete expectation.

The important object is not the chat transcript. It is the changing state of the work:

1. Intent. What is being removed, and what must remain compatible?
2. Initial evidence. Which files, tests, service paths, and deploy configurations appear relevant?
3. Action. What was changed, in what environment, and with what authority?
4. Observation. Which checks ran, what they showed, and which result was ambiguous?
5. Decision. Why is the task ready for review, or why should it stop?

That record can be compact. It does not need to capture every token of private reasoning or every harmless shell command. It does need to preserve the facts that change the next decision. If the task is paused, another engineer should be able to see that the schema was updated, a staging deployment still references the old key, and the integration test was intentionally not run because it requires a missing credential. That is enough to continue responsibly.

Static examples teach syntax; changing systems teach judgment

Code corpora are rich training material, but they mostly expose artifacts after a decision has been made. A repository at rest can teach an agent what a migration looks like. It cannot, by itself, teach why the team rejected the first migration, which production constraint changed the plan, or how a flaky test was distinguished from a legitimate regression.

Execution adds the missing feedback. A command that fails tells the system something about its model of the environment. A browser preview may contradict a unit test. A reviewer may identify a requirement that was never encoded in an issue. These are the moments in which an agent needs to revise its plan rather than continue emitting the pattern that looked likely in text.

This does not mean that every runtime event should become training signal. Build logs are noisy. Tests can be incomplete. A green pipeline can be produced by an assertion that never exercised the relevant path. Treating all output as equal evidence encourages a different kind of overconfidence.

The infrastructure should therefore connect specific claims to the artifacts that support them. "The empty state renders correctly" is supported by a visual check and perhaps an interaction test. "The API remains backward compatible" is supported by a contract test, a schema diff, and a reasoned account of the compatibility window. "The data change is reversible" is supported by a migration plan and a tested rollback path, not by a general statement that migrations are safe.

The closer a system gets to this discipline, the more useful its execution traces become for evaluation and learning.

Evaluation should include the path, not only the patch

Many software benchmarks score the final state: did the test suite pass, did the agent produce the expected diff, did it close the issue? Those measurements are useful, but incomplete. Two agents can arrive at the same patch by very different routes. One may inspect the affected interface, run a targeted test, notice a dependency constraint, and leave a concise record. Another may make a broad edit, retry until a test turns green, and accidentally remove an edge case the benchmark does not cover.

The difference matters in a shared codebase.

For practical evaluation, we care about questions such as:

• Did the agent identify the files and contracts that actually governed the behavior?
• Did it make reversible, scoped changes before escalating to broader ones?
• Did it use the available environment to test a meaningful hypothesis?
• Did it distinguish a successful command from evidence that the task was complete?
• When it encountered uncertainty, did it preserve the question for review or bury it in a polished summary?
• Can another person recover the current state without replaying a long conversation?

These are not stylistic preferences. They describe whether an agent is safe to place in a real engineering loop.

Recovery is part of the learning signal

The most revealing moments are often failed attempts. An agent changes a configuration file, the service refuses to boot, and the original error message points to a different subsystem. A first draft of a migration passes in isolation but fails when run against a realistic data volume. A frontend fix looks correct until a narrow viewport reveals the layout assumption underneath it.

The right response is not to suppress the false start. It is to make the correction legible. What was tried? What observation invalidated it? What condition now protects against the same failure? A task that records this sequence gives a later reviewer a much better understanding of the system than a task that presents only a clean final diff.

This is one reason durable task state matters. If a process restarts halfway through a repair, it should not begin from the fiction that no work has happened. It should resume with the last verified facts, the unresolved failure, the branch state, and the authority needed for the next action. That is how an agent's experience becomes cumulative rather than disposable.

What software can teach, and what it cannot

Software is a good training ground because feedback is dense, artifacts are inspectable, and interventions can be limited. It offers a practical bridge between language models and consequential work. But it is still only one kind of environment.

The goal is not to build agents that become excellent at generating a ritual of commands. It is to build systems that can maintain a disciplined relationship with evidence: form a hypothesis, act within a boundary, observe an effect, preserve uncertainty, and hand work to the next person in a usable state.

Repositories are valuable because they make that discipline possible. They give agents something more demanding than a prompt and something more honest than a perfect benchmark: a changing system that can answer back.

This distinction has consequences for evaluation. A benchmark that checks only the final diff can reward lucky edits and miss brittle reasoning. A better evaluation can ask whether the agent used relevant evidence, preserved constraints across retries, and stopped when uncertainty remained. It can also measure recovery: whether a later agent or reviewer can understand the current state without replaying an entire chat.

What the environment should expose

Not every signal deserves equal weight. Build output is often noisy. Tests may be incomplete. A screenshot can prove a visible state while saying little about accessibility or failure handling. The system needs a way to connect a claim with the evidence that actually supports it.

That is why the infrastructure around an agent matters. Sandboxed execution, repository state, permissions, tests, previews, logs, and review checkpoints are not merely tools attached to a model. Together, they define what the model can know about its own work.

The near-term opportunity is practical rather than mystical. Build environments in which agents can form hypotheses, make bounded changes, collect evidence, and recover from interruption. Software is a good place to begin because the feedback is dense, the artifacts are inspectable, and the consequences are real enough to teach discipline.