Exploring Coding Efficiency: Utilizing Tmux and Claude Code for AI-Powered Ray Tracing

[00:00:00] Jason Hand: Hey, Scott, how's it going? 

[00:00:01] Scott Gerring: Yeah, good. Thanks, Jason. Good morning, by the way. Good. I didn't say that when we started. 

[00:00:06] Jason Hand: That's right. Yeah. Good afternoons getting into the evening for you. Thanks for thanks for making the time despite our time zone challenges.

[00:00:13] Scott Gerring: Yeah, I'll I'll get stuck into it, but I wanna say the reason I got so enthusiastic about it is because I had been using Cursor for, I dunno, a couple of months now or so, and it's pretty good.

I was very skeptical to start with like most programmers are. But now that there's this kind of agentic thing where you can throw it a whole code base, it goes off and does a elaborate things everywhere. Great. And very productive in lots of cases I found. But I'm not such a big code of graphical editors in particular VS Code. I think it's been great for the community. It's a really complete editor. I just don't like it that much. And when you shared the link to Claude Code, I had a look and I was like, oh, this is a terminal tool. Yeah. This is a bit more something that I would like to be using. So I had to get stuck in.

[00:01:00] Yeah it gets a bit more out of the way, I think, because it doesn't force you to use it in the way the tool is built. like I don't think that these are ultimately gonna end up being.

Entire bespoke environments for coding. I think we have very good coding environments and mostly developers just want to use what they have and are familiar with. Yeah it's all gonna get pretty commoditized at some point and become like a normal developer extension I would expect. So I'm happy that I can use this now in this fashion just as a separate pane in my Tmux where I go and ask questions and make demands of my code base, which I'm pretty fond of.

[00:01:27] Jason Hand: Yeah. And and I guess maybe just for anybody who's not familiar with Tmux, maybe you can give us just a quick explanation of what that tool does. 

[00:01:34] Scott Gerring: Yeah, sure. I'll there's a bit going on in this screen, so I'll make a new one quickly, but the gist of it is that it's a terminal multiplexer. I. And you have this surrounding bits at the bottom of the window you can see.

And at the top of the window, which, I've told it to display, to gimme contextual information like the part of the bottom. Those different tabs are different tabs, unsurprisingly. But the cool thing is that you can split this up anyway you want. So if you want to do something down [00:02:00] here, you can do that.

You can split it again the other way. You can run Claude Code over here. You can basically split everything up and jump around really quickly with your keyboard. And once you get used to it, it's really productive. It's a really good way of working. And you can also detach the whole thing from the terminal you're in.

SSH to other machines or connect back to your machine from other machines and reattach it so you can move the whole session. You have away independent the window it's running, which is very useful in some situations as well. Anyway, if you like terminal tools and you haven't used Tmux before, I thoroughly recommend it.

But so what I've been up to lately, or should I explain a little bit the different ways I use, I've been using Claude Code initially, or should I just jump in with this fairly interesting one? I think, 

[00:02:45] Jason Hand: I think that there's two, yeah, there's definitely multiple things here that you've got going on that are interesting.

One Claude Code running here. Know, in this multiplexer is the first time I'd ever seen anybody do that. And I don't, it just, it makes perfect sense. I just don't I don't use [00:03:00] Tmux, I use, all the tools that you've been talking about lately. Or I just go into terminal and just run Claude Code straight.

Yeah. So I thought that's, that was interesting. But definitely the Ray tracer, once I learned like what it is that you're actually, you're building, I thought that was fascinating too. So I'd love to hear a little bit about. Yeah, 

[00:03:17] Scott Gerring: I'll so the way I've got it split up here first initially to the, the Tmux point I would say is fairly typical if you're used to coding in the terminal, apart from the Claude Code bit, obviously, which is new.

I have a normal console over here, so I can go and run, this is a Rust project, so I can run cargo build, I can run cargo test, I can do all the kind of like interactive stuff. That I would typically do on a terminal. I tend to keep one of those around. I have Claude Code up here so I can ask it a little bit about the project, interact with the project, and in this case, I have not touched any of the lines of code of this at all.

This has been an experiment in what can I get out just by guiding it with prompt engineering. And then over here I have Helix, which is my, my terminal based text editor of choice. This is another one of those things. [00:04:00] If you use Vim and you like Vim, try Helix, it's really good. And it's based on Rust, which means it's also very snappy, but it's a great editor for things like Rust because it has good built-in language service, support and what have you.

Anyway, that's the high level overview of the three panes we have here.

And what I've done in this particular case is see how far I can push Claude Code with building something that's fairly complicated without ever touching the code Myself and I picked a ray tracer, 'cause it's been a habit of mine when learning new programming languages for a while now, to build a basic one because it's.

