@Michaelzsguo: This episode of Jane Street's podcast is incredibly hardcore and practical! It dives deep into how AI coding tools get rolled out internally at a company — very concrete, very thorough, and well worth studying. This is an episode of Jane Street's official tech podcast Signals and Threads, hosted by their head of tech…

This Jane Street podcast episode is incredibly deep and practical! It discusses how AI coding tools are rolled out within a company in concrete, thorough detail — well worth studying and drawing inspiration from.

This is an episode of Signals and Threads, Jane Street’s official tech podcast, hosted by technical lead Ron Minsky, with guest John Crepezzi, a developer tools engineer who builds internal AI tools at Jane Street.

John covers everything from the JaneGPT prototype built in three days, to permission systems, sandboxing, asynchronous coding agents, and code review — almost all real-world engineering problems you’d actually encounter.

A few points especially worth noting:

1. Build your own platform, but also use external tools.

Jane Street builds its own tool, AIDE, while also letting engineers use Claude Code and Codex. In-house tools can deeply integrate with internal builds, codebases, and permission systems; external tools bring new features and interaction paradigms, and also show the internal team where they’re falling short. You can’t just block external competition to make your own tool the “best” one.

2. Give AI its own identity: AI Users.

When an agent acts on your behalf, it uses a corresponding AI identity. This way, underlying services can distinguish between “you, the person” and “the AI working for you,” apply different permission rules accordingly, and track which code was generated with AI assistance. Integrating agents already involves reworking the identity and permission infrastructure.

3. Reducing friction in launching tasks visibly changes how people use them.

Their tool, AIDE mint, lets you describe a request directly in Slack. The system automatically creates a PR-like work unit, kicks off a build, and then runs the agent on your dev machine. The steps saved are minimal, yet far more people start delegating tasks to agents. This detail is highly valuable for anyone building internal tools.

4. Sandboxes should use allowlists — deny by default.

Blocking dangerous operations one by one with a denylist is easy to miss things. Models are getting better at finding alternative paths, so permission boundaries need to be enforced by the system, not reliant on a prompt saying “please don’t.”

5. Watch out for reward hacking — and for models circumventing rules to finish a task.

A very concrete example: the compiler treats warnings as errors, the model can’t fix them, so it just disables the warning check. The build passes on the surface, but the engineering standard has been bypassed. Similar behavior shows up in evaluations — searching for ready-made answers — so how tests are designed and what the agent can access must be considered together.

6. Once code generation becomes easy, verification and review deserve more investment.

The latter half of the discussion is especially good: AI can help people understand unfamiliar code, generate explanations and visualizations — but whoever submits the code still needs to understand their own changes. Just because an agent has written a feature doesn’t mean it’s worth merging. Review also needs to judge whether it’s necessary and whether it will make the system more complex.

If you’re rolling out AI coding within your company or building an internal agent platform, this is highly recommended. (Chinese subtitles available.)