Rails After the Robots: Chad Fowler on AI as the Next Abstraction

Valentino Stoll (00:01)
Hey everybody, welcome to another episode of the Ruby AI podcast. I'm your host today, Valentino Stoll, and joined by co-host Joe Leo. And we have an incredibly special guest today, ⁓ Mr. Chad Fowler. I really appreciate you coming on. It was just one of those blind reaching out to you we had never met before, but I ⁓ was at RailsConf and I heard you talking about

Joe Leo (00:10)
Hey everybody.

Valentino Stoll (00:31)
how you feel about all of these AI changes ⁓ with respect to rails. And ⁓ I found it really compelling. And so I would love to hear your opinions on so many things here. ⁓ do you wanna intro? Yeah.

Chad (00:46)
Sure. I want to hear yours too. Let's argue a little bit too, hopefully.

Joe Leo (00:50)
know, Valentino

is actually, he's being nice and I appreciate that he is, you know, he's completing the gambit, which is to get you on here under the auspices of talking.

but that's not true. I actually, I specifically wanted you to come on the show so that I could talk to you about February 2013 when you left the Ruby world as I knew it and the country to go work on a startup and write it in cappuccino. And I would like you to explain that please. Yeah, exactly.

Valentino Stoll (01:18)
I'd to explain that.

Chad (01:20)
In cappuccino?

What is cappuccino? ⁓

So I think you're talking about when I went to Wunderlist. I actually... What is cappuccino? Is that a thing we use? Oh, yes. Okay, right, right, right. Yeah. You know, it's funny. I did leave the Ruby world then. So like, you we were talking about our mutual friend, David Allen Black, Ruby Luminary. And right before we started this, and I said I hadn't seen him since RailsConf 2012. That's because the last time I went to RailsConf was 2012.

Joe Leo (01:30)
I am, yeah. That's the Objective C.

Hahaha

Mm-hmm.

Chad (01:54)
Right after that, I left the country. I went to Germany. I worked on this thing called wonder list and they hired me because I was a Ruby person and they had done this big rewrite and done a backend in Ruby. And the first thing I did was start talking about tearing up the Ruby thing and replacing it with other languages, which I think was, you know, much to their chagrin. Like, great. We got this crazy guy. We moved him from the U S and now he wants to use Gala of all things. But it is true. I did. Yeah. I totally did that.

Joe Leo (02:22)
Yep.

Chad (02:25)
Actually, I think we'll probably end up getting back to that at some point, so I won't go too much into it. But ⁓ the reason I did that was actually largely architectural. And it's when I was forming some of the biases that lead to how I'm AI today and generative code specifically. Not to bring it back to AI, we can go wherever.

Joe Leo (02:44)
Yeah, I definitely want to get into it. Yeah, no, I definitely

want to get into it. I mean, it was such a conflicting moment for me. I know I'm dating myself, but you know, there were all these people who started writing Scala ⁓ at or around that time because it's like, look at what Chad is doing and look at this cool thing. Because obviously, if you don't know the story of Wunderlist, was an incredible success sold to Microsoft. You then had several positions at Microsoft. Obviously, the re-architecture was a good idea. ⁓ But of course, me as a Rubyist at that time, I was like, wait.

wait, Chad's doing something else. Why? Why? And of course, know, I, you I got, you know, go, you get older and you make different decisions. did other languages as well. ⁓ So I'll be interested to hear, you know, the kind of architectural underpinnings behind that.

Chad (03:15)
Thank

Yeah, sure. ⁓ You know, it's funny, you were talking about that feeling of like, no, I'm doing Ruby and I'm seeing people going away from Ruby now. I started being paranoid about that in 2007, I think. And I say that date specifically because one of my first ever conference keynotes was at Mountain West Ruby Conference and it was about how like,

There was this big craze around Ruby and Rails at the time and we all felt like we were at the top of the world because we got lucky and we were in this tech that everyone was using. It's kind of like investing in a company that is very early and then getting lucky. ⁓ And it won't be long before we're all old people wishing that we had learned something else. So how do we avoid getting stuck in this thing?

Joe Leo (04:03)
Yeah.

Valentino Stoll (04:13)
You

Chad (04:13)
And so that is actually one of the reasons that I stopped doing Ruby when I did because it felt too good to do Ruby, ironically. And I knew I could get stuck there. I didn't want to get stuck.

Joe Leo (04:21)
It's interesting.

Yeah, I can understand that. But I also had that same feeling ⁓ right around that time, but I was much earlier on in my Ruby writing career, but I was like, man, can we actually keep this thing going? And I think your ⁓ analogy to a startup you invested in, I think is a really good one. Go ahead, Vy.

Valentino Stoll (04:27)
I'm.

I just

double checked and isrubydead.com says no. ⁓

Chad (04:51)
⁓

Joe Leo (04:51)
You

Chad (04:54)
Now I've got to load it. There is an Israelian.

Nice. ⁓ hey, I know that guy.

Valentino Stoll (05:03)
Yeah, you know, I have so many questions for you. ⁓ I mean, especially around, you know, all of this AI stuff is very Python central, or what now is TypeScript central in some ways. ⁓ And there's so much value, I think, from the Ruby language in this particular space, as far as transformers go and natural language processing, ⁓ that I think...

to be honest makes Ruby well positioned to work better in a lot of ways ⁓ for these transformers specifically. ⁓ I'm curious what your opinions are kind of with language specifics around all this stuff like is that something that you think about even or is it all abstractions at this point?

Chad (05:53)
think about that a lot, ⁓ partially because being a nerd, of course, I want to be one of the people who figures out how to do it. ⁓ The Python thing is really irritating. It's irritating as a Rubyist, of course, because there really is no reason to be both a Python program and a Ruby programmer, unless it's just like you want to use one of the libraries from one of them or something, because they fill the same hole. ⁓

Joe Leo (06:21)
You

Chad (06:23)
But I mean, just the very basic fact that a language that's whitespace sensitive in an era where everyone's copying and pasting is just really stupid. And I hope everyone involved in that decision, which might just be Guido. Maybe he's not even experiencing this now, but in retrospect, it's a mistake.

Joe Leo (06:32)
You

Chad (06:42)
And even at the time, it felt like a mistake. So, ugh, gross Python. Just for that reason. That said, I don't know that I... So I want to hear your perspective on how Ruby is better for transformers. I will tell you first, since you asked me, that the way I think about it is like, I think probably it would make sense to even have a language that's geared toward ⁓ generative AI, generative code. ⁓