You get cool output. Basically you get pretty pictures of things, spheres, teapots, and whatnot. So you feel a sense of satisfaction when you get it to work. And it's also interesting, both in an algorithmic sense, like the algorithms are well known and well documented, but they're chunky enough that you have to use the programming language a little bit and also a data structure sense.

And again, there's enough complexity there that you're building something that's a bit more meaningful than a hello world [00:05:00] or right. Hello, world rest API or whatnot. So you get a feeling for the way the language is 

[00:05:04] **Jason Hand:** structured. So you've got this baseline like project that you use every single time.

Is it a set of instructions for the project or do you have code that you've like just developed over, over the years and you use as like the baseline? Like how does it look? 

[00:05:19] **Scott Gerring:** So when I do it without the generative ai, which is the way I've done it every other time, I just try and remember how I did it last time.

Ah, the main thing was you need a camera, you need some stuff that you can cast, rays at, you need some model for surfaces, ah, remember now. And then I build out from there, up from the foundational primitives. And this is also what I've tried to do a little bit with Claude Code and I, I, I had a bit of a trick here.

I told it at the very beginning. That whenever we have a conversation or like whenever we have an interaction, it should go and update this Log MD file. And it worked for a while, but it stopped working after a while. And I wonder if that's because the context window got too full. Ah, [00:06:00] 

[00:06:00] **Jason Hand:** how? How large is this log?

[00:06:02] **Scott Gerring:** Yeah, let's have a look. 382 lines. And there was a lot more conversation than that. Yeah. A couple of times while I've been using it, I've noticed it stopped writing to the log, and then I've reminded it again to go and reread claude.md. And it started doing it again for a while, but it's not consistent.

I ultimately feel like it's a bit of a clutch because the tool itself, the Claude CLI could do this if it wanted, and there's an open feature request on GitHub for it. 

[00:06:24] **Jason Hand:** Okay. 

[00:06:25] **Scott Gerring:** But you can it's interesting because you can see what I've demanded of it. Like I, I set the base, I say we're gonna make a ray tracer.

I start giving it kind of high level overview of what I want. I want you to do it with Rust. You're going to use. These libraries to do so like the standard command line passer, this is the normal library you would use to do parallel processing, which is very useful for Ray traces 'cause they take a very long time to run.

Stuff like that. And then I got a bit further into it and said, all right, there's different sorts of ray traces. What do you know about them? And it gives me a summary of [00:07:00] them. And then I pick one that's reasonably complicated. Which is ultimately one that supports bidirectional reflectance distribution functions, which is like a complex way of modeling surfaces, but it's, again, I've picked it intentionally because I know that it's a bit harder than just doing a simple ray tracer, and I wanted to see how I would go with that. 

[00:07:18] **Jason Hand:** Yeah. Okay.

[00:07:20] **Scott Gerring:** And as it kicks along, I've got it to update this claude.md file itself. Okay, we've had this discussion about what I want you to build and the constraints of how I want you to build it. Go and write that down let's see if we're aligned on this thing. And it's done reasonably well.

Like we have all the core technical decisions here. Like it's gonna run parallel, we're gonna do Monte Carlo integration. This is another one.

I push it in the direction that I wanted it to be shaped rather than just letting it do whatever. 'cause I thought it would go a long way and then end up being useless. Things that I thought it would get wrong, like the coordinate system will always be shaped this way so that it didn't, do strange things where some was one way and some was left-handed, and rah.

But things that I think [00:08:00] matter. As kind of foundational decisions for array tracer, more or less. And I'm not an expert here, right? If anyone comes and listens and says, this is all madness, maybe it is. But it's served me reasonably well up to now.

And from that point on, that kind of the next big thing was like we had this technical foundation.

What are the logical steps to implement it? And because I wanted this to go as, as the kids call it, fairly "YOLO Mode", where you just let it rip for a while and then you come back and say yeah, it's okay, or not. I went with really coarse-grained steps. You'll build the foundational project, you'll build camera abstractions, you'll build a way to load scene files.

You'll do integration and so on. And made it right unit test as it kicked along and looked at the outputs and said, yeah, this looks pretty sensible. And by the time we got down around here, it was actually working quite well. It's not the fastest thing in the world, but it's functional. And if you look at the structure of the code, it's roughly what I've seen as how other people [00:09:00] tend to structure simple ray traces

It's not as horrible as I was expecting, I would say for something that's quite a chunky code base Now, 

[00:09:08] **Jason Hand:** do you think it would have gone through that basically its own checklist that would've been similar if left to its own devices? 

