At Jane Street, coding agents can test a terminal application and read its screen as text. That simple feedback loop helps them check their own changes. The trading firm's internal harness, AIDE, grew alongside the framework that makes those tests possible. Its next investment reaches further: mathematical ways to verify properties of generated code.
AIDE fits the tools people already use
Jane Street's May 2026 account describes AIDE as its own coding-agent harness: the software around a model that supplies tools and controls execution. The company wanted model choice, support for its unusual development environment, and control over sandboxes.
Its Bonsai_term framework makes terminal applications testable through text snapshots. An agent can run an interaction and read the resulting screen. Jane Street also reports internal tools for managing agent sessions and evaluations. The article gives no fleet size or company-wide delivery rate.
That makes this a case about the work environment. A product manager evaluating a similar investment can ask the team to demonstrate one complete interaction: change a feature, run it, inspect the result, and recover from an intentional failure. The demonstration should include the failure. A successful first attempt says little about how much supervision the next attempt needs.
Verification becomes part of the investment
In June 2026, Yaron Minsky explained why Jane Street was forming a formal-methods team. Formal methods use mathematical specifications to establish properties of a program. His argument has two parts: agents make these techniques easier to use, and generated code increases the value of dependable verification. Jane Street's experience with types already suggested that stronger guarantees give agents useful feedback.
This was an investment thesis and team-building announcement. The post does not establish that Jane Street had deployed a system that automatically proves and ships arbitrary agent-written code.
For a reader deciding where to spend engineering time, three kinds of evidence deserve separate questions:
| Evidence | Question it helps answer | Decision still needed |
|---|---|---|
| A reproducible example | Does this interaction behave as expected? | Have we chosen representative cases? |
| A stated program property | Does the implementation preserve a particular guarantee? | Does that guarantee cover the failure we care about? |
| A release review | Is this change ready for users? | Are the remaining risks and product tradeoffs acceptable? |
These are SWFT's decision categories, not a description of Jane Street's release process. That process is not detailed in the cited articles.
What to borrow first
Start by finding the part of a task that an agent cannot currently observe. It might be the final screen, an error response, or the state left after an interrupted operation. Give that result a repeatable check before increasing the number of agents working on it.
Then examine the checks themselves. A test can be easy to run yet miss the important requirement. Ask a domain expert which behavior would make a passing result unacceptable, and turn that answer into another check or an explicit human decision.
Jane Street's example belongs in a software-factory reference because it shows how the surrounding engineering system changes. It provides no public basis for a claim about autonomous trading, a thousand-agent swarm, or a measured company-wide productivity gain.