Latest / Superlinear / How to Make Coding Agents Faster: Crabbox + 3 Fixes

Transcript

How to Make Coding Agents Faster: Crabbox + 3 Fixes · Superlinear

• 0:00
  Christine: Your coding agent is probably slower than it needs to be, and you don't have to switch to a faster, less capable model to fix that.
• 0:08
  Christine: We had multiple agents working in parallel, but every time they ran their end-to-end tests, they were eating up all the resources.
• 0:15
  Christine: So, how do you make your agents faster without sacrificing the verification that makes them reliable? Today we'll show four ways to do that, from simple changes you can make right away to some more involved techniques.
• 0:27
  Christine: So, Brandon, what exactly was happening with your project?
• 0:34
  Brandon: So, I was working on an Electron app and I had set up strong verification loops because that's what you need to do to build successfully these days, including lots of end-to-end tests.
• 0:47
  Brandon: And what was happening is when I was running these tests with just one agent, Electron keeps popping up over and over again over my work. I'm using tons of RAM.
• 1:01
  Brandon: My computer locks up.
• 1:03
  Brandon: It's so frustrating.
• 1:03
  Brandon: It's so so frustrating.
• 1:05
  Brandon: So I had to do something about it.
• 1:07
  Christine: Right. So instead of, you know, the agents doing the work so you can be productive elsewhere, actually you couldn't use your machine for anything else.
• 1:20
  Brandon: And the agent's barely doing any thinking.
• 1:23
  Brandon: It's just waiting. Just waiting on tool calls.
• 1:25
  Brandon: So frustrating.
• 1:27
  Christine: OK, there are probably ways to optimize this process, but before we dive into that, let's first look at what's actually slowing the agent down.
• 1:38
  Christine: So, when we talk about speeding up coding agents, where does their time go?
• 1:43
  Brandon: Well, let's pull up my favorite chart.
• 1:46
  Brandon: OK. I'm showing my favorite diagram for those that can't see it, this is a diagram that illustrates Amdahl's law applied to agents as inference time speeds up, the total time that it takes to work with agents doesn't speed up as fast. That's what this chart is showing.
• 2:09
  Brandon: This bar chart is broken up into three different chunks. There's one chunk that's model inference, one chunk that's tool calls, and one chunk that is called you. When you're waiting for your agent, you're waiting for the intelligence to happen, the actual inference. So that's the part that we can't really control if we wanna use smart models.
• 2:30
  Brandon: Then there's the tool calls.
• 2:32
  Brandon: And this is maybe building, testing, running things. OK? And then that last part is the time it takes as a human to understand what the agent's doing and to decide if it's going the right direction or to steer it.
• 2:49
  Brandon: As we add more guardrails, if we increase the amount that we verify, and if we have really strong end-to-end tests, and a lot of them, the part of the time that's for tool calls grows, and the part that is how often the human needs to be in the loop to make sure that it's going in the right direction shrinks because you can trust the agent more. Now, hopefully you're starting to see the point here. If we can't change the inference time, we've already shrunk the human time, but this tool call time is the problem. This is the problem.
• 3:34
  Brandon: This is how we can make agents faster.
• 3:36
  Brandon: If we make the tool call time faster, we make the agent faster.
• 3:39
  Christine: Right. So there's definitely a trade-off when you add more verification steps. On one hand you're like, whoa, and now I make it more reliable.
• 3:47
  Christine: There's more verification whether the agent really implemented the thing right.
• 3:52
  Christine: But it also makes the whole process longer.
• 3:56
  Christine: Yeah, maybe can you like talk like when this could be really impactful?
• 4:02
  Brandon: Well, firstly it's getting more and more of a problem because that's what this chart is showing the frontier models are getting faster.
• 4:09
  Brandon: You can run Codex in fast mode, you can run Opus is faster than it used to be but that doesn't mean that your tests speed up.
• 4:19
  Brandon: In fact, your tests are probably slowing down as your project is getting more complex.
• 4:24
  Christine: What are the situations when this is really impactful, when you really have to pay attention to your tool call time?
• 4:32
  Brandon: Big, big culprits for tool calls.
• 4:35
  Brandon: If you're having your agent do some kind of verification with judgment. So the agent is thinking and clicking around. That's the slowest thing. There's also if you're building a project in Rust or some other language that has a build process then you're waiting for the compilation time and that gets slower as the project grows in complexity.
• 5:02
  Brandon: And then there's also testing.