[00:09:16] **Scott Gerring:** I'm not sure. I think that it would've confused itself with different implicit decisions at local points.

So super concretely. You, one of the points I made was about the way I wanted it to do the coordinate system, like right hand coordinate system or whatnot, like X axis points in this direction, and rah. You have to constantly make decisions based on that over and over again. As you go through more or less, like when you do different parts of the intersection code and whatnot, you have to have the same thing in mind.

I think if you don't spell it out explicitly, it's just gonna do something. And some of the time it will line up with the way it's done at somewhere else and some not. So in that case, I [00:10:00] think it's important. I don't know how it would divide it up by itself. I've noticed that in Claude Code now, it often generates itself an intermediate.

To-do list as it goes through. Yeah. And it checks those off as it goes through the steps, but the scope of the whole thing here is so long that, I dunno that you would get it to do it all in one prompt. But when I was doing, say one of these, you would see that it would create a submodel of what it had to do and tick itself off as it went along.

That was a very rambly answer. I'm not sure if I answered your question. 

[00:10:27] **Jason Hand:** Yeah, you got it. 

[00:10:30] **Scott Gerring:** But it's worked pretty well. I'll show you what it output. It's not super spectacular, but it's very functional. I'm gonna have to zoom over to another screen and I'm gonna lose you. So tell me if you can still see 

[00:10:41] **Jason Hand:** can, yeah, I see colored browser window.

Yeah. 

[00:10:45] **Scott Gerring:** Okay. And you can see a finder window, I hope. Yep. Cool. So there's a different, a couple of different scenes it supports. Here's one I showed you earlier and you said that looks very, very nineties, I think. Yeah, but it's. Sorry. 

[00:10:59] **Jason Hand:** Yeah. [00:11:00] Vintage nineties. I'm trying to think. There was like, this technically probably was like a ray tracing PC application that became popular.

Like Blender or something? 

[00:11:10] **Scott Gerring:** Perhaps. 

[00:11:10] **Jason Hand:** Way before Blender. Oh, really? Yeah. I'm thinking back in like the late nineties. I'll have to look it up, but it reminds me of stuff that Yeah. That thing would output. 

[00:11:17] **Scott Gerring:** It's interesting because you look at it and you see the noise and you say, oh, it's a bit noisy.

But that's what Ray Trace images tend to look at because you're always making these decisions about where you should randomly cast the next ray based on when you hit a point. You don't just bounce it straight off and go towards the light or whatnot, you, there's always some probability it goes in some crazy direction.

And that 

means that to render a scene accurately, you just cast more and more rays and effectively average them together. But because you want it to finish at some point you put an upper bound on that. And the upshot of that is that they start very noisy and they converge on something.

But that noise and the way that the reflection off of the light looks and the kind of shadowing, the soft shadowing from the ground, like it's it's pretty typical. It's done reasonably well there. [00:12:00] We have. What else do I have? That's interesting. Of course we have a teapot. It's important to have a teapot.

Absolutely. In this case, it's a bit more wild. I'm not really sure what's happening under the teapot on the plane. I think there's some reflection and some occlusion of the lighting, but I. It's done. The teapot loading itself, I've given them an object file and it's passed it and loaded and everything.

And again, it's like approximately what you would expect. 

[00:12:23] **Jason Hand:** And 

[00:12:23] **Scott Gerring:** I haven't looked at the code for this. I've just let it rip and judge the output and told it what I would like it to change. I have a very noisy teapot too, but that's not so interesting. 

And the other thing I did, which I'll point out really quickly while we're here, is make it.

Reflect on its coverage of the own code base to decide where it should be writing tests. And the reason I did that really explicitly is because you've probably seen it as well, they often tend to go off and make crazy adjacent changes to things that you don't ask for. 

[00:12:55] **Jason Hand:** And 

[00:12:56] **Scott Gerring:** without good test coverage, you have no idea that's happened.

It takes so long to run the [00:13:00] renderer to get an image out. You can't always check every output by running the whole thing through. So I want a decent test coverage. 

[00:13:05] **Jason Hand:** Wow. This is great. I've never seen anybody do this. 

[00:13:08] **Scott Gerring:** Yeah, just I try and put as many things in the way of it doing terrible stuff that I don't notice as possible, basically.

So 

[00:13:15] **Jason Hand:** do you keep this up like in another part of your screen to just keep an eye on it all the time? No I 

[00:13:20] **Scott Gerring:** tell it to, I tell it to follow it. So if we go back over here, so whenever you add tests, go and check the coverage again. I haven't told her to do coverage on every. Build or every change because it takes a while to rerun the coverage.

