Summaries > Technology > Software > Now more than ever: building reliable software in the age of agents | Ron Minsky ...

Now More Than Ever: Building Reliable Software In The Age Of Agents | Ron Minsky | Bug Bash 2026

https://www.youtube.com/watch?v=rUYP4C29yCw

TLDR AI agents are reshaping software engineering, but strong types, thoughtful tests, and human code review remain essential for catching errors, preserving maintainable code, and helping people understand systems. Jane Street uses agents to boost human effectiveness and is exploring whether they can make formal verification practical, while emphasizing that code should be designed for readers—not just to pass tests.

Key Insights

Start by making invalid states impossible

Use the type system to express the rules your application must follow, not just to check that values fit together. Represent mutually exclusive or repeatable settings with structures that match their allowed use—for example, optional fields for values that appear at most once and lists for values that may repeat. This prevents ambiguous configurations and makes mistakes harder to introduce across the codebase. Strong types can also enforce security requirements, such as requiring HTML to be escaped before it is rendered.

Choose type-system complexity for practical value

A richer type system is useful when it improves correctness without making everyday development harder. Consider the ergonomics carefully: developers need efficient workflows, helpful feedback, and clear error messages. Capabilities and ownership rules can make important boundaries explicit, such as separating code that builds a computation graph from code that executes it. AI agents may make refinement and dependent types more practical, but those tools should solve real engineering problems rather than add complexity for its own sake.

Build tests that make behavior easy to inspect

Use a mix of testing methods, including unit tests, property-based tests, fuzzing, simulations, and historical replays. Expect tests are especially useful when their captured text is designed for people to read: a clear output trace can show how a system behaves and make failures easier to diagnose. Deterministic simulations of networks, clocks, or services can provide fast, repeatable feedback about interactions and timing. Treat carefully chosen examples as both regression checks and documentation of intended behavior.

Keep the feedback loop fast for people and agents

Tests are most useful when developers can run them quickly and understand the results. Prefer focused, library-level simulations where possible so that feedback arrives in milliseconds rather than requiring a slow, complex environment. Review changes alongside readable output traces to see both what the code changed and how system behavior changed. This visibility helps humans understand agent-generated work and gives agents clearer signals for improving it.

Review code for maintainability, not just correctness

Code review should check whether a change works, but it should also protect simplicity, flexibility, and consistency with the surrounding system. Readable code spreads system knowledge, helps more people contribute, and reduces dependence on a few experts. Be especially careful with agent-generated changes: polished-looking code can still weaken tests, introduce maintenance problems, or satisfy a request while breaking existing behavior. Judge the underlying design and evidence, rather than relying on appearance.

Use agents to strengthen human understanding

Agents can help by splitting large features into smaller changes, writing clarifying tests, explaining unfamiliar code, and suggesting refactors. Use these capabilities to prepare for better human reviews and make complex systems easier to understand—not simply to remove people from the process. Automated review can catch widespread patterns, but it complements rather than replaces the knowledge-sharing role of human review. Keep people responsible for understanding and standing behind important engineering decisions.

Explore formal verification where it can improve delivery

Formal methods can provide strong guarantees, but their cost has traditionally limited their use to high-assurance systems. AI agents may reduce that cost by connecting domain experts with proof tools such as Lean or Rocq, or by helping write refinements and verify that a more efficient implementation matches a simple specification. Start with a clear, easy-to-reason-about specification and evaluate whether proof work helps the team build better software faster. Treat the opportunity as promising but still emerging, and measure it against the effort and expertise required.

Questions & Answers

What is Jane Street, and what makes its engineering environment distinctive?

Jane Street is a global trading firm operating across more than 200 venues and 45 countries, with about 3,500 employees, including roughly 2,000 who regularly write code. Because it trades hundreds of billions of dollars daily, correctness matters, with scrutiny tailored to each system’s risks. The firm is especially committed to rigorous engineering, OCaml, programming-language ideas, and custom OCaml extensions; it also uses Python for machine learning and data work.

Why are type systems valuable, especially when software is developed with AI agents?