• 5:05
  Brandon: And what I think the community is sort of aligning on is that the kinds of tests that are very valuable that are the most helpful are black box end-to-end testing. Your test suite can get out of control if you don't pay attention to it.
• 5:23
  Christine: Mine definitely ran out of control.
• 5:26
  Christine: At some point it just built new features within a few minutes, but then it took an hour for me to wait until the tests were done.
• 5:34
  Christine: Yeah, I can see that happening.
• 5:39
  Christine: Yeah, unacceptable, yeah.
• 5:43
  Christine: So let's dive into how I could solve that.
• 5:46
  Christine: If I have a coding agent session right now, how would I find out which steps are taking the most time? What would I do?
• 5:54
  Brandon: I think a really easy thing you can do is ask your agent to review the recent sessions and specifically you're gonna wanna ask what parts of my tool calls are taking a long time so once you determine, is it the build, the tests is it like running review agents, then you can drill down more, right?
• 6:20
  Brandon: You can say, OK, it's something in my test suite and then you can maybe add more instrumentation to figure out exactly what parts of your tests are being slow.
• 6:28
  Christine: OK, so let's say once you know that verification and the test are the bottleneck, what can you actually change?
• 6:35
  Christine: Like, do agents need to run the entire test suite after every code change?
• 6:41
  Christine: What do you think?
• 6:42
  Brandon: No. So this is a pretty like relatively easy step to take but there's some risks, I would say.
• 6:54
  Brandon: So yeah, so you can talk to your agent and say, well which test do I need to run when I make these kinds of changes or these kinds of changes. So you can set up your test using tools that can track these dependencies very neatly with your code, like Bazel or Nix. You can use regular expressions to filter for tests that are connected to certain parts of your code.
• 7:22
  Brandon: You can even have an agent decide, like Jev, to choose which tests need to be run based on the changes you're making to your code base.
• 7:31
  Christine: How would we do that?
• 7:31
  Christine: How would you do it?
• 7:34
  Christine: I'm pretty interested in, like, how we can decide which tests are relevant to a particular change that you're making?
• 7:42
  Brandon: Yeah. So this is like an experiment that we ran when we were first playing with Jev.
• 7:47
  Brandon: Basically the input is the diff the changes. And then you can ask Jev, should I run this test for each test and you can just ask Jev in parallel on all your tests. And then Jev or any decision model will tell you, OK, I think you should run this with seventy percent probability or I think this one you don't have to run with some probability.
• 8:14
  Brandon: And then you can pick a threshold and run the ones that you need to run and skip the ones that Jev says you're allowed to skip.
• 8:21
  Christine: So you use a decision model to decide whether a test is relevant to a change.
• 8:27
  Brandon: Right. Right. But it's not always gonna be correct.
• 8:33
  Brandon: So that's something that might be scary.
• 8:35
  Brandon: And in fact, the exact tests that are the most helpful for keeping your agents on track, which are end-to-end tests, they're the most far away from the code change and so it's the hardest to decide whether it's safe to skip a particular end-to-end task given just the code change.
• 8:56
  Christine: Right. Because sometimes you could be like, OK, only these files are changed during this change, so we're only going to do tests that relate to these files. But now you're saying, but you know, that doesn't work for end-to-end tests.
• 9:10
  Brandon: Right. Unit tests are like testing specific functions which live in certain files, so that's easy.
• 9:16
  Brandon: End-to-end tests are like open the application, click around, do all these things, and attaching that to specific code changes, especially ones deep within the foundations of your application, sometimes are really difficult.
• 9:27
  Christine: I guess there's also been quite some debate around that, right? About agent-written tests and which ones are necessary.
• 9:35
  Brandon: There's nuance here, which I'll just quickly
• 9:37
  Brandon: summarize: if the LLM
• 9:43
  Brandon: is choosing its own tests so it's deciding what test it wants to write and you haven't steered it in any way, those are probably unhelpful. Those aren't gonna help you.
• 9:55
  Brandon: If you work with an agent to figure out the right testing strategy for some part of your project and you steer your worker to make those kinds of tests, it's probably a little bit more helpful even if you're making unit tests, integration tests.
• 10:13
  Brandon: However, what is the most helpful is these end-to-end tests. They're the best feedback loop to the agent. It's what a person would do when they're QAing the product or service.
• 10:25
  Brandon: They would use it and see if it works.
• 10:27
  Brandon: And if it works, you're done.
• 10:29
  Brandon: And if it doesn't work, then you know, you can go back and do the loop again.