My first hunch was that something like Haskell would be perfect for this. Because with Haskell, I used to joke we had Haskell stuff at Wunderlist, and I would say with the Haskell stuff, if it compiles, it works. Because the type system is so rich, and you can embody so much in the type system that it's beyond just syntax and grammar, it's semantics that get baked into these things. Ruby doesn't have that, and Python doesn't have that.

⁓ TypeScript sort of does, so if we are shifting toward TypeScript out of Python as being like the default thing that these LLMs vomit up, then great. Because now, in a way that I used to argue against when dynamic languages were becoming the rage in the early 2000s, ⁓

The programmers we're talking about now actually are stupid. They're LLMs. ⁓ Dave Thomas of Pragmatic Bookshelf and Pragmatic Programmer, he used to say that Java is the Duplo block of programming. You're trying to protect the dumb programmers for themselves by putting all these things in place. ⁓ Joe Armstrong actually even told me once about ⁓ the Erling system. ⁓

Valentino Stoll (08:15)
Right.

Joe Leo (08:15)
Right.

Chad (08:23)
What is the Erlang system, the framework? Is it called OTP? Yeah. So we were talking about OTP and he's like, I don't use that. We built that for bad programmers to use. And he would never, he would literally not use OTP. He would always code everything on his own. He's one of the inventors of Erlang, just for context, if people don't know, most Ruby people seem to know Erlang. ⁓ So my point is like guardrails actually matter more than they used to.

Joe Leo (08:32)
That's really funny.

Chad (08:53)
or at least more than I used to argue that they used to. There were people that never moved on from that. the programmers are pretty dumb, the LLMs. They're good at spitting out lots of stuff. So there's language-specific stuff like that. think I've done some research into ⁓ formal verification and languages for that for doing specifications, TLA plus and... ⁓

There's another one called Quint that's new and open source and looks more like Ruby and JavaScript. It's really nice. I feel like there's a place for those sorts of tools. And then ironically, things like ontologies to describe domains in some sort of codified language, like OWL was the thing from the semantic web, ontological web language. I think it's these sorts of things that come together that can...

Valentino Stoll (09:30)
Yep.

Chad (09:48)
create and document constraints in a computer checkable way that become more valuable usually than very specific language features. then, you know, so the, like...

The problem is I think it would be great if there were languages built for LLMs to use, because I think they'd make things better. However, you also have the whole other side of reality, which is LLMs work by indexing the internet, which means the best thing that you could do is use something that everyone else used two years ago or before, right? The best documented things are the best ones. Or here's something in the favor of Rails, not necessarily Ruby, languages that have

Valentino Stoll (10:06)
Yeah.

You

Chad (10:30)
very strong conventions or frameworks have very strong conventions. That's a great thing about Rails. Rails is an architecture more than a framework. It's an architecture embodied in Ruby and you can and people have completely embodied that in other languages. so ⁓ the things that reduce... ⁓

decisions that a human would need to make that are not of value are also good for LLMs because you also want to reduce places for them to make mistakes, places for the context window to grow so they become more stupid as they go. Anyway, this was like a totally unhinged babbling session. Why do you think, ⁓ Valentino, that Ruby is better for transformers? What's the argument there?

Valentino Stoll (11:17)
I mean, more specifically, I guess, is the training data. Right now, things are mostly like, like you said, it's great from the internet, but a lot of it is pure textual. I would say a very small portion of the training data is actually code in a lot of ways, especially for the larger ones, models that everybody uses the code, Is that, you know.

in perspective to the amount of data that they're actually scraping and training and preparing. ⁓ You know, the amount of code is very small. And so what you end up with is something more desirable is aligning your inputs to be more textual and more English reading and sentence structure and things like that matter more than how the code is specifically formatted or parameters and things like that is how I imagine, you know,

This is all hearsay. I don't have any empirical data to support any of this that I'm talking about. But this is just like from what I've been reading about it, know, transformers over the years and following the patterns and training data that they, you know, at least are admitting to. You know, this is kind of where I'm thinking is the more you can get something to look like actual sentences and structures and reporting and things like that, the better your outputs end up being.

And I think a lot of this can be ⁓ proven simply by Markdown. Markdown is an incredibly well-performing format, ⁓ even compared to JSON as an example, which is what a lot of people use, but it doesn't perform as good. And I think that leads into a lot of just how transformers work. And when you get a lot of these superfluous tokens of hash signs or like...

begin end and maybe some of the stuff that doesn't make sense in a sentence, you know, for Ruby's case, like those begin ends maybe make it less desirable. But when you get ones where there's like curly brackets and lots of semi-colons and even, you know, like lots of this extra tokens, it doesn't really align as well. And then unless the model is like heavily trained in that specific language, you end up getting, you know, kind of blended results where it's...

Chad (13:17)
Thank

Valentino Stoll (13:40)
Okay, it has to assume that you're using this language and then based on that language it gets into a different layer and then tries to like have to reason internally about how to align those layers and chains through everything right and so My perspective is that you know Ruby is very ⁓ Easy to read and it is more like language specific from a grammar standpoint And so if you can align your code, which I think

Rubyists do kind of best practices of trying to make it more legible, right? And even from an abstraction standpoint, it's like very practiced at trying to make your abstractions work well from a readability standpoint. And so like the more readable your code is, really people say that's the better Ruby. And I tend to agree with that. But.

Chad (14:23)
Thank

That's interesting.

It's also another take on the raising of abstraction where Rubius will, like, create a DSL for something that doesn't need a DSL. ⁓

Valentino Stoll (14:39)
Yeah.

Right. Yep.

Chad (14:40)
And I don't mean that in a negative way. It's stylistically what happens.

Because we all fell in love with this idea of being able to raise the level of abstraction to where it's almost like human language, to the point where we did a bunch of stupid things, too, in the past. Weird chained sentence structures just because you can do it, because the result of every call is some sort of value that you can chain on and overload and blah, blah.

Valentino Stoll (14:58)
Right?

Chad (15:06)
And that's an interesting one because those are really bad for people. they're good for the reader and not good for anyone who needs to write it or modify it. But that might not be true for LLMs. Yeah. I hadn't thought about that.

Valentino Stoll (15:18)
Right. Yeah, I mean,

this is all just assumptions. ⁓ There's definitely more like, you know, training data on the models for code, for all of the code that these model producers adhere to, right? And that's clear, ⁓ which in some cases may be why ⁓ something like ⁓ Scala or Rust or something like that, ⁓ maybe Rust is a bad example. I heard it doesn't perform very well. ⁓

But, ⁓ you know, I don't know. I feel like there's just a lot of opportunity for Ruby to really dig in to the current state at least. But I definitely want to hear more about your idea of abstractions because I feel like that's something, you know, I was hoping like, you know, the WebAssembly application of like language, like you're mentioning some kind of specification that converts to something that is LLM performant, right?