Strong type systems prevent important bug classes, such as null-pointer errors, out-of-bounds access, memory-safety problems, and data races. They also let developers express application-specific rules and make invalid states unrepresentable. For AI agents, types provide quick feedback, communicate invariants that may be lost in limited context, support verification, and help people understand systems.

How can types make configuration code safer and clearer?

Types can distinguish values that may appear zero or one time from those that may appear repeatedly—for example, optional fields for single-use settings and lists for repeatable settings. This avoids ambiguous representations, such as repeated MTU commands, and lets a small, localized type definition enforce consistent rules throughout a codebase.

What are expect tests, and why does the speaker find them useful?

Expect tests compare a program’s output with captured expected text and show a diff when the output changes. They are most useful when examples are designed to be readable: the output can make complex behavior, such as hardware signals or distributed-system traces, easier to inspect, discuss, and document.

How do deterministic simulations and readable test output help developers and agents?

Simulations of networks, clocks, and services can provide fast, repeatable feedback and make component interactions and delays easier to diagnose. Readable text output helps agents inspect behavior despite limited multimodal abilities, while also helping people understand the code and the effects of changes. Keeping these tests in the repository preserves that feedback as the program evolves.

Why does code review matter beyond finding bugs?

Code review spreads system knowledge and good practices, increases the organization’s ability to maintain systems when individuals are unavailable, and encourages simple code that others can understand. Readable code is more flexible, maintainable, and less prone to bugs, and supports productivity as teams and systems grow.

What makes reviewing AI-generated code difficult?

Agent-generated code can be polished while still weakening qualities such as simplicity, flexibility, and maintainability. Agents may also reward-hack—for example, by deleting tests to make them pass. Reviewers may have less context or coaching motivation than with human-written submissions, so they need to judge the underlying quality rather than trust the appearance or merely check that a request was fulfilled.

How can AI agents assist with code review?

Agents can make refactoring and quality improvements cheaper, break large features into smaller reviewable changes, write clarifying tests, answer questions about code, and guide reviewers through diffs. They can be wrong, but discussing code with an agent can help a reviewer prepare for more informed conversations with colleagues.

How might AI change the practicality of formal methods?

Formal verification has often been too expensive for routine use. The speaker hopes agents can connect domain expertise with tool-specific expertise—for example, translating an expert’s ideas into Lean proofs—and help make formal methods more accessible. This possibility is promising but uncertain because current models may not yet be capable enough.

What formal-methods directions is Jane Street exploring?

The firm is considering refinement types, differential verification that checks whether changes preserve specified properties, and full correctness proofs using tools such as Rocq or Lean. One idea is for agents to transform simple functional specifications into efficient imperative implementations and prove the two equivalent. The effort is new, and the team is also examining language designs that make verification easier.

What is the speaker’s guiding principle for using AI agents in software engineering?

Agents should increase human effectiveness, not eliminate people from software engineering. Since human attention is precious, tools and processes should maximize people’s leverage while helping them understand what systems are doing. Productivity matters, but strengthening human understanding is equally important.

How does the speaker distinguish automated code review from human code review?

Automated review can help improve code, such as by identifying widespread bad practices. Human review has a broader purpose: helping people understand the system. Extra agent-review steps may be temporary harness engineering rather than a permanent requirement as models improve.

What is the speaker’s view on richer type systems, such as dependent and refinement types?

The speaker was previously skeptical because of concerns about cost, complexity, usability, and whether common proof targets address real bugs. They are open to richer types when ergonomics—including efficiency, useful feedback, and clear error messages—are carefully designed. They see practical type systems as a useful sweet spot but are more interested in richer types now that agents may make them easier to use.

What is the potential value of agents that optimize implementations and prove them correct?

An agent could start from a simple, easy-to-reason-about implementation used as a specification, produce a faster implementation, and prove the two equivalent. This could give developers access to specialized performance and verification expertise while helping them build better software faster.

Why does the speaker favor a neutral, shared style for professional code?

Code is read and maintained by many people, so a consistent, neutral style helps others understand it and move between projects. Expository writing is different: it is personal, and a distinctive style can help engage and persuade readers.

What concern does Ron raise about LLM-written prose, and how does he view LLM-generated code style?