• 10:33
  Christine: So when you said like, how do you work with the agent on testing strategy, do you mean like you would work on a testing strategy every time a change happens? Or like would you work on a testing strategy, a high-level testing strategy before a particular change happened?
• 10:52
  Brandon: This is one of those things that's like, you get a feel for it.
• 10:56
  Brandon: It's like, OK, small bug fixes, you don't need to say anything. Or maybe a one line of like, hey, like prove that this is failing before you fix it or something for huge new features in the application, using new modules, new tech, then yeah, I will sit down and be like, OK, let's figure out how to test this, like what are these different options what about like these kinds of tests?
• 11:20
  Brandon: What if we fuzz it?
• 11:21
  Brandon: What kind of end-to-end tests can we use?
• 11:24
  Brandon: Can we use property-based testing?
• 11:25
  Brandon: And then this is kind of a sliding scale if the task is small enough or if it's an incremental addition to some feature that I've already mapped out how to test it, I can just let the agent kind of follow the patterns. And even this isn't enough I think it's important to periodically go and review your verification step.
• 11:47
  Christine: That totally makes sense. I'm just wondering what is a good, like, default pattern to use?
• 11:55
  Christine: In my own projects I see that the agent just writes test every time I've built a new feature or after there's a change And then the number of tests just grows over time and it just keeps testing every previous test that it wrote before So what is a good, like, simple default heuristic maybe?
• 12:16
  Brandon: Don't let your agent make tests if you don't understand why it's making the tests.
• 12:21
  Brandon: I think that's like a good direction.
• 12:22
  Christine: But even if you do understand it's only I guess the default approach, what I've noticed my agents do is they just keep track of all the tests they've ever written and for every change they just test all the tests that they've ever written.
• 12:37
  Christine: And even if those you understand those tests and it made sense for that particular change their default approach is to just test everything.
• 12:48
  Brandon: I actually don't think it's that bad it is something that you should look at as your project gets really big But your unit tests should be fast and so it might be more expensive to figure out which one to run than to just run all of them.
• 13:05
  Brandon: And your end-to-end tests, it's too dangerous to decide which one is relevant or not.
• 13:10
  Brandon: And so it's safer just to run all of them now this isn't true forever.
• 13:16
  Brandon: As the project gets really big then you can take one of these steps and you can start with just using regular expressions that's really easy.
• 13:24
  Brandon: You just tell your agent use regular expressions to filter tests based on which files we're touching.
• 13:32
  Brandon: And then it'll work it'll start filtering tests. It might be slightly incorrect but that's not something I would recommend that you do until your test suite starts to get out of control but there's other things we can do first to speed this up.
• 13:49
  Christine: How would you define the test getting out of control?
• 13:53
  Christine: Like, if it takes an hour? If it takes fifty minutes?
• 14:00
  Brandon: I think if you've exhausted the other ways to speed it up that we haven't talked about yet and your test suite is taking more than a few minutes, then you should start digging into this.
• 14:15
  Christine: Gotcha. So maybe this is cutting down your test is not the first solution you should grab towards because it's it might affect the reliability of the thing that you're building.
• 14:29
  Christine: So, yeah.
• 14:32
  Christine: So what else what are less disruptive solutions?
• 14:37
  Brandon: Yeah. While choosing specific tests amongst tests that are good is something that you should not do too quickly what you should do quickly is talk to your agent to figure out if the tests that you have are good.
• 14:53
  Brandon: Because probably there's lots of shitty ones.
• 14:56
  Brandon: So what is a bad test a test that's unnecessarily slow, a test that is testing something that another test already covers. Or a test that is testing something stupid, which LLMs love to write.
• 15:12
  Brandon: So for example LLMs love to write tests that, like, a function has a certain name.
• 15:19
  Brandon: Those kinds of tests are just plain stupid so and it's really as easy as just a conversation with your agent to identify those.
• 15:28
  Christine: Cool. Yeah, I've definitely also seen tests for old features that I've already removed that are still there. Gotcha.
• 15:33
  Christine: So those are like the type of tests that you should remove.
• 15:38
  Christine: OK. That makes sense.
• 15:38
  Christine: And let's say we've already removed the unnecessary checks and we still have a large test suite, what's next?
• 15:51
  Christine: If my conclusion is I need all these tests, what else can we do?
• 15:55
  Brandon: You can run them in parallel.