Chad (15:57)
Mm-hmm.

Mm-hmm.

Valentino Stoll (16:16)
Where

like maybe there's like some kind of WebAssembly version of cross-language compilation into some kind of spec that then the LLMs understand universally. ⁓ You know, that's something I think about too. Like, but these are all hypotheticals, right? Like, is anybody working on this stuff? Like, I haven't seen it. You know, maybe you have, I don't know.

Chad (16:36)
Yeah.

I've talked to a lot of people doing code-gen related stuff, yeah. And my sense is that probably they don't live in LLMs, ultimately these models. Parts do and parts don't, you know? But they're like MCP calls into things that have better graph-oriented structures behind them or whatever.

Though don't know. I don't know if the LLMs care about this sort of uniform thing either. Like one lesson I've learned from talking to founders as an investor now is sometimes I'll ask people, know, like, well, what's the shape of this API and how do you get these two things to talk to each other? Like, it's a prompt actually. You know, at this point, we don't even need to think about that anymore. And, you know, for the small, for small enough problems, that's fine. It actually works today where you can tolerate some error. But you were asking about abstractions. ⁓

Valentino Stoll (17:17)
you

Chad (17:28)
You know, I remember when Rails came along. Well, I remember when Ruby came along, in fact. you know, before that...

There was a time in my programming life where I really thought in terms of the program counter, basically. When I learned basic, it's 10, print hello world, 20, go to 10. It's literally about the steps that the program is following. Store this thing in here and then print it here. ⁓ Or assembly was even lower level than that, of course. Every time we've seen a major level of abstraction get raised in programming, there's a community.

of people that are absolutely terrified, angry, think it's stupid, not gonna work, whether it's compilers or even assemblers or the JVM or Ruby as a high level language with dynamic typing as opposed to using Java or C at the time, where everyone's like, well, it's gonna go crazy, you're not gonna know what any of these values are, and it's not gonna work, and it's gonna perform terribly. Well, that ended up being false.

Valentino Stoll (18:34)
You

Chad (18:34)
Rails comes along and says, you know what, you don't need to spend several days figuring out the project structure of this web app because none of these are valuable questions to even answer. So just get past that by typing one command and we're done with how to set up the test framework, which one to use, what directories things go into, how you do routing, all this stuff is just answered for you. That is the miracle of Rails sitting on top of the miracle of Ruby at the time.

It's all about convention over configuration and being opinionated. So you look at active record, you know, that looks insane to a person in the year 2004. Someone who spends all day working on database stuff, they look at that and think that is never going to work. It sounds like a fun trick, but it's never going to work.

Joe Leo (19:08)
Yes, I agree.

Chad (19:27)
It worked, it works. Of course, there are all sorts of corners and you end up fixing them. And for a while, there's a job, and there still is, but for a while there was really a job for people to figure out how to get something like ActiveWit Record to work without destroying your database when you start getting people hitting it. Because the first thing that you do is N plus one problems. There were so many things that were just like, by default, you were going to screw up.

No longer the case though, and no one expects to start a job on a software project now and type SQL all day, right? It just doesn't happen. Someone has to do it sometimes if you're lucky. And I say if you're lucky because it means you have a performance problem because people are using your app, right? So if you're lucky, you get to do that. It's not everyone on the team.

So I'm looking at these LLMs like this. And I know there will be people who disagree because it's not deterministic and blah, blah, blah. There's all sorts of arguments. But it's just a continuation of the same thing we've been doing the entire time we've been in this very still nascent industry, is raising the level of abstraction to a point where we can ignore the things underneath it. So I think there's soon a time, very, very soon, I think we should stop saying the phrase vibe coding unless it's a pejorative, actually.

because vibe coding implies people who don't know what they're doing just like letting the thing go, right? There's a time pretty soon where people like us that have spent our entire careers understanding exactly what's happening also ignore what the thing develops as long as it's doing the thing we want, it's creating the thing we want in the same way that I have not recently read the source code to any of MRI to see what happens when I call a function with a certain type of argument because I don't care. Ruby's doing it.

That's Ruby's job, not my job.

Joe Leo (21:13)
Well, so this is an interesting

point here because you've hit on something with Rails, the convention over configuration concept or feature. What it does is it eliminates cognitive load, right? I no longer have to think about how I'm going to group my models, my views controllers. I no longer have to think about routing, right? There were a lot of things. Soon after that, got things like Heroku.

And then all of a sudden we didn't have to spend two weeks figuring out how we're going to deploy this thing that we had built to the web. And we can do it overnight, and we can do it in an hour. So if that is an abstraction, both of those are abstractions that reduces cognitive load so that we can work on presumably higher order or more creative problems, then what is the cognitive load that gets reduced with the introduction of AI as an abstraction?

Chad (22:10)
⁓ Eventually, think it's okay. I'll tell you a story instead of answer the question real quick, but it will be in service of it. It's a short story. Right after Rails was released, there's a guy named Glenn Vanderberg that all the Ruby people used to know. I'm not sure if they still do because he also left around the time I did and I think you can a closer, but.

Joe Leo (22:29)
I

remember vaguely. ⁓

Chad (22:32)
He did a bunch of great talks at Rails comps and stuff. He's a really good thinker in architecture. He had moved from doing Java stuff, I think he'd written books on Java, Enterprise Java before that too, to Rails. And he told me, I remember where I was sitting, I was in 2005, and I was helping him with some like Rails windows problem. he said, yeah, I've just started working in Rails, and it's been like a month, and I find myself to be exhausted at the end of the day.

And the reason, because I thought, well, that's weird. That's not what I expected. I expected you to stay energized and excited and not dealing with all this crap anymore. I'm exhausted because in the Java world, I would think of something I wanted to do, and then I'd spend an hour typing it into the thing and having it compile. And then I'd be done, and then I'd think of the next thing. And the hard part is thinking of what you want to do and how you want to do it. And then the easy part was sitting and typing. Right?

So weirdly, it actually increased his cognitive load to raise the level of abstraction. And I recognize that to be true for me too. Like, I can go so fast with this thing, you know? I have this exact feeling today when I'm using quad code, because I structure things in such a way that it finishes the thing I want it to finish, and I need to decide what's next.

Joe Leo (23:42)
Yeah, I can identify with that as well.

Chad (23:56)
And I'm dealing with complexity much more quickly than I would if I was typing it in, because the system that it's creating is huge. So you ask me the opposite. I'm telling you, it sort of increases the cognitive load, but I think it does it because it removes the boring stuff and the mindless stuff from my process. The things that it would decrease, though. So just to make this believable.