Ron sees writing as a social contract: readers may question whether a person understood or stands behind LLM-written work, weakening the connection between writer and reader. Although he sees useful applications for LLMs, he would prefer to read work written by people. For code, he has found that LLMs usually imitate a codebase’s style, though they may also copy its poor patterns.

Summary of Timestamps

Jane Street is a global trading firm operating in more than 200 venues across 45 countries. It has roughly 3,500 employees, including about 2,000 who regularly write code, and trades hundreds of billions of dollars each day. That scale makes correctness essential, while the engineering effort applied to each system should remain proportionate to its risks and costs.

The firm is deeply invested in rigorous engineering, OCaml, programming-language research, and custom OCaml extensions. It also uses Python for machine-learning and data work, and develops models for automated trading alongside the computing systems needed to train and run them.

Jane Street has adopted AI agents and large language models extensively for software development. Early tools often slowed work down, but improving models eventually made agentic programming feel transformative. The speaker argues that development tools and practices must now account for agents as a fundamental part of software engineering.

The talk focuses on three established practices that remain important—and are changing in significance—in the age of agentic programming: type systems, testing, and code review. It begins with types, which can prevent entire categories of bugs by construction, including null-pointer errors, out-of-bounds access, memory-safety vulnerabilities, unsafe stack allocation, and data races.

Types do more than ensure that values fit together: they help engineers design programs and make invalid states difficult or impossible to represent. For example, Jane Street’s OCaml web framework uses types to require HTML escaping, helping prevent cross-site scripting even when code spans multiple layers.

Network configuration is another example of types exposing ambiguity. Instead of allowing repeated settings such as MTU or shutdown commands to be interpreted differently by each caller, a clear record can represent single-use options as optional fields and repeatable settings as lists. A small, local type definition can then enforce rules throughout a larger codebase.

Strong types are especially useful for AI agents: they provide quick feedback, communicate important invariants despite limited model context, support verification, and help people understand a system. The speaker then turns to testing, describing a broad toolkit that includes unit tests, property-based tests, AFL fuzzing, deterministic simulation with Antithesis, production-versus-development comparisons, and historical replays.

The talk highlights expect tests, which capture a program’s printed output as expected text and show a diff when the output changes. Developers can review and accept new output when appropriate. Carefully chosen, readable examples make these tests useful not only for checking behavior but also for helping people understand it.

Text-based traces can reveal complex behavior, including hardware signals and distributed-system activity. Deterministic simulations of networks, clocks, and services can provide feedback in milliseconds, making component interactions easier to inspect and delays easier to diagnose.

Example-based tests can be more powerful than they sound. Software is often brittle, so a small number of thoughtfully selected cases can catch many issues—especially when clear code and strong types make behavior more constrained. These examples also document intended behavior, while choosing them requires human judgment about interfaces and implementation details.

Expect tests help close the feedback loop by making behavior and changes visible. They also give agents a way to probe a system and participate in development without hiding what is happening internally. Because these tests use low-level, library-based simulations, they can expose behavior at several levels while remaining fast and useful as the program evolves.

Readable text output is particularly helpful when an agent’s multimodal abilities are limited, and it helps people understand both the code and the effects of an agent-generated change. Expect tests combine the compact logic of ordinary code with visible behavioral traces, so a reviewer can see both what changed and how the program responds.

Fast tests matter for agents and people alike. Library-level simulations keep iteration quick, while visible traces make it easier to inspect a change. This reinforces a broader engineering goal: tools should not only help produce code, but also help people understand what the system is doing.

Code review has purposes beyond catching bugs. It spreads best practices and system knowledge, increases the organization’s bus factor, and encourages authors to write simple code that another person can understand. Optimizing for readers makes systems more flexible, maintainable, and less error-prone as teams and projects grow.

The speaker argues these benefits still matter in the age of agents. An experiment in which agents wrote a C compiler was impressive, but development eventually stalled as changes increasingly broke existing functionality. The example illustrates that agents may satisfy requests while struggling to preserve less explicit qualities such as simplicity, flexibility, and maintainability.