'cause the tests are doing a little bit of rendering in them. But whenever it, I go through with my version control system and see how much it's touched Every time I let it touch something. And if it's touched a lot more than I think it should have, then I say, go check the coverage again. Go check the unit test.

Have you broken something? 

[00:13:51] **Jason Hand:** And does it feel you know how like everybody forever has been talking about shifting left? Now I feel like we're shifting back to the right, like the human in the loop part [00:14:00] is the other direction that we've been trying to tell people to go. Like now we're all the way at the end again, the yeah, it's definitely, 

[00:14:09] **Scott Gerring:** It's such a strange interaction loop doing this stuff.

I find, I think there's a big part of shift left in it though, in the sense that. You want to use more of these tools that convince you that the thing it's produced isn't bad. So like more static analysis? More tests, more coverage. 

Because ultimately you're trying to use it in a way where you don't have to put too much scrutiny on the code, right?

Like you want it to produce, or at least in this case, I just want it to produce heaps of code and to roughly work. To convince myself that it's roughly working. You can use all these other nice kind of shift lefty tools to try and keep an eye on what's come out without having to review and understand all of the lines of code.

To be clear, I think the way I've built this is not the way to build a serious production system, but it's an a fun exploration of what you can get away with absolutely no hands on the [00:15:00] steering wheel and a bit of enthusiasm and time.

[00:15:03] **Jason Hand:** Yeah, and I think what a lot of people are realizing is that with.

Things like the Claude.md file and even your logs file, but just having a a form of. Context, right? So that we always hear that all these models are best if they know all the context, but if we're upfront about what we want, what the guardrails are, it lets us build a little bit more trust with them, with the models and what they're doing because they do output higher quality stuff, more complex things like what you've done here, however.

As you pointed out, we've also recognized that they still get to a point where you can't just like "YOLO" and completely walk away. You do have to check in on it every once in a while. 'cause despite giving it clear instructions, it still seems to run into a another problem somewhere where it just can't keep up with that.

[00:15:53] **Scott Gerring:** Yeah. And often I think it's. So I should preface this by saying I don't know [00:16:00] a lot about generative ai. Like I'm a programmer, my focus is on programming, and I've just, I use the tools that come to me, but it seems like they often do things to try and make you happy, even if they don't have confidence that it's good.

They always kinda want to take positive action rather than just throwing their hands in the air and saying, I'm not sure about that. And in some cases you get really fun. Effects of that in the output code. And there, there's there's a really common pattern that I've seen a lot with Rust code bases, which I spend a lot of time on lately, which is you have some borrow checking issue.

The borrow checker is this famous thing and Rust that makes it so that you don't. Have to work with mallock style C memory, but you still get fast performance. But every now and again, you get these crazy compiler warnings that are saying You have done the bad thing, fix the bad thing. And often it's not super clear how to fix the bad thing if you go and let Claude Code rip on those sometimes.

It fixes them. But if it's at the point where you probably couldn't have fixed it [00:17:00] yourself, 'cause it's a bit convoluted for whatever reason, it will do terrible things to try and make the compiler happy, but almost certainly not what you want. There's like an escape hatch where you can say, this memory lives for the entire life cycle of the program, which you almost certainly never want to use.

[00:17:14] **Jason Hand:** Yeah, 

[00:17:14] **Scott Gerring:** and it'll just grab it all the time and be like, yeah, I put static on it, you're good. And you're like, no, this is not what I want. Please undo that and I'll actually think about it now. Thank you. But once you start to recognize that and realize in these cases, probably it's not the hammer to reach for, I think it's fine.

[00:17:30] **Jason Hand:** Yeah. There's so many times where I've found myself speaking to it like a, like it's a toddler. It's no, that's, I just told you not to do that. 

[00:17:40] **Scott Gerring:** Yeah. And I get angry with them and I've, then I feel really strange about it. Afterwards, I'll put on the caps lock and I'll be like, "NO! THIS IS WRONG!".

"This isn't what I said". And then you see it reflecting on what you've said, and it says. "The user is emphatically telling me he is not happy with this outcome. I better think again", you're like, yeah, this is, I feel a bit bad about it now, but Yes. 

[00:17:59] **Jason Hand:** Yeah, I don't know if [00:18:00] bullying the AI is the right move, man.

[00:18:02] **Scott Gerring:** No, I'm on a list now and so you probably, but we can just hope the complex window isn't too large.

[00:18:08] **Jason Hand:** So what's next? Before we, we run out of time here and wrap up. What's what whatcha gonna explore now? 

