Every week, we share emerging practices for building with AI, tested and explained. Podcast hosted by @bkase_ and @christinetyip.
Joined July 2026
- Tweets158
- Following36
- Followers360
- Likes295
Pinned Tweet
Tool calls are the hidden bottleneck killing the AI coding speed.
Models are getting faster, but tests and builds still take time, making the agent spend more time waiting for tool calls to end than coding. @steipete's Crabbox is one interesting way to speed up your agent.
To make your agents faster, ask yourself:
1) Where is the time going? Measure which tool calls are slowing your agents down.
2) Can I run fewer checks? Select relevant tests instead of always running the entire suite.
3) Can I parallelize? Run independent tests concurrently.
4) Am I hitting CPU/RAM limits? Offload expensive work to other machines with tools like Crabbox.
5) Can I use faster tools? Try Oxlint instead of ESLint, or build your own. We built a Swift linter that speeds things up by 20x.
We walk through these approaches, what we've tried, and the tradeoffs in our new episode.
00:00 The hidden bottleneck in coding-agent speed
01:27 Where agents spend their time
06:28 Running fewer tests without losing coverage
15:40 Parallelizing verification
17:43 Offloading tests with Crabbox
23:56 Faster tools: Oxlint and custom linters
29:30 Which optimizations are worth trying?
Superlinear retweeted
We use @steipete's crabbox to offload large tests. It makes our coding agents faster.
With crabbox, more tests/builds can run in parallel without competing for CPU+RAM. Higher tool call throughput, less waiting.
🧵 More ways to speed up agents in the full episode.
xitter.cf/steipete/status/211079…
We use @steipete's crabbox to offload large tests. It makes our coding agents faster.
With crabbox, more tests/builds can run in parallel without competing for CPU+RAM. Higher tool call throughput, less waiting.
🧵 More ways to speed up agents in the full episode.
xitter.cf/steipete/status/211079…
For more ways to speed up your coding agent, check out the full episode:
- YouTube: youtube.com/watch?v=Z3h0i_hr…
- Apple Podcasts: podcasts.apple.com/gb/podcas…
- Spotify: open.spotify.com/episode/0Zg…
xitter.cf/superlinear_fm/status/…
Tool calls are the hidden bottleneck killing the AI coding speed.
Models are getting faster, but tests and builds still take time, making the agent spend more time waiting for tool calls to end than coding. @steipete's Crabbox is one interesting way to speed up your agent.
To make your agents faster, ask yourself:
1) Where is the time going? Measure which tool calls are slowing your agents down.
2) Can I run fewer checks? Select relevant tests instead of always running the entire suite.
3) Can I parallelize? Run independent tests concurrently.
4) Am I hitting CPU/RAM limits? Offload expensive work to other machines with tools like Crabbox.
5) Can I use faster tools? Try Oxlint instead of ESLint, or build your own. We built a Swift linter that speeds things up by 20x.
We walk through these approaches, what we've tried, and the tradeoffs in our new episode.
00:00 The hidden bottleneck in coding-agent speed
01:27 Where agents spend their time
06:28 Running fewer tests without losing coverage
15:40 Parallelizing verification
17:43 Offloading tests with Crabbox
23:56 Faster tools: Oxlint and custom linters
29:30 Which optimizations are worth trying?
Superlinear retweeted
This episode was super influential on my development flow.
Tool calls are the hidden bottleneck killing the AI coding speed.
Models are getting faster, but tests and builds still take time, making the agent spend more time waiting for tool calls to end than coding. @steipete's Crabbox is one interesting way to speed up your agent.
To make your agents faster, ask yourself:
1) Where is the time going? Measure which tool calls are slowing your agents down.
2) Can I run fewer checks? Select relevant tests instead of always running the entire suite.
3) Can I parallelize? Run independent tests concurrently.
4) Am I hitting CPU/RAM limits? Offload expensive work to other machines with tools like Crabbox.
5) Can I use faster tools? Try Oxlint instead of ESLint, or build your own. We built a Swift linter that speeds things up by 20x.
We walk through these approaches, what we've tried, and the tradeoffs in our new episode.
00:00 The hidden bottleneck in coding-agent speed
01:27 Where agents spend their time
06:28 Running fewer tests without losing coverage
15:40 Parallelizing verification
17:43 Offloading tests with Crabbox
23:56 Faster tools: Oxlint and custom linters
29:30 Which optimizations are worth trying?
Superlinear retweeted
Tool calls are the hidden bottleneck killing the AI coding speed.
Models are getting faster, but tests and builds still take time, making the agent spend more time waiting for tool calls to end than coding. @steipete's Crabbox is one interesting way to speed up your agent.
To make your agents faster, ask yourself:
1) Where is the time going? Measure which tool calls are slowing your agents down.
2) Can I run fewer checks? Select relevant tests instead of always running the entire suite.
3) Can I parallelize? Run independent tests concurrently.
4) Am I hitting CPU/RAM limits? Offload expensive work to other machines with tools like Crabbox.
5) Can I use faster tools? Try Oxlint instead of ESLint, or build your own. We built a Swift linter that speeds things up by 20x.
We walk through these approaches, what we've tried, and the tradeoffs in our new episode.
00:00 The hidden bottleneck in coding-agent speed
01:27 Where agents spend their time
06:28 Running fewer tests without losing coverage
15:40 Parallelizing verification
17:43 Offloading tests with Crabbox
23:56 Faster tools: Oxlint and custom linters
29:30 Which optimizations are worth trying?
Superlinear retweeted
crabbox is underrated
Tool calls are the hidden bottleneck killing the AI coding speed.
Models are getting faster, but tests and builds still take time, making the agent spend more time waiting for tool calls to end than coding. @steipete's Crabbox is one interesting way to speed up your agent.
To make your agents faster, ask yourself:
1) Where is the time going? Measure which tool calls are slowing your agents down.
2) Can I run fewer checks? Select relevant tests instead of always running the entire suite.
3) Can I parallelize? Run independent tests concurrently.
4) Am I hitting CPU/RAM limits? Offload expensive work to other machines with tools like Crabbox.
5) Can I use faster tools? Try Oxlint instead of ESLint, or build your own. We built a Swift linter that speeds things up by 20x.
We walk through these approaches, what we've tried, and the tradeoffs in our new episode.
00:00 The hidden bottleneck in coding-agent speed
01:27 Where agents spend their time
06:28 Running fewer tests without losing coverage
15:40 Parallelizing verification
17:43 Offloading tests with Crabbox
23:56 Faster tools: Oxlint and custom linters
29:30 Which optimizations are worth trying?
Superlinear retweeted
If you are harness engineering properly, tool call time is your bottleneck. Improve your tool call time and you will get more done faster.
Your agent's speed can be broken up into inference time, tool call time, and the time you spend understanding what happened at the end of the turn and then steering.
As the models get faster, inference time goes down.
To reduce the time you spend reviewing and figuring out what to do next, you need to improve your harness which inevitably requires increasing the work of verification-related tool calls.
Thus, you will be stuck with some fixed large amount of work to do in your tool calls.
So how to make this faster?
Recently, I discovered Crabbox by @steipete which enabled me to easily offload the expensive work to an extra computer in my house without needing to offload my agent.
We also discuss a handful of other options for improving tool call performance as well.
And if you improve tool call performance, your agent gets more work done for you faster!
[diagram from @martinald 's blog post]
Tool calls are the hidden bottleneck killing the AI coding speed.
Models are getting faster, but tests and builds still take time, making the agent spend more time waiting for tool calls to end than coding. @steipete's Crabbox is one interesting way to speed up your agent.
To make your agents faster, ask yourself:
1) Where is the time going? Measure which tool calls are slowing your agents down.
2) Can I run fewer checks? Select relevant tests instead of always running the entire suite.
3) Can I parallelize? Run independent tests concurrently.
4) Am I hitting CPU/RAM limits? Offload expensive work to other machines with tools like Crabbox.
5) Can I use faster tools? Try Oxlint instead of ESLint, or build your own. We built a Swift linter that speeds things up by 20x.
We walk through these approaches, what we've tried, and the tradeoffs in our new episode.
00:00 The hidden bottleneck in coding-agent speed
01:27 Where agents spend their time
06:28 Running fewer tests without losing coverage
15:40 Parallelizing verification
17:43 Offloading tests with Crabbox
23:56 Faster tools: Oxlint and custom linters
29:30 Which optimizations are worth trying?
Superlinear retweeted
Good tip: check where your coding agent actually spends its time after you send a prompt.
I hadn't really thought about speeding up tests and other tool calls before, but it turns out they can make a big difference to how long each turn takes.
Tool calls are the hidden bottleneck killing the AI coding speed.
Models are getting faster, but tests and builds still take time, making the agent spend more time waiting for tool calls to end than coding. @steipete's Crabbox is one interesting way to speed up your agent.
To make your agents faster, ask yourself:
1) Where is the time going? Measure which tool calls are slowing your agents down.
2) Can I run fewer checks? Select relevant tests instead of always running the entire suite.
3) Can I parallelize? Run independent tests concurrently.
4) Am I hitting CPU/RAM limits? Offload expensive work to other machines with tools like Crabbox.
5) Can I use faster tools? Try Oxlint instead of ESLint, or build your own. We built a Swift linter that speeds things up by 20x.
We walk through these approaches, what we've tried, and the tradeoffs in our new episode.
00:00 The hidden bottleneck in coding-agent speed
01:27 Where agents spend their time
06:28 Running fewer tests without losing coverage
15:40 Parallelizing verification
17:43 Offloading tests with Crabbox
23:56 Faster tools: Oxlint and custom linters
29:30 Which optimizations are worth trying?
Watch on
- YouTube: youtube.com/watch?v=Z3h0i_hr…
- Apple Podcasts: podcasts.apple.com/gb/podcas…
- Spotify: open.spotify.com/episode/0Zg…
Newsletter: superlinear.fm
Great tip from the replies worth highlighting:
If your agent relies on lots of skills (or some critical ones), it could be a big problem if the skill breaks after swapping in a new model.
Workaround: save your early successful manual runs, then replay them after a model swap to check whether the right skills are still being invoked and producing the expected results.
Basically, build regression tests from real workflows.
Great one, @kartikb753 !
Superlinear retweeted
the human step is an interesting design choice here. i'd want the handoff to feel like picking up a task mid-stride: what's already done, what's blocking it, and where the agent can resume. there's a lot of product design in that little moment.
How do you build your own Dots or open-source Grok Bot?
Start as high up the stack as you can. Use the most off-the-shelf layer that still gives you the control you need, and only move down when your agent requires it.
We had @an_engineer_log , founder of YC F26 startup Agent37, walk us through what he’s seen work across real agent products. A few things that stood out:
- Dots, Muse, Instinct & Grok Bot are finished products. If you want to build your own version, Hermes or OpenClaw give you much of the machinery already. If you need fine-grained control over the agent loop and context, go further down to something like Pi.
- don't automate a workflow before you understand it. do it manually with an agent first, then turn the repeatable parts into skills. One product we discussed ended up with 100+ skills for its workflow.
- same with evals. don't start by designing an eval suite for a process you barely understand. Run it manually a few times, learn what "good" looks like, then encode those signals.
- if you're building for multiple users, don't run them all in the same computer/sandbox to save money. Give each user their own isolated environment.
- humans can be part of the agent architecture too. @an_engineer_log spent countless hours trying to make browser automation reliable, then realized it was better to have a human handle the brittle browser/form steps while the agent did the rest.
We also walk through a working Dots-like agent built on Hermes , with its own browser, files, memory, and computer per user.
@Agent37HQ is also giving free credits to listeners who want to try running their own agents in an agent sandbox.
First people to reply to this thread will get them.
00:00 Choosing an agent stack
03:29 Products vs. harnesses
04:43 The abstraction ladder
07:21 Memory and scheduling
15:16 When to customize
18:33 Where agents run
24:34 Agent sandbox economics
26:27 One sandbox per user
28:36 From manual work to skills
37:54 Rent humans
42:43 Harness by use case
47:01 Building a Dots-like agent
Superlinear retweeted
Had a fun time chatting about how to build your own Dots, GrokBot, Instinct, Muse etc.
OpenSource github templates for each of them below :)
xitter.cf/superlinear_fm/status/…
How do you build your own Dots or open-source Grok Bot?
Start as high up the stack as you can. Use the most off-the-shelf layer that still gives you the control you need, and only move down when your agent requires it.
We had @an_engineer_log , founder of YC F26 startup Agent37, walk us through what he’s seen work across real agent products. A few things that stood out:
- Dots, Muse, Instinct & Grok Bot are finished products. If you want to build your own version, Hermes or OpenClaw give you much of the machinery already. If you need fine-grained control over the agent loop and context, go further down to something like Pi.
- don't automate a workflow before you understand it. do it manually with an agent first, then turn the repeatable parts into skills. One product we discussed ended up with 100+ skills for its workflow.
- same with evals. don't start by designing an eval suite for a process you barely understand. Run it manually a few times, learn what "good" looks like, then encode those signals.
- if you're building for multiple users, don't run them all in the same computer/sandbox to save money. Give each user their own isolated environment.
- humans can be part of the agent architecture too. @an_engineer_log spent countless hours trying to make browser automation reliable, then realized it was better to have a human handle the brittle browser/form steps while the agent did the rest.
We also walk through a working Dots-like agent built on Hermes , with its own browser, files, memory, and computer per user.
@Agent37HQ is also giving free credits to listeners who want to try running their own agents in an agent sandbox.
First people to reply to this thread will get them.
00:00 Choosing an agent stack
03:29 Products vs. harnesses
04:43 The abstraction ladder
07:21 Memory and scheduling
15:16 When to customize
18:33 Where agents run
24:34 Agent sandbox economics
26:27 One sandbox per user
28:36 From manual work to skills
37:54 Rent humans
42:43 Harness by use case
47:01 Building a Dots-like agent
Superlinear retweeted
Had an interesting convo with YC F26 founder @an_engineer_log on what he's seen work and fail across real agent products.
He's also giving listeners free @Agent37HQ credits. Reply to the original thread if you want to try running your own agent in a sandbox.
How do you build your own Dots or open-source Grok Bot?
Start as high up the stack as you can. Use the most off-the-shelf layer that still gives you the control you need, and only move down when your agent requires it.
We had @an_engineer_log , founder of YC F26 startup Agent37, walk us through what he’s seen work across real agent products. A few things that stood out:
- Dots, Muse, Instinct & Grok Bot are finished products. If you want to build your own version, Hermes or OpenClaw give you much of the machinery already. If you need fine-grained control over the agent loop and context, go further down to something like Pi.
- don't automate a workflow before you understand it. do it manually with an agent first, then turn the repeatable parts into skills. One product we discussed ended up with 100+ skills for its workflow.
- same with evals. don't start by designing an eval suite for a process you barely understand. Run it manually a few times, learn what "good" looks like, then encode those signals.
- if you're building for multiple users, don't run them all in the same computer/sandbox to save money. Give each user their own isolated environment.
- humans can be part of the agent architecture too. @an_engineer_log spent countless hours trying to make browser automation reliable, then realized it was better to have a human handle the brittle browser/form steps while the agent did the rest.
We also walk through a working Dots-like agent built on Hermes , with its own browser, files, memory, and computer per user.
@Agent37HQ is also giving free credits to listeners who want to try running their own agents in an agent sandbox.
First people to reply to this thread will get them.
00:00 Choosing an agent stack
03:29 Products vs. harnesses
04:43 The abstraction ladder
07:21 Memory and scheduling
15:16 When to customize
18:33 Where agents run
24:34 Agent sandbox economics
26:27 One sandbox per user
28:36 From manual work to skills
37:54 Rent humans
42:43 Harness by use case
47:01 Building a Dots-like agent
Superlinear retweeted
Principle: Understand how your tools work, not just as a user, but truly understand the components underneath.
Personal agents are an important new tool that can help you in your life, and you may want to build specialized ones for yourself or as a product for others.
We have "apple": Dots/Muse/Grok Bot/Instinct
and "linux": OpenClaw/Hermes
And these are built up of building blocks like a coding-harness, a scheduler, memory system, gateway, etc.
If you deeply understand how these tools work, you can be way more productive using them than if you have only a cursory understanding.
In a sense, this is the thesis behind our whole Superlinear podcast: Applying this principle to all aspects of building with coding agents.
We had a great conversation with @an_engineer_log founder of YC F26 @Agent37HQ going deep on personal agents under this lens!
How do you build your own Dots or open-source Grok Bot?
Start as high up the stack as you can. Use the most off-the-shelf layer that still gives you the control you need, and only move down when your agent requires it.
We had @an_engineer_log , founder of YC F26 startup Agent37, walk us through what he’s seen work across real agent products. A few things that stood out:
- Dots, Muse, Instinct & Grok Bot are finished products. If you want to build your own version, Hermes or OpenClaw give you much of the machinery already. If you need fine-grained control over the agent loop and context, go further down to something like Pi.
- don't automate a workflow before you understand it. do it manually with an agent first, then turn the repeatable parts into skills. One product we discussed ended up with 100+ skills for its workflow.
- same with evals. don't start by designing an eval suite for a process you barely understand. Run it manually a few times, learn what "good" looks like, then encode those signals.
- if you're building for multiple users, don't run them all in the same computer/sandbox to save money. Give each user their own isolated environment.
- humans can be part of the agent architecture too. @an_engineer_log spent countless hours trying to make browser automation reliable, then realized it was better to have a human handle the brittle browser/form steps while the agent did the rest.
We also walk through a working Dots-like agent built on Hermes , with its own browser, files, memory, and computer per user.
@Agent37HQ is also giving free credits to listeners who want to try running their own agents in an agent sandbox.
First people to reply to this thread will get them.
00:00 Choosing an agent stack
03:29 Products vs. harnesses
04:43 The abstraction ladder
07:21 Memory and scheduling
15:16 When to customize
18:33 Where agents run
24:34 Agent sandbox economics
26:27 One sandbox per user
28:36 From manual work to skills
37:54 Rent humans
42:43 Harness by use case
47:01 Building a Dots-like agent
Superlinear retweeted
How do you build your own Dots or open-source Grok Bot?
Start as high up the stack as you can. Use the most off-the-shelf layer that still gives you the control you need, and only move down when your agent requires it.
We had @an_engineer_log , founder of YC F26 startup Agent37, walk us through what he’s seen work across real agent products. A few things that stood out:
- Dots, Muse, Instinct & Grok Bot are finished products. If you want to build your own version, Hermes or OpenClaw give you much of the machinery already. If you need fine-grained control over the agent loop and context, go further down to something like Pi.
- don't automate a workflow before you understand it. do it manually with an agent first, then turn the repeatable parts into skills. One product we discussed ended up with 100+ skills for its workflow.
- same with evals. don't start by designing an eval suite for a process you barely understand. Run it manually a few times, learn what "good" looks like, then encode those signals.
- if you're building for multiple users, don't run them all in the same computer/sandbox to save money. Give each user their own isolated environment.
- humans can be part of the agent architecture too. @an_engineer_log spent countless hours trying to make browser automation reliable, then realized it was better to have a human handle the brittle browser/form steps while the agent did the rest.
We also walk through a working Dots-like agent built on Hermes , with its own browser, files, memory, and computer per user.
@Agent37HQ is also giving free credits to listeners who want to try running their own agents in an agent sandbox.
First people to reply to this thread will get them.
00:00 Choosing an agent stack
03:29 Products vs. harnesses
04:43 The abstraction ladder
07:21 Memory and scheduling
15:16 When to customize
18:33 Where agents run
24:34 Agent sandbox economics
26:27 One sandbox per user
28:36 From manual work to skills
37:54 Rent humans
42:43 Harness by use case
47:01 Building a Dots-like agent
How do you build your own Dots or open-source Grok Bot?
Start as high up the stack as you can. Use the most off-the-shelf layer that still gives you the control you need, and only move down when your agent requires it.
We had @an_engineer_log , founder of YC F26 startup Agent37, walk us through what he’s seen work across real agent products. A few things that stood out:
- Dots, Muse, Instinct & Grok Bot are finished products. If you want to build your own version, Hermes or OpenClaw give you much of the machinery already. If you need fine-grained control over the agent loop and context, go further down to something like Pi.
- don't automate a workflow before you understand it. do it manually with an agent first, then turn the repeatable parts into skills. One product we discussed ended up with 100+ skills for its workflow.
- same with evals. don't start by designing an eval suite for a process you barely understand. Run it manually a few times, learn what "good" looks like, then encode those signals.
- if you're building for multiple users, don't run them all in the same computer/sandbox to save money. Give each user their own isolated environment.
- humans can be part of the agent architecture too. @an_engineer_log spent countless hours trying to make browser automation reliable, then realized it was better to have a human handle the brittle browser/form steps while the agent did the rest.
We also walk through a working Dots-like agent built on Hermes , with its own browser, files, memory, and computer per user.
@Agent37HQ is also giving free credits to listeners who want to try running their own agents in an agent sandbox.
First people to reply to this thread will get them.
00:00 Choosing an agent stack
03:29 Products vs. harnesses
04:43 The abstraction ladder
07:21 Memory and scheduling
15:16 When to customize
18:33 Where agents run
24:34 Agent sandbox economics
26:27 One sandbox per user
28:36 From manual work to skills
37:54 Rent humans
42:43 Harness by use case
47:01 Building a Dots-like agent
we made it.
@VictorTaelin just followed + reposted our Bend2 episode ❤️
we’ve referenced his work and posts in so many episodes that this feels weirdly full circle.
We spent the last week building with @VictorTaelin’s @bendlang on real projects, and came away pretty impressed.
Some takeaways:
1. Bend changes what the human needs to pay attention to.
Instead of reviewing every implementation detail, you can spend more time getting the intent and laws right, then let the agent figure out the implementation and proof. You still need to make sure the laws actually express what you want.
2. Agents make formal verification much more practical.
The annoying part used to be writing and maintaining the proofs. Now the agent can do that work. Basically: you don’t need deep math knowledge to start anymore; you can work through the problem in English and use the model to find the algebra/laws.
3. The proof is useful feedback for the agent, not just a safety certificate at the end.
This was probably the most interesting thing we actually observed. In one of our projects using Bend, the agent proposed roughly 20 laws. When we made it prove all of them, 4 of the original laws were actually false. The proving process found counterexamples, forced the edge cases to be stated correctly, and changed the implementation.
4. Bend being a real general-purpose programming language with formal verification built-in matters a lot.
Before Bend 2 existed, you might have your real program in Rust/TypeScript and separately model it in Lean/TLA+. Then you have to trust that the thing you proved still matches the real program. Bend lets the code you execute also be the thing whose laws you prove. No more worrying about the 'model of your code' drifting from the real code.
5. You probably shouldn’t formally prove everything.
This was an important conclusion for us. Use it where correctness really matters, where the logic has a clear mathematical shape, where agents keep tripping up, or where there's a core that will evolve a lot. Proving every trivial piece of an app can be overkill and costs more tokens/time.
6. You don’t have to rewrite your whole app in Bend to use it.
It's easy to get started. We took one correctness-critical part of one of our existing TypeScript projects, rewrote just that slice in Bend, compiled it to JavaScript, and left the rest of the application alone. It is now 100% bug-free (actually proven!) and 4x faster.
We recorded our whole journey trying out Bend 2:
00:00 A new verification layer
00:47 Machine-checkable guardrails
10:11 Types, tests, and proofs
17:49 Find a problem worth proving
20:30 How algebraic laws enable optimization
25:03 Find the algebra
30:38 From exploration to self-contained spec
32:20 Laws that reflect your intent
37:33 Proofs and false laws
42:12 Bend in one part of an existing project
45:55 Costs and how much to prove
Superlinear retweeted
We spent the last week building with @VictorTaelin’s @bendlang on real projects, and came away pretty impressed.
Some takeaways:
1. Bend changes what the human needs to pay attention to.
Instead of reviewing every implementation detail, you can spend more time getting the intent and laws right, then let the agent figure out the implementation and proof. You still need to make sure the laws actually express what you want.
2. Agents make formal verification much more practical.
The annoying part used to be writing and maintaining the proofs. Now the agent can do that work. Basically: you don’t need deep math knowledge to start anymore; you can work through the problem in English and use the model to find the algebra/laws.
3. The proof is useful feedback for the agent, not just a safety certificate at the end.
This was probably the most interesting thing we actually observed. In one of our projects using Bend, the agent proposed roughly 20 laws. When we made it prove all of them, 4 of the original laws were actually false. The proving process found counterexamples, forced the edge cases to be stated correctly, and changed the implementation.
4. Bend being a real general-purpose programming language with formal verification built-in matters a lot.
Before Bend 2 existed, you might have your real program in Rust/TypeScript and separately model it in Lean/TLA+. Then you have to trust that the thing you proved still matches the real program. Bend lets the code you execute also be the thing whose laws you prove. No more worrying about the 'model of your code' drifting from the real code.
5. You probably shouldn’t formally prove everything.
This was an important conclusion for us. Use it where correctness really matters, where the logic has a clear mathematical shape, where agents keep tripping up, or where there's a core that will evolve a lot. Proving every trivial piece of an app can be overkill and costs more tokens/time.
6. You don’t have to rewrite your whole app in Bend to use it.
It's easy to get started. We took one correctness-critical part of one of our existing TypeScript projects, rewrote just that slice in Bend, compiled it to JavaScript, and left the rest of the application alone. It is now 100% bug-free (actually proven!) and 4x faster.
We recorded our whole journey trying out Bend 2:
00:00 A new verification layer
00:47 Machine-checkable guardrails
10:11 Types, tests, and proofs
17:49 Find a problem worth proving
20:30 How algebraic laws enable optimization
25:03 Find the algebra
30:38 From exploration to self-contained spec
32:20 Laws that reflect your intent
37:33 Proofs and false laws
42:12 Bend in one part of an existing project
45:55 Costs and how much to prove