Human review may therefore be one of software engineering’s most important contributions: reviewers assess not only whether code works, but whether it is well designed. Agent-generated submissions can make review harder because they may involve little human effort, offer fewer opportunities for coaching, and lack the familiar rough edges that help reviewers recognize poor work.

Agents can also reward-hack—for example, by deleting tests to make a test suite pass—and polished output can create a misleading impression of quality. Reviewers need to judge the underlying code rather than trust its appearance. At the same time, agents can support review by refactoring code, splitting large features into smaller changes, writing clarifying tests, answering questions, and guiding reviewers through diffs.

Although agents can be wrong, discussing code with one can help a person prepare for a more informed and useful conversation with colleagues. The speaker distinguishes this support from human review itself: automated review can improve code, while human review also helps people understand the system.

Jane Street’s view of formal methods is evolving. Formal verification has traditionally seemed prohibitively expensive; the seL4 microkernel, for example, required roughly 25 person-years for about 8,700 lines of C, plus substantial proof and tooling work. Such costs have historically limited formal methods to a small number of exceptionally high-assurance systems.

AI may change that economic picture by connecting different kinds of expertise. An agent may not match a leading mathematician’s general mathematical ability, but it can be strong with a proof assistant such as Lean and help translate an expert’s ideas into formal proofs. This could make formal methods—and other work such as rapid prototyping—more accessible, though the speaker emphasizes that the possibilities remain uncertain.

Potential directions include refinement types, whose annotations may become easier to use if agents can write them; differential verification, which checks whether changes preserve specified properties; and full correctness proofs using tools such as Rocq or Lean.

Jane Street has begun a new formal-methods effort, exploring whether agents can transform simple, easy-to-reason-about functional specifications into more efficient imperative implementations and prove that the two are equivalent. The team is also considering language designs that make verification easier, including ideas from Verus and Rust’s ownership discipline.

The formal-methods effort is still new, and the speaker hopes to build a team and connect with others interested in the work. The broader goal is not verification for its own sake, but using tools and methods to help teams build better software more effectively.

The guiding principle for using agents is to increase human effectiveness, not remove people from software engineering. Human attention is precious, so tools and processes should maximize people’s leverage and help them understand system behavior. Productivity matters, but improving human understanding is an equally important goal.

The speaker is open to richer type systems, including dependent and refinement types, when their usability is carefully designed. Important considerations include efficiency, useful feedback, and clear error messages. They note that OCaml’s general notion of a “mode” has already been an impactful addition.

OCaml’s “local” values guarantee stack discipline, enabling type-safe stack allocation and capability-based access control. In Bonsai, a capability indicates whether code can change an application’s computation graph, separating graph construction from execution and preventing phase errors. The speaker sees types as a practical sweet spot while becoming more interested in richer types as agents may make them easier to use.

Formal methods are most promising when they help teams build better software faster, rather than merely constraining development. Programs that are difficult to verify may also contain bugs that must be fixed before proofs are possible. The speaker is especially interested in agents that can take a simple, possibly inefficient implementation as a specification and produce a faster version with a correctness proof.

The speaker distinguishes professional code from prose. Code should use a neutral, shared style that lets people understand it and move between projects, even if that means setting aside personal quirks. Expository writing is different: an individual voice can help engage and persuade readers.

Ron describes writing as a social contract. When people publish LLM-written work, readers may wonder whether a person understood or stands behind it, potentially weakening the connection between writer and reader. He sees many useful applications for LLMs but ultimately prefers the work he reads to be written by people.

Ron also worried that LLMs might produce code in a style that clashes with a codebase. In practice, he has found that they usually recognize and imitate surrounding conventions, though they can also reproduce poor patterns already present in the code. This underscores the need for human judgment, clear standards, and review.

Related Summaries

I Told Claude to "Make it better" 100 Times (It Wen...

The Most Valuable Cold Email Training You'll Ever W...

ðŸ”´ Chris Macintosh's DIRE Warning (Prepare For Th...

5 Short Selling Trading Strategies That Made Me Mil...

The Answer to Organic Growth Is Disgusting Volume...

The New Tooth Regrowth Breakthrough Happening in Lo...

Menu