[00:18:15] **Scott Gerring:** I wanna keep pulling on this one because it's cool and I wanna see if I can make it do more complicated things, but I also feel this tension where ultimately I'm just spending a lot of energy on something that's not solving a real business problem.

That's a bit awkward. You're learning, sorry, 

[00:18:30] **Jason Hand:** You're learning, about these tools. I think that's the big takeaway from, for me on a lot of these things is just staying, aware of how these things work to the best I can to be able to have conversations with folks.

[00:18:42] **Scott Gerring:** Yeah. But I use it much more seriously as well, in day-to-day work here. 

Yesterday, for instance, I, we have all this data internally in our analytics database, right? I know that you're always hunting for fun facts in there. I thought I would start learning about that and I found this GitHub repository that we have that has all [00:19:00] the different schemas in it, but there's so many files.

GitHub won't even list them all in the ui it just says there are too many files. So I checked the whole thing out. Chucked Claude at it and I won't share this 'cause I think it's an internal thing, obviously. And made it generate a Claude index for it. And then just started asking questions about the particular data set I was looking for, which in this case was APM related, like how can I figure out what services I'm running and how they relate to other services, stuff like that.

That's super effective and that saved me a lot of time. Yeah, because you guess a little bit like, oh, I probably wanna look in this file, and you read the schema a bit and then you compare it to something else and two hours have passed at the end and you have this really vague model of this tiny corner of this massive code base.

[00:19:41] **Jason Hand:** Yeah. 

[00:19:42] **Scott Gerring:** The, there's no more effective tool than things like Claude Code for that now. I think it's it's quite impressive there. 

[00:19:49] **Jason Hand:** Yeah. Once the code base is indexed it is pretty nice to just be able to find something. I used to look around a lot easier, 

[00:19:56] **Scott Gerring:** and you move beyond like crazy grep expressions where you're like, yeah, it's [00:20:00] probably called this.

Or maybe that just would like all the awe characters in the middle, and then you try and decode the rubbish that comes back. I find that really useful. And for more normal code bases. I mean with this ray tracing thing. I'm being a bit silly, right? But I've actively chosen that direction.

'cause I thought it would tell me something interesting about the tools, more or less. 

But it, it's indispensable for everyday programming. Now there's lots of stuff where it's more than just, go and render this template. Go and do this basic co-generation. There's a bit of nuance to it.

But there's not so much nuance to it that it can't be done mechanically. You just traditionally have to go through it yourself. And like an example I had yesterday was I am building a service with James. For some stuff for a demo we're building, but it has a database schema or an API schema, some internal models, and you can start with any one of them and with your brain, with very little energy produce the other ones.

But you're probably gonna have to go and do a bunch of fiddling in your editor and that. And Claude Code and Cursor are ridiculous of that. You just pointed at [00:21:00] one and say, Hey, I want you to go and build the RRM backend for this use Postgres. Use the current Java annotations write some unit tests.

It thinks for 10 minutes it comes back. You look at it like, that's perfect. Thanks. I was having a coffee while you did that. 

[00:21:14] **Jason Hand:** Yeah, it's exactly stuff that's we never maybe thought of it as boilerplate, but I know that the way I would manually go do it is there's a set, there's a set way. I'm gonna go do it and it's fine.

I know how to do it. I just don't have the time or I don't wanna make the time to do it, even though I know I need it. That's where these tools come in. 

[00:21:31] **Scott Gerring:** Yeah, exactly. It's it is boilerplate, but it's just like a tiny bit more complicated than just find and replace from a string. And that's enough that the human has to be involved otherwise no more.

[00:21:41] **Jason Hand:** Yeah. Yeah. Don't have to. You can, if you enjoy doing it, if you wanna make very artisanal Rust code or whatever your favorite flavor of language is. Okay. Scott, I appreciate you showing us your terminal setup with Tmux and Claude Code. And [00:22:00] what was the editor that you said?

[00:22:01] **Scott Gerring:** Helix. 

[00:22:02] **Jason Hand:** Helix. I feel like 

[00:22:03] **Scott Gerring:** I should have a prepared advertising statement for Helix, because I often tell people they should use Helix, but Helix is amazing. Check out Helix. 

[00:22:10] **Jason Hand:** Okay. Cool. Thanks for showing us your setup and walking us through your ray tracing project and some of the other observations that you found as you explored Claude Code.

And let us know if you find anything else as you continue to look around and love to chat more about it. 

[00:22:25] **Scott Gerring:** No worries. The next time you find another exciting terminal base tool, feel free to ping me.

[00:22:30] **Jason Hand:** I absolutely will. All right thank you and we will see you on the next one later. Have a good 

[00:22:35] **Scott Gerring:** one.

See.