Imagine you have a system you're building and almost the entire system is made of pure functions. So, you know, no side effects, no memory being changed. It's just, you know, deterministic inputs, outputs. ⁓ So the first one is reverse a string. You could write that. ⁓ You could also use a built-in thing for the language, but let's imagine the language doesn't already have it.

If you had to reverse the string right now, you'd sit down. If the language doesn't already have it, you'd sit and you'd think, OK, how do I need to do this? How does it need to perform well? Blah, blah. And then you'd finally type it out and you'd be done. It's a simple thing. But I think we all agree we could ask an LLM to do this, and we could probably trust the output. It's a pure function. The complexity is reduced by the surface area of it.

I think, I don't think there's an easy question or answer your question, so this is why I'm rambling so much that and I'm a rambler apparently, but I think with the right architecture, many more problems can be solved in such a way that the solution is trivial and therefore we can reduce cognitive load by not having to think about it. And that leaves us thinking about architecture.

And you know another thing from my past is when I got into test-driven development I've only been to two software courses in my life. One of them was the extreme programming immersion that object mentor used to do And I went to that I convinced my company to send me and a whole bunch of other people and we were going to do XP you know And so I was sitting with Kent Beck because that's what you get to do the inventor of extreme programming pair programming on some made-up problem

Joe Leo (26:01)
That's pretty cool.

Chad (26:06)
And I remember telling Kent as we were working on this thing, I see what's happening now. When we do TDD the right way, we take a complex problem, we break it into simple pieces, we declare what those pieces are, and we allow the hard part to happen lower in the stack. So now we go lower in the stack, we do exactly the same thing, and we TDD all the way down to the bottom where nothing was ever actually hard to do.

I think what we need is architectures now that mirror that sort of a thinking for the LLMs. Because the LLMs can't do hard stuff in a way that's reliable. They certainly can't maintain the system after they generate it. But what if we had a system design and architecture that was just made up of hierarchies of things that were all trivial, and we could all trust the most idiotic programmer we've ever met to build it, as long as there's a test for it?

So this is how I think now, and it's how I've always thought, and I told you there's biases that I bring from back before I went to Wunderlist, which led me to do this crazy heterogeneous back-end microservice architecture, which I didn't talk much about. the reason I left Ruby was I wanted to explore these ideas of decoupling and composing systems of trivial pieces. And even back then, started talking about immutable infrastructure, which

Joe Leo (27:31)
Yeah, I remember

that. That was a big influence for me. Sorry to cut you off. I loved that. ⁓ What you wrote about it, I knew it at the company I was working for. It was a big influence on me. So yeah, continue.

Chad (27:43)
So I think I coined that term, and along with it in... ⁓ no, it you. It was you that coined the term. But after I heard it, I wrote a post about it. ⁓

Joe Leo (27:48)
I've been taking credit for it for years. I'm sorry.

Chad (27:59)
What I used to always talk about was immutable infrastructure and disposable code. And it's the latter that's more powerful that didn't catch on as much. So at Wunderlist, what I would tell the team is you can write your code in any language you want on the back end, That's where I was really working, mostly. Any language you want, but it had to follow a certain set of guidelines. And there were the obvious ones, like it works with the monitoring system and the build system, whatever else. ⁓

The one that was the most important is I would hold my fingers up, like the size of a small page or something, and say, as long as the code is this big or smaller, you can write it in any language you want. The reason was we had built a system with a consistent set of calling conventions and API conventions, so anything could plug in. It was all via HTTP, of course, and a message bus thing that was ⁓ sitting on top of RabbitMQ. ⁓ So we had two modes of calling things.

Valentino Stoll (28:38)
haha

Chad (28:58)
We had an architecture where it was very obvious where something should sit. And so if your code is no bigger than a page long and it doesn't work, or someone doesn't like that language and they're on call, they can replace it. So if I'm doing some crazy stuff in Haskell and I could only find one other person at the company who would work on Haskell with me, which is the case. And that was one of the rules. You had to have at least one other person who was excited to work on and maintain the thing with you.

Joe Leo (29:25)
That's a rule.

Chad (29:27)
So if neither of us was around and the Haskell thing went down, we'll just rewrite it in Ruby. It's fine. Or rewrite it in Go or whatever. And we did that sometimes. So like, oh, I've got an upgrade request for this service. I don't like closure. I'm just going to rewrite that function and type script or whatever and do the upgrade for it, the feature enhancement for it at the time. So why am I talking about? Oh, the reason I'm talking about this is

Valentino Stoll (29:33)
hehe

Joe Leo (29:50)
⁓ That's pretty fascinating.

Chad (29:57)
What if you had a complex software system where all of the pieces of code followed those rules, and therefore, any time you needed to modify the code or maintain the code, the system just figures out which piece it needs to change, and it replaces it, because it's trivial, and it has clear inputs and outputs, and its side effects are well known. So it doesn't matter if your LLM can figure out how to maintain your code.

as long as it can find the thing and replace it. And you don't care. You're not married to the implementation of the thing. You just need it to do what it's supposed to do.

Joe Leo (30:33)
Yeah, exactly. I really love that response. I'm glad you rambled because I love the idea of the composable, like the hierarchy of composable objects. think that's a great way to think about it. An optimistic version of the future.

Chad (30:38)
you

Valentino Stoll (30:49)
Yeah, I mean, I can

testify to that actually working in practice as well. A lot of stuff that we're working on at Gusto is very ⁓ modular as far as like ⁓ these chains of abstraction, ⁓ right? Like, so you can, if you can abstract a concept about something, then you don't have to define it everywhere anytime you call the LLM. And that seems to be true even for a lot of the stuff.

You know coming out in the industry as well even from Shopify a lot of OB's work from like, know Claude on rails or or even a lot of the specification driven development right that's coming out now It does seem to be like well you know, okay if you enter this directory even then ⁓ this is how you should behave as an assist coding assistant, right and ⁓ That can be even like you said drilled down further down the stack to be more specific to okay. I'm working on you know

database related things in a Rails architecture. ⁓ Here are things to follow, right? But there is definitely, you know, it's hard to manage that kind of abstraction on top of all the other abstractions, right? And I think that's where we're kind of missing some tooling and infrastructure, even from the industry, not just Rails and Ruby, Is we have all of these, ⁓ you know, kind of cobbled together.

things that work kind of ⁓ and they should work very well because of how tightly bound the conventions are already defined, right? So in a Rails stack, if you want to do anything database, ActiveRecord is very well defined and it has very ⁓ simple instances and interfaces to do most things with, right? But if you just drop that in an LM, you're gonna have to give it some handholding or