• 15:58
  Brandon: So maybe not all of them, but you should be able to run most of them in parallel By default, your agents are gonna be running your tests sequentially.
• 16:07
  Brandon: So what that means is first your unit tests run, and then this integration test, then this integration test, and then one, two, three, four, five, each end-to-end test.
• 16:19
  Brandon: Whereas what you can do is run your unit tests at the same time as your end-to-end tests, and your end-to-end tests all run at the same time and your integration tests all run at the same time, subject to the resources you have available on the machine that you're running the tests and that highlights the next issue that comes up.
• 16:40
  Christine: Yeah. I'm just curious, like how would you tell your agent to run them simultaneously?
• 16:47
  Christine: Is it just telling them, run the tests that you can simultaneously, or are there more specific instructions we can give?
• 16:55
  Brandon: No. Yeah. Say make my test suite run the things in parallel that can and then it'll work.
• 17:06
  Brandon: And it's a little harder So it's just not something that, gets set up automatically. But on a recent project that I, jumped on, I noticed the test suite was taking like eight minutes and then I removed some bad tests and parallelized the rest and I got it down to one minute.
• 17:28
  Brandon: So.
• 17:29
  Christine: Oh, yeah. That's quite a difference.
• 17:33
  Christine: And you. Were talking about another solution before I stopped you.
• 17:43
  Brandon: Yeah. So, well, I was hinting at the problem, I guess and this is the problem that I most recently ran into So, you have the tests.
• 17:56
  Brandon: You want to run them.
• 17:57
  Brandon: You've parallelized them, but your computer can't handle it.
• 18:03
  Brandon: You're exhausting the resources on your machine.
• 18:05
  Brandon: I guess the solution is run them on other machines, right but how do you do that?
• 18:12
  Brandon: So, the like the kind of easy thing that people think of first is, OK, well, if I have another machine somewhere, like I have another computer in my house or a cloud machine I'll just run some of my agents over there. But it's kind of annoying to do that because then you have to think like, OK, what agent is running where which machine is more full than the other one?
• 18:40
  Brandon: You're as a human becoming like an operating system trying to balance resources.
• 18:45
  Brandon: And a computer is good at that.
• 18:48
  Brandon: So let the computer do that.
• 18:49
  Brandon: And I don't wanna have to think like of where my agent is running. I just wanna run my agents where my computer is, It's nice.
• 18:56
  Brandon: I like running agents on my laptop. I have all my tools set up, I have browsers that are logged in as me.
• 19:05
  Brandon: I have everything the way that I want it.
• 19:07
  Brandon: And I want my agents running on my laptop.
• 19:10
  Brandon: And actually, that's not the problem.
• 19:12
  Brandon: Like if even when I'm running lots of agents I can run a hundred agents at the same time on my computer. It's fine.
• 19:20
  Brandon: The problem is when the agents actually do something, it's the tool calls.
• 19:25
  Brandon: So what would be nice is what if we just offload the tool calls to another machine to speed it up?
• 19:33
  Christine: Without moving the agents.
• 19:36
  Brandon: Without moving the agents.
• 19:37
  Christine: Cool. What is it?
• 19:39
  Brandon: So, there's this tool called Crabbox so Crabbox was made by Peter Steinberger and the OpenClaw team, that's why it's called Crab.
• 19:53
  Brandon: And it literally does this.
• 19:56
  Brandon: So Crabbox handles pushing your local state over to a remote machine to do expensive work and then bringing that state back to your local machine. And it keeps track of which machines are, like, full of work and queues the work as needed and it does everything that you'd wanna do.
• 20:26
  Brandon: And it's great. I started using it.
• 20:27
  Brandon: It solved this problem that I ran into in my Electron project. And now, I can run my test suite in peace.
• 20:34
  Brandon: It actually runs faster than before.
• 20:36
  Brandon: I'm running it on my DGX Spark.
• 20:38
  Brandon: I have just like little mini computer that's like sitting in my house.
• 20:40
  Brandon: And when I push my test suite to there, I can run more tests in parallel than on my laptop because there's more resources.
• 20:53
  Brandon: And most importantly, my machine doesn't get bombarded with like things exploding, my RAM doesn't fill up. It just solves the problem.
• 21:01
  Christine: Right. Is Crabbox only useful if you have like a DGX Spark at home or could you use old computers or cloud machines for it too?
• 21:10
  Brandon: Yeah. Any old computer you have you can set up, you can spin up cloud machines you can have a cluster.