hook up an MCP and then it's gonna have to call the MCP, like who knows how many times to figure out like just how to implement the thing that's already implemented. ⁓ And so what I'm looking forward to is more of like this context expansion, right? Like how do we take these abstractions that are very big but when the ask comes, it's very specific. How does it like then walk the stack, right? Like how does it find its way up to build up more context?

to those things out, is ultimately what we do kind of in reverse in a way. Where we say, okay, like we do it in both directions, yeah.

Chad (33:21)
Yeah, well, we do it in both directions because we have

the same problems that LLMs have too. We also create the same problems that LLMs create for that matter.

Valentino Stoll (33:27)
Right, yeah, and so, totally. ⁓

I feel like, you know, Rails, like you mentioned, outside of the conventions, all the generators and things like this are just so helpful in this generative process. I feel like there's something there too where we could really expand on ⁓ to drill into these kinds of concepts. I'm curious if you've thought about, even from a Rails perspective or even Ruby's like,

modules like includes and things like that if you've thought about maybe how this architecture would look

Chad (34:03)
A bit, yeah. I I think, like, I lean toward, you know, I use the word bias a lot in this conversation already because I have this bias that everything needs to be small and decoupled. And this is why I was also one of the crazy microservice people, and I probably still am. It's not because I want everything to talk via HTTP and be slower. It's because I want forced decoupling.

And I want it to be harder for things to be badly coupled than easier. The default choice should be the good choice. And that's what microservices do. in Rails and Ruby, who was it? There was a speaker, I should remember his name. There a speaker at Nordic Ruby back in 2014 who said,

Ruby, paraphrasing, Ruby lets you create beautiful ⁓ coupling or something. Like that's the purpose of Ruby. And it was just like, he was coming from the outside and he had this really eloquent way of saying, Ruby's features are beautiful and they increase coupling in so many different ways. Like you don't know if there's a new function or a new method on string, for example, you know, then.

Valentino Stoll (35:00)
you

Chad (35:16)
you don't know what's going to happen. And that's one of the things that never would have worked, that people thought Ruby is crazy, you can't be doing this. ⁓ So I think more about how do I not have to worry about tons of context more than I think about how to increase it. ⁓

You know, I think you're right that generators, it's not just conventions, it's actual code that does things. And to your point about text being a big input, well, the input, textual descriptions versus code being more of an input into LLMs and the training data, ⁓ all the text tells you to generate things. So the LLMs already know that's what you're supposed to do, which is good. That's a good start. The worst case would be like, I know how to make a Rails app. I'm going to, as an LLM, hand code.

Valentino Stoll (35:56)
Right.

Chad (36:03)
all the components, which means they're gonna be like the two year old version and not work with Rails 8 or whatever. ⁓ But yeah, I I think like, there are good things about, like we've been talking about how Ruby and Rails in certain ways lend themselves well to generated applications and I agree, I think that's true. ⁓ I agree with myself, no, I think that's true. ⁓ Though the pessimistic side of this from a Ruby perspective, ⁓

When I was thinking about going to RailsConf and how I was going to perceive being there after all these years, the pessimistic side of me says, well, the language that wins is the one that is easiest for, there's an ease of generation, ease of deployment piece. But ease doesn't matter anymore when humans are out of the loop. So what really matters is the runtime that's the cheapest to run.

and provides the best uptime and speed. So they're just really boring metrics that are all about machines that ultimately we need to care about. Probably there is a bit of how verbose is it, Valentino, to your point of more tokens means larger context? I'm sure there are ways that brilliant people can compress that stuff out, but succinctness is probably important. But fast is...

Joe Leo (37:18)
you

So that's, is that another,

that kind of like another vote in favor of something like Haskell as a better alternative.

Chad (37:35)
Yeah, or

Haskell Rust. I mean, it could even be C. I think that would be stupid with LLMs because you have no guardrails. Rust is kind of best of all worlds. You've got like really strong typing system, ⁓ you know, the compiler can check things for you. It smells sort of like Haskell in that way, but you can create things that are like super lean, perform really well.

Joe Leo (37:42)
you

Chad (37:59)
Haskell is a great example. We had a service in Haskell that when we were scaling up, we had massive performance problems before a big rewrite that we did that I was leading. ⁓ With all of our servers, we'd have at least nine instances of the server running on nine EC2 machines back then. With Haskell, we never needed more than one because it was just like everything happened in a millisecond. It used no memory and it never crashed.

Joe Leo (37:59)
Yeah.

Chad (38:28)
You could run it on a laptop probably. The rest of it we are spending hundreds of thousands of dollars to run this infrastructure.

Joe Leo (38:35)
why we're renaming the show to the Haskell AI podcast coming here next week.

Chad (38:38)
I think Haskell

has not won. By the way, Haskell is an interesting one. ⁓ When I said if someone hates my Haskell code and they don't want to modify it or they don't like Haskell, they can rewrite it. Ultimately, the code never broke. We never had to change it once it worked because the type system and there weren't any bugs in it.

But the build system changed around it in a way that was incompatible with something we had done. And we got to a point where we could never compile it again. So we had to replace it just because we couldn't get it to compile, which was a very annoying thing for me with my Hasbro project. yeah. I don't know if I...

Joe Leo (39:13)
Yeah, that is.

Valentino Stoll (39:13)
Yeah, you know, I had a follow-up

question ⁓ based on, you know, your idea of ⁓ computation-like performance ⁓ at that point. ⁓ So I think what I took away from that is that if Ruby wants to ⁓ dig in to take more market share, we need to be more performant.

Chad (39:40)
Yeah, yeah, definitely. I mean, the pessimist says, too late. Doesn't matter anymore, you know? ⁓ The optimist says, well, there's a whole bunch of reasons. There's a bunch of Ruby code in production, so people already are dealing with the operational cost of Ruby. So maybe it's not too late. There's tons of great documentation that's easy to generate things and all the stuff we said about Rails before with conventions. So maybe it's not. ⁓

Valentino Stoll (39:46)
Too late.

Chad (40:07)
I do worry a little bit though. I know we're on a Ruby-themed podcast now, but the main thing that I was thinking about going to RailsConf is like, I spent so much of my career really identifying with a programming language, whether it be Ruby or something else, or with some sort of like guts of how things work concern, you know. Most of us in the future won't have the luxury to do that, if that's even a luxury.

Like the fact that there's a conference called RailsConf, this feels like a blip in time. Of course, now it no longer exists. So, you know, maybe not the best example, but it's a blip in time where humans were concerned with this sort of thing at levels that would have thousands of them go to other countries and talk to each other about it. You know, like I, I think it's a dangerous worrying thing.

Joe Leo (40:44)
More right than you realize, yeah. ⁓

Chad (41:06)
to identify now with an implementation detail. And I think Ruby and Rails are implementation details in the near future versus like cultures and full-time vocations and hobbies. Unless it's like, I guess I still do like racket programming sometimes on the weekend for no reason. there's probably a place for a hobby. ⁓ But yeah, it's not just Ruby and Rails. It's just like any language community.

beyond the hobbyists. You say like we want Ruby to be adopted. Well, you I used to be a director of a nonprofit that was all about advocacy, of course, for Ruby. Now I think that isn't a thing that we should be thinking about so much. I think we're graduating to another level. And it's more like, how do we make these machines build the code for the machines better? And there's a whole bunch of stuff around that, as you know. You you've been talking about MCPs, this and that. Like, to me, that's...

That's the place that people like us live in the future, as opposed to down in the layer of abstraction of even a web framework and how you.

Joe Leo (42:15)
Well, so you could be right about that. and OB Fernandez was on the show a few weeks ago. So it's something similar. Like, Hey, you know, I used to really pride myself on, ⁓ what did he say? The assembler, you know, code that you put together and, know, that's, that's all where you kind of let those things go. But I am curious to know, I probably have a less serious question than Valentino, but it is, it is serious. Like what, what did the enthusiasts, the professional enthusiasts do? Where did they go to, ⁓

Valentino Stoll (42:15)
Yeah, you know.

Joe Leo (42:43)
celebrate what they do together and learn from each other? Or is it just a bunch of like, well, we all just kind of direct the machines now and that's good enough. We don't have to go to any conference about it.

Chad (42:54)
So there's probably a

transition period. Obviously, for a long time, there's going to be Ruby and Rails, and people are gonna be typing Ruby and Rails code, and reading Ruby and Rails code. If for no other reason, then there's all this legacy code people have to maintain. So I think communities continue to exist around this stuff. ⁓ But I think in the future, ⁓

I think there will always be enthusiasts, but it's just a matter of what they're enthusiastic about. ⁓ It's not going to be, I think it's going to be like the tools around this stuff and the techniques. I'm sure you see this as well. The reason I said earlier, I think we should stop using vibe coding as a term, except for as a pejorative. So I think there is like an art which will be evolving for quite a long time of how to orchestrate systems so that they get built well.

Joe Leo (43:53)
Yeah, I think so too.

Chad (43:53)
cheapest, most effective,

best user experience. It's still a creative thing. I wrote a short story recently, and when I say I wrote one, ⁓ had multiple LLMs collaborate with me on a short story, and ultimately I wrote none of the text. But I feel deep ownership of the output. No one else would have created what I created in that session.

It's actually deeply disturbing. I'm going to use it for a music project. I won't go into it because I ramble too much. But at the end of that, thought, I'm exhausted. I feel like I've done something amazing. I want to share it with people. And I did not write this story. I'm not an author of fiction. I didn't write the words, but I still feel like I created this thing. And there's a craft to it. And I don't think you could have done it, either of you.

because you're not me, you didn't approach it the way I did. And I think there is actually even something like novel and clever of the way I did it. Now, of course, in programming, I think that to a much greater degree, because I'm a so-called expert in software development and architecture. So the way I deal with these LLMs is different than most people. And the way you deal with them is different from most people. And it's really exciting. And what I find is when I catch up with my friends,

in such situations like this. My previous call was with a friend named Jess Martin, who used to be in the Ruby community too. We spent the whole time talking about how we're dealing with LLMs to generate code and how we're orchestrating and making tasks get completed in a way that works, integrating with GitHub. I think that's where it goes now. It's just a different thing that you're worried about at a higher level of abstraction. Sometimes we'll look at the code that it implements and probably comment on that too, but...

Valentino Stoll (45:23)
You

Chad (45:41)
You know, we don't get together at RailsConf and all of us talk about the specific implementation of some feature, like how has-many works. That's not interesting anymore, you know. It used to be in 2008. That was the thing we would debate. Not anymore, it's done.

Valentino Stoll (45:51)
You

Yeah, you know, I'm curious because like there are so many problems technically that haven't been solved too, right? ⁓ And so where did those problems go in this new state? ⁓ We almost have to have those solved too, right? Before we can get to that ideal state of the LLM just doing everything. Right. And so to me, I worry that that is like something promised early and delivered late.

Chad (46:15)
Mmm.

Yeah.

Valentino Stoll (46:26)
and everybody just ends up having to deal with it. And how do you move fast in that environment, right? Rails and Ruby, they're really great at moving fast. That's why people choose Rails to begin with is you want to get a business set up on the internet. Rails is fantastic for doing that at lightning speed. ⁓ And so how do we keep that momentum in this new layer of abstraction, right? And so that's something I worry about because

Chad (46:31)
yeah, yeah, definitely.

Valentino Stoll (46:56)
know, REPLIT is great for like doing quick things. You know, somebody wants to deal with UX and try out a new thing, you know, let your design team at it and have them build up an interface and solve your UX for how you want it to work. And then hand it off to something else, right? Like that's going to be more performant longer term. ⁓ I feel like I'm a little suspicious of that actually being solved near term, even medium term.

like in the next three years. I feel like that's a long shot. ⁓ so I think about like, you know, everybody's going and using all these code generation tools and it's great, but you still have this review process, right? Trust but verify is going to be a thing for a long time. And when you have to read through thousands of pages of code that it generates at a time, yeah, there are ways to reduce that amount with some work, right?

Chad (47:26)
and

Valentino Stoll (47:54)
but then you just have more code to review in smaller chunks. It's still reviewing, right? ⁓ So how do you continue to move fast, right? Like in this iterative process that we've built up, ⁓ that we've proven that works, right? I know that we're talking about building new processes, ⁓ but I feel like that generative aspect of things is a huge bottleneck.

Chad (47:58)
And you're not going to review it. You're not going to do it. That's the answer.

Yeah.

Valentino Stoll (48:22)
Everybody that I've seen introducing code generation from a ⁓ large scale ⁓ introduces a bottleneck that is unseen. ⁓ And it is seen by top people in some regards, right? But it hasn't been realized. And, ⁓ right.

Chad (48:40)
Yeah, yeah, I mean it's trash, most of it. I

think, like, I have so many reactions to what you just said. One of them being there is this obsession with one-shots, which is the wrong way to think about things. That's good for demos. ⁓ The other one is just...

Valentino Stoll (48:56)
Totally.

Chad (49:00)
Like the entire modality of assuming that people are gonna sit in an editor and have an assistant. That's silly That was a complete waste of time and will continue to be I think it made us all go faster for a little while for those of us that like to use those IDEs I don't but ⁓ Ultimately, I think we have to think about agents as members of the team, know Not like we have to humanize them. But you know like github ⁓ GitHub was built for agents

They didn't know that at the time, but I remember the first time I saw Sneak, the security company, SNYK. I talked to the founder, he showed me demo of Sneak making changes to code to upgrade from security vulnerabilities. I was very skeptical back then, this is like 2017, until he showed me, it just generates a pull request. I thought, oh, wow, okay, great, it's a pull request. I'm comfortable with that. And the reason that that turned on the switch of like,

computers are going to be able to generate code because I see how it fits into the process. So I would like to see agents get introduced to teams in this way where they're just dealing with the programmable API surface areas of all the things that we interact with when we create code. We don't need to look at their editor when they're working on it, just like you don't have to look at mine.

Joe Leo (50:19)
Totally agree.

Yeah. ⁓

Chad (50:21)
But

then you're right. If it's going too fast, you're not going to be able to generate it, or you're not going to be able to review it quickly enough. That's where it's about new processes to me and architectures that make this OK, sending the right things to the agents so that you can trust them. In the same way that if you work for a big company and you bring on a large contracting company for lower cost labor to do software development, which I have done a lot in my career.

You don't get to talk to them all the time. Sometimes you're not speaking the same native language, so there's a bunch lost in translation. They go off and they do a bunch of work and they deliver it all at the same time. And then you've got tons of code to review. You work on a system for 10 years and you're in an environment with rotating staff members and rotating contract companies. You have the exact same problem already that you have with LLMs.

You're just getting to the problem state faster, but you're also getting to the positive state faster with LLM. So it's not all bad. So I think you should worry about it. I was interrupting ⁓ excitedly saying, we're not going to review the code. It's not because I think we shouldn't, although I also think we have to accept it and not review the code, because we can't. And we also can't slow down.

Because no one will tolerate that. The incentive structures in the world don't align with us all saying, we've to slow down. Let's be like half AI speed and half human speed. Not going to be OK. That's just not how it works, right? So look into the future, and look what business is going to tell us about how we need to operate on code. And we need to be thinking about how that's going to be OK. ⁓ I think you're totally right. ⁓

Valentino Stoll (51:44)
haha

Chad (52:00)
There were a bunch of promises and they're not going to be delivered and the whole thing's going faster. The cart's going before the horse and all this stuff.

Valentino Stoll (52:07)
Mm-hmm.

Chad (52:08)
We have to figure it out. And there are going to be people who care about this and who don't have their heads in the sand that are the ones that figure it out. And they're the ones that have a programming community that people that enthusiasts rally around because they're figuring this stuff out in the same way that like the rails, you know, the first like rail scaffold thing, all the Java enterprise people are like, haha, that's ridiculous. That's junk. I don't trust that. I'm worried about that. Yeah, you should have been. But also there are a bunch of people who saw that and said, we're going to make that OK. And we're going to solve

Valentino Stoll (52:29)
You

Chad (52:38)
those problems as opposed to say, we got to slow down, not use that. Let me know when it's done. Because those are the ones that are still doing Java enterprise programming at a terrible corporation.

Valentino Stoll (52:48)
Hahaha

Joe Leo (52:48)
Yeah, I really like

that answer. I had something similar to say in a talk a few months ago about the number one reason that AI exists at all when it comes to software is so that humans could go faster, right? Businesses just want us to program faster. So yeah, you're right. can't, at some point we will have to...

a system or get comfortable or something with the fact that we can't review all the code that the AI is writing because our competitor is not going to review all the code that AI is writing and look at all the money they're making according to, you know, the owners of the business. that is, yeah, I mean, that's maybe that's capitalism or that's economics, but I think that's absolutely the way we have to be thinking about it. But I also like that there's some hope in there, I think, from both of you because you're saying, well,

Valentino Stoll (53:25)
you

Chad (53:26)
Yeah.

Joe Leo (53:43)
Okay, if that's the case, then we need to get a lot better at building the thing to make it okay. As you said, Chad, right? To make it okay means to be innovative and creative to find solutions for that rather than tucking it away or pushing it away.

Chad (53:57)
Yeah,

it's kind of like regulation and alignment and all this stuff, you know.

If a country slows down on this AI stuff, then the other ones aren't going to. Unfortunately, it's like an arms race, but you have the same situation. I think it's not capitalism as much as is economics, to your point, that it's all about incentives and mechanisms and game theory. ⁓ And by the way, we all have a business. ⁓ You were mentioning the business owner. Well, you're the business owner of your career.

Valentino Stoll (54:18)
you

Chad (54:28)
and you're competing with other software developers as well. like 10 years ago, it felt like that would never actually mean anything other than how rich can I be as a software developer? It might mean, can I have a job as a software developer in the future? And so you need to be making those decisions, not you specifically, Joe, but you as the proverbial you. You need to be thinking about this, like how do you compete in the industry?

Valentino Stoll (54:39)
You

Chad (54:57)
And if you're not going fast, someone else is. ⁓ Are they writing perfect code? No, but neither are you. So like, you know, what's the gradient? What's the delta? What are you bringing that's this time in the world?

And I will argue that for most people, the thing you bring that is special and differentiates you will not be your expertise in a specific programming language or framework. It might be in a database, it might be in a runtime. If you're an expert at deploying, it's like the containers and the rails on which these agents will work. That will continue to be valuable for some period of time. But the creation of the thing, not so much, not in the details anyway.

Valentino Stoll (55:37)
Yeah, you know, one thing I've seen ⁓ recurring in the Ruby community is this idea of a runtime self-tolerant system where, you know, it kind of just rebuilds itself as it goes. And I can see that becoming a thing as these things become more performant. And maybe that is a potential future for Ruby in general ⁓ if somebody can go build one of these things where it's safe to run.

⁓ And modify right in real time. I feel like there is potential there ⁓ to see maybe a future not necessarily for ⁓ Doing the like writing the language of your own but at least using it You know

Chad (56:10)
Mm-hmm.

Yeah,

that's interesting. You can modify in memory with monkey patching in memory. ⁓

Valentino Stoll (56:27)
Right? You know, if it generates something

and it had an issue doing whatever it was trying to do, just having the thing reflect on itself and be like, what should we have done differently and modify it and then re-execute, right?

Chad (56:40)
Yeah, I'm afraid of that. I'm also excited about it. Yeah. Yeah. I mean, I, you know, my crazy idea is like, we could definitely build up a standard library of known good stuff really quickly. Um, you know, whether it's in Ruby or probably WASM or, some, some other, maybe it's on a domain and tech specific thing. Like imagine a, an incentivized contest where

Valentino Stoll (56:42)
Yeah, everybody should be.

Chad (57:09)
you are rewarded for the ⁓ challenges, and the best challenges like the most useful, best specced version of a function that needs to exist that more people, that lots of people want, right? You're rewarded on that end. You're also rewarded for the solution. And the solution is based on metrics and KPIs, and of course, assertions and actual test framework. Now...

Valentino Stoll (57:29)
You

Chad (57:33)
People could come play this game and they could type code. That wouldn't happen for very long if there's a reward, right? So then it becomes a bot war. Whose bot does the best thing? So imagine now you win the contest for one specific function or library or whatever the unit is, you know. Now there's an ongoing thing where you're incentivized to make a better version. So this has now been canonicalized into the standard library of whatever. And now you've got thousands of agents competing to make the more performant version.

the version that uses less memory, and now just like pour tons of money into this thing and watch agents build up an amazing new system of interoperable libraries and components that you can trust because they're all spec'd out in terms of how you verify them.

Valentino Stoll (58:21)
I'm sensing a cryptocurrency scheme here.

Chad (58:24)
Well,

it feels that way because that would be a way that makes sense. It's really because crypto and mechanism design go together, and this is an economic problem. Yes.

Valentino Stoll (58:28)
is true.

To be honest, I could see that,

⁓ know, you know, incentivizing people to solve challenges and earn from that ⁓ over time, ⁓ being very fruitful.

I know I've done coding challenges myself back in the day, no longer, you know, there's a certain reward you get from it, achieving it. And I imagine agents would feel that, you know, in a way.

Chad (58:49)
You

Joe Leo (58:58)
Yeah

Chad (59:00)
Well, you would still be a person, you know, program, like trying to coerce the agent, trying to program the agent.

Valentino Stoll (59:05)
It's true.

Joe Leo (59:05)
Yeah, exactly. You're

trying to create the bot that'll do it.

Chad (59:08)
Yeah, if the system existed and was successful, people could just make their living asking bots to do the most clever version of this. I think it'd be an interesting way to race to some new understanding of how to generate code well. All right, after this call, we'll hang up and start on. Well, for me, the first thing I will type is Claude space dash dash dangerously skip permission check, or whatever it's called.

Valentino Stoll (59:22)
Let's do it. Yep. ⁓ Botchallenge.com.

Joe Leo (59:29)
Yeah

Valentino Stoll (59:40)
It's amazing ⁓ how much that is getting adopted that I've been seeing people do. ⁓ Just like, yeah, whatever, YOLO, you know. ⁓ It makes me nervous. Right? Yeah, I should be nervous.

Joe Leo (59:50)
You

Chad (59:51)
Welcome to the future. You should be nervous. Yeah. And

it's just what I was saying. You should be nervous and you cannot stop it. So we have to assume this is the case.

Valentino Stoll (59:58)
Can't stop it.

Joe Leo (1:00:02)
We should let Chad go, I know he's got a heart out. ⁓ But we really love to have you on here, we'd love to have you back again, especially after this new, you know, this new Chad Baw challenge is up and running. And ⁓ you can talk about the winning, the purse that we could all win.

Chad (1:00:17)
Thank

We'll be too busy raking in the money after that.

No, it was fun, yeah, and anytime. I love to talk about this, obviously. Thank you.

Joe Leo (1:00:31)
Yeah, us too. Thanks

Valentino Stoll (1:00:31)
Yeah,

Joe Leo (1:00:32)
so much.

Valentino Stoll (1:00:33)
yeah, I appreciate it. If you've got any more time, you know, we do this little segment at the end where we just share something that you're interested in. It doesn't have to be specific to what we're talking about. I'll just give you the opportunity to share whatever you want. Just anything.

Chad (1:00:46)
Just anything that I'm interested in.

⁓ Well, let's see. Because of AI, I am finally learning 3D modeling and 3D printing after wanting to do it for years. And it is amazing how quickly you can go from nothing to actually solving a problem in your house. So the first project I did was I created a new end cap for my saxophone that protects the octave key, because I have one that I love.

Then I had another one I didn't love and I have two alto saxophones and I lost the bad one. So I like measured with calipers and created a new end cap. It was my first project. It took me like three hours and it was all because I was asking chap GPT and like showing it my screen. I just knew what to do. It's amazing. I sound like such an AI show, but it's just such an exciting new world.

Valentino Stoll (1:01:23)
You

That's awesome.

It really is. Yeah, you know, I have

a similar one with circuit printing and configurations. ⁓ Hey, chatGPD, what would you do for this? I even took a picture of just like tiny hardware components that I had lying around. You know, I'm thinking about making this thing. You know, how would you lay it out? Right. And it's just so cool.

Chad (1:01:58)
yeah, I got an ESP32

dev kit for doing IoT this weekend too. It's all related to 3D printing and all this. And it had a QR code and a URL to get like instructions and a tutorial. Of course the URL's dead. And I think the company doesn't exist. I was getting some knockoff. So I dumped out all the components on a table and I threw a picture of it and PatGBT sorted through and told me what it all was. Amazing. And they're like, walk me through projects.

Valentino Stoll (1:02:02)
Nice.

That's awesome.

It's the future, man. Yeah, can't not talk about it,

Chad (1:02:29)
Yeah, exactly.

Well, ⁓ it was fun. I'm interested in so many things that I could probably spend the next hour just brain dumping random junk on you, so I won't do that.

Joe Leo (1:02:38)
you

Valentino Stoll (1:02:43)
You know,

let's schedule another episode and we'll just do that. We'll just run through all the stuff that you're interested in and ⁓ working on.

Joe Leo (1:02:45)
Yeah.

Chad (1:02:50)
Then I'll make you listen to avant-garde jazz music.

Joe Leo (1:02:53)
Well, that's what I was thinking.

Valentino Stoll (1:02:53)
that's great.

Joe Leo (1:02:54)
want to hear, there's a whole other hour to do on AI and how you're using it in your music creation.

Chad (1:03:02)
That's the one place it doesn't touch that much, honestly.

Joe Leo (1:03:04)
Okay,

all right.

Valentino Stoll (1:03:06)
Awesome. Well, yeah. Thanks again, Chad.

Joe Leo (1:03:08)
Thanks very much and it's great

Chad (1:03:10)
All right, thank you.

Joe Leo (1:03:11)
having you. Take care.