• 21:17
  Brandon: You can have all your computers, you can mark which ones of them are Mac or Linux.
• 21:21
  Brandon: You can have some jobs that you like prefer to send to Macs. You can have jobs where you don't care.
• 21:26
  Brandon: So all of this is sort of built into Crabbox I think practically there's no limit.
• 21:32
  Brandon: I'm sure like no no human is gonna use more than Peter is. So if it's working for Peter...
• 21:40
  Christine: Do you know how many Peter's using?
• 21:42
  Brandon: No, but probably a hundred plus. This will scale, and it'll also scale across teams, which is cool.
• 21:53
  Brandon: So if you have a team of people working together on something, You can have a pool of machines that are shared amongst people. Like a mix of cloud machines and local machines. Yeah
• 22:11
  Christine: Couldn't I just tell my agent without Crabbox, like, oh here's my if I had one, DGX Spark, use DGX Spark for the tool calls, the tools.
• 22:23
  Brandon: You can. But a good design of this thing is using a mix of Git to like clone the project and rsync which is another like tool for syncing data it's doing stuff over SSH.
• 22:42
  Brandon: You have to keep track of which resources are in use it ends up growing in complexity.
• 22:48
  Brandon: So your agents can build anything, right but there will be little bugs, I think, if you build it yourself so it's nice to use open source tools that a lot of people are using because the bugs will have been ironed out. So.
• 23:06
  Christine: Right. Because if you want to orchestrate the additional execution capacity, like the additional machines, there may be more things than meets the eye.
• 23:19
  Christine: More things to monitor, more things to take into account OK, and Crabbox helps with it.
• 23:27
  Christine: How do you set up Crabbox?
• 23:29
  Brandon: Just install it on all the machines and then tell your agent use Crabbox to offload my tests.
• 23:35
  Brandon: And that's it what will happen is you know your agent will kind of change the way that tests are run or your build is run depending on what you wanna offload so that it, runs things through Crabbox.
• 23:54
  Brandon: And it'll work.
• 23:56
  Christine: So I guess offloading can give you more resources.
• 23:59
  Christine: Are there also any other approaches for minimizing the tool call time outside of the things that you've already mentioned?
• 24:07
  Brandon: Yeah. So the other thing you can do if you wanna keep your build, your tests is you can use or create faster tools that do the same work.
• 24:27
  Christine: Do you have examples?
• 24:27
  Christine: It sounds very high effort.
• 24:34
  Brandon: It requires one extra prompt.
• 24:37
  Brandon: OK, so all these things depend on the tech stack you're using.
• 24:41
  Brandon: But if you're building a web app, that's like the default that people are doing these days.
• 24:45
  Brandon: By default, your agents probably pick ESLint because it's more popular or it's more kind of well-known and established. But Oxlint is way faster, a hundred times faster, as a linting tool.
• 25:00
  Brandon: So you should use Oxlint for example, there's like Bun versus Node.js, there's different React bundlers, so there's all these things if you just add something to your prompt when you're discussing the tech stack with your agent and say hey use the fast tools instead of the slow ones for my lints, my tests, my bundles, whatever
• 25:24
  Christine: This is for JavaScript, but you feel we should prioritize speed over popularity or the size of an ecosystem.
• 25:32
  Brandon: Yeah, I do.
• 25:34
  Brandon: And I think this even extends to there was a very experimental recent work from both Theo and Bun, like within the same week.
• 25:49
  Brandon: They rewrote TypeScript in Rust, and it's like two to five times faster.
• 25:57
  Brandon: And you know what? You should use it.
• 25:59
  Brandon: If it works in your code base, it'll speed up your agents. But like, building a linter is actually not that much work I actually built my own fast linter for Swift, like in February this year.
• 26:11
  Brandon: Basically, the Swift ecosystem doesn't have a robust linting story.
• 26:17
  Brandon: It's just not many people are using it, I guess there hasn't been effort in making a linting ecosystem with a fast lint tool.
• 26:28
  Brandon: And so I was able to just, work with my agent to say, OK, figure out what Oxlint did that sped up JavaScript linting so much, and let's do the same thing for Swift Linting.
• 26:40
  Christine: And what was the performance difference after you built that tool?
• 26:45
  Brandon: So the linter I don't wanna, like, shame existing Swift linters, but I'll just say, like, typical mainstream Swift linters take, like, five to ten seconds on the order of that to like lint, files in your project which is like really unacceptable for linting because it should happen really often.
• 27:09
  Brandon: And my linter works more like a hundred milliseconds. So it's Yeah. So it sounds crazy you know it's something that you would very rarely attempt in the olden days before agents but now it's not crazy to try these things anymore.
• 27:34
  Christine: Especially if that linter or something you could re-use across projects.
• 27:40
  Christine: I assume.
• 27:42
  Brandon: Yeah, I can use it for all my Swift projects now.
• 27:45
  Christine: So, do you have like more examples of things that people could try to speed up the tool call phase?
• 27:52
  Christine: So I guess you could build faster tools, maybe there's ways to increase the performance specifically on your hardware Do you have, like, more examples of things that people could do?
• 28:12
  Brandon: Yeah, I guess that's sort of another I think an interesting point just to like double-click on.
• 28:18
  Brandon: Like you can optimize for your specific machine so like lot of these tools might be optimized for like any arbitrary Mac or Linux machine but you can probably squeeze extra juice out of it if you fork it and optimize it for like my M5 Mac I think anytime you have something slow.
• 28:43
  Brandon: So another good example is like if you have any ML inference in your, in your tool stack.
• 28:53
  Brandon: So for example in our podcast editing workflow we run a transcription step over our audio files. And I took an open source transcription tool and I just told my agent, like, make it fast with MLX and it sped up five X, and that saves real time. So for example kernel optimizations, would also fall under this.
• 29:30
  Christine: How would you decide whether spending time on doing kernel optimizations or rewriting a tool is really worthwhile?
• 29:38
  Brandon: I think tokens are more abundant than ideas.
• 29:41
  Brandon: By that I mean, for many folks if you have any extra tokens you should be using them on these crazy ideas because maybe one out of five of them will work.
• 30:00
  Brandon: Probably one out of five of my crazy ideas work, I would say.
• 30:03
  Christine: Oh, you mean like crazy ideas in general, not like these faster tools.
• 30:10
  Christine: You're not saying like, OK, I build five tools and only one out of five works?
• 30:15
  Christine: Or is that what you mean?
• 30:17
  Brandon: I'd say one out of five of my crazy tooling ideas are working. Something like that.
• 30:24
  Christine: That sounds more effort than what you said, like, OK, just tell the agent one sentence and it'll build it.
• 30:31
  Brandon: It's not quite one. If you're building your own, my fast linter was not a one sentence prompt.
• 30:39
  Brandon: It was like hour session planning with my agents and like coming up with the design and all that.
• 30:45
  Brandon: Yeah. And if you're using a normal mature ecosystem, there's already gonna be fast tools.
• 30:52
  Brandon: And then it's really a one sentence prompt because it's just like, hey, prefer the fast versions of these tools.
• 31:00
  Christine: It's pretty interesting. So if we take a step back and make this actionable, suppose I'm using coding agents and I'm noticing I'm spending a lot of time waiting for feedback.
• 31:12
  Christine: What is a good order to approach the optimizations?
• 31:18
  Brandon: Discover, cull bad tests, parallelize, use fast tools, offload, and then build.
• 31:32
  Christine: Right. That makes sense. I wonder how much, especially the last few steps, are overengineering.
• 31:39
  Christine: When would it be overengineering?
• 31:41
  Christine: I guess if I'm working on a hobby project, maybe it doesn't matter. Maybe we don't need to, like, make it a whole project to create a faster checker.
• 31:51
  Brandon: If you have tokens, you should do it.
• 31:53
  Brandon: Be wild.
• 31:53
  Brandon: Overengineering is dead.
• 31:55
  Brandon: There is no overengineering because your agents work tirelessly.
• 31:59
  Brandon: Any idea you have, you should do.
• 32:02
  Brandon: OK, until you run out of tokens.
• 32:03
  Brandon: And then prioritize them, I guess.
• 32:07
  Christine: OK, thank you, Brandon. This was a fun conversation to have.
• 32:09
  Christine: So, I guess for the listeners, your coding agent might be spending more time verifying code than writing it.
• 32:17
  Christine: So, next time your agent is taking a long time, take a look what it's actually waiting on.
• 32:22
  Christine: And then you might find that the biggest speed improvement has nothing to do with the model that you're using, but it's actually the engineering feedback loop.
• 32:30
  Christine: So, now you have ways to solve that.
• 32:33
  Christine: All right, so we're Superlinear and every week we share emerging practices for building with coding agents. And next week we'll share some other insights with you again that can improve your workflows. See you then.
• 32:46
  Christine: Thanks for listening.