Brendan: 0:13

Hey, how's it going?

Ryan: 0:14

I'm good. How are you?

Brendan: 0:15

Uh, not too bad. A little under the weather, so, uh, hopefully I don't sound like complete crap, but pretty good.

Ryan: 0:21

Yeah, I think these mics, uh, hide a lot, so we'll be all right.

Brendan: 0:24

Yeah,

Ryan: 0:25

feel like it's been a while since we recorded. Um, so good to be, good to be back here. Uh.

Brendan: 0:32

yeah, definitely.

Ryan: 0:33

All right. So I, the other day, um, I saw that 37 Signals is putting out a new podcast, YouTube thing. I don't, I don't know what exactly it's gonna be, but they're calling it recordable. So, um, it, it is touted as, uh, deep dive into technical topics, which I'm super excited about. Um, 'cause I've always felt like this has been a missing piece of the ecosystem. Um, very hard. To produce good content in this space, it's, uh, time consuming. So I'm, I'm hoping that 37 Signals is doing another solid for the community here with this. Uh, but I couldn't help but dive in. Um, their first episode was on Rail's delegated type pattern. Um. And, you know, we, we might get into that, we might get into a few other things, but the, the thing that came to mind first was they were actually sharing, uh, you know, snippets of the base camp code, uh, in this YouTube video, which, uh. You know, something I haven't seen very often, so I'm kind of excited just to, you know, another example of, you know, rails code essentially from the creators of Rails. Uh, right. So it, it provides like what I think is a nice roadmap. Um, and of course, like everything else they do, the, the most obvious thing right off the top was it was just like very. Easy to read and understand, right? Like naming was great. You know, the, the files were short, like their quote unquote God model. It was under a hundred lines, which to me is just absolutely insane. Um. But you, whenever I see stuff like this, you know, I get in this, uh, you know, it, it, and I don't exactly know how I'm gonna phrase this, so, so bear with me as it comes out, but it's like I have this urge to write code like that. Now, it's not a perfection thing, although maybe it, it, it sort of feels like that in my reaction, but like, I want my code. To look like their code. Not so much in terms of, you know, I'm trying to emulate them, but in terms of the ability to just be like very clear, I perceive it to be maintainable because it's so easy to understand. Um,

Brendan: 2:53

Yep.

Ryan: 2:53

but every time. You know, I feel that urge and I dive in and it becomes very difficult, right? Like it, it's hard to change existing code. Um, you know, on top of that you're learn I'm learning a new, you know, whether it's a new pattern or just, you know, new habits really is probably, you know, more, more apt. I have a hard time doing it. Um. But I, I feel like I, I, I don't exactly know how to explain the feeling, but I, I thought we could explore what that means. Like what, what, you know, why do I feel that way? You know, why is that a good idea or a bad idea? Um, you know, I, I'll, I'll stop there. And you say, what are your thoughts on, you know, you shared pre-call that you, you have similar feelings from time to time, so, you know, let's start there. Yeah.

Brendan: 3:43

Yeah. Yeah. No, definitely. It's something that, I mean, I'm even starting to putter again. It's like the third time, uh, at least I never get all the way through, but I'm, I'm getting in the same kind of feeling and

Ryan: 3:55

Which, which what you, what? Which, whatcha reading again?

Brendan: 3:58

Uh, this is Sandi Metz

Ryan: 4:00

Oh, yeah. Yeah.

Brendan: 4:01

puter, I cannot remember what it stands for at the moment. Uh,

Ryan: 4:04

Okay.

Brendan: 4:04

we'll link it in the show notes, but it's, it's object oriented. I know. That's like the, the

Ryan: 4:09

Right, right.

Brendan: 4:11

Um, and, you know, reading that book and I'm, it invokes similar things to what you were just talking about in me, where I'm reading it and it's like, this makes sense and I wanna write my code better and more like this. And then inevitably I get into writing the code and it, it feels fine maybe for a little while. But then, like you said, the realities of existing code and just time and pressure of the business and things like that make it hard to keep up with. Um, and I don't write code day-to-day enough to also like keep some of these things in mind. So like I, I fall back on bad habits, I think a lot more because of that. Um. But yeah, it, don't know, have a better word, you know, or like a better term for it, but I totally get it. It's like you, you see the patterns, they make sense, you know, whether it's right or wrong or good or bad, I guess is debatable, but it, it feels right, at least in the moment. And so it, again, it is not like perfection. It's just like something that. You feel like is maintainable later? That's how it always feels to me. but yeah, it's really hard to keep up with it and so I'm not really sure I can relate to it, but I'm not, I don't, I definitely don't have an answer to like to get better at it.

Ryan: 5:27

Yeah, I. You know, whether, whether it's, you know, a blog like this, a video like this, or, you know, uh, a pattern book, I, I always feel the same way. It's like, oh, it just makes so much sense.

Brendan: 5:42

Yeah.

Ryan: 5:43

And if I could instill, not even instill, I mean, it's like, if I can remember

Brendan: 5:51

Mm-hmm.

Ryan: 5:51

the patterns and the approaches long enough to. Commit it to a habit, I'd be in a really good spot, um, as a programmer. Right. And, you know, I, I, I want to get better as a programmer. I want to strive for these ideals. Um, but yeah, it's just. I, I struggle. It's like, what is, you know, I, I always try to keep in mind, I, I tend to be a perfectionist. Like I always want things to be as good as possible, right? But reality is that is, uh, a tough mindset to, to have all the time. You put too much pressure on yourself. So I always try to think of like, all right, what is good code versus good enough code, right?

Brendan: 6:41

Yep.

Ryan: 6:41

Um, and. You know, I look at, you know, I guess the question would be, you know, 37 signals as a company is very successful, right?

Brendan: 6:58

Yep.

Ryan: 6:58

Is that success a byproduct of, you know, the founders, right? Jason and David? Is it a byproduct of. The code they write. Right. And where do you think that line is drawn? Right? Like, I think it's naive to say it's one or the other, right? In reality. But there, there is a line somewhere there, right? How much of it is writing good code and maintainable code, and how much of it is the people, you know, not not just the founders, but the entire team? Um.

Brendan: 7:34

Yep.

Ryan: 7:34

Do you have a, you know, a guess?

Brendan: 7:39

Well, I think, I mean, I think their mentality like Jason and David's at least, is one that, you know, leans towards the success that they've had. I also think that because David at least has the personality and has written or you know, started rails basically, and obviously keeps maintaining rails. There's like to, to me, there's always that inside information that he has, even though it's not stuff that no one else can know, but just like by being the creator and the maintainer, and obviously there's lots of other people doing it, so I don't wanna take anything away from them. But just like he has a vision clearly that he wants and good or bad for everyone else using Rails like. feel like that's part of their success is that they have the business, but they also have rails and they go together enough that, and it's been around long enough too. That's the other thing about it. It's like that feels like it works for them. I don't know if that completely answers the question, but that's kind of my take on, on why I think it, or

Ryan: 8:40

Yeah,

Brendan: 8:40

feel about it.

Ryan: 8:41

and I think it's, it's, you know, they touch on this in, in the podcast too, but it's important to remember, I think they're on base version five, right.

Brendan: 8:49

it's

Ryan: 8:52

This pattern until three,

Brendan: 8:54

right.

Ryan: 8:55

And then they've iterated on it twice more. Now, according to them, the, you know, the chassis so to speak hasn't changed much since version three,

Brendan: 9:03

Mm-hmm.

Ryan: 9:04

I'm sure they've learned some stuff along the way and we have no idea what version one and version two look like, you know? So maybe, you know, the reality is. You know, I look at this code and be like, Hey, this is amazing code. You know, it looks good. It feels good. It is easy to understand. But that was a 20 year journey, and I'm on year five, right.

Brendan: 9:27

that, that was gonna be my takeaway too, is that, you know, one, uh, one thing that, um, uh, Dave, Dave Thomas says, I don't know if this is his originally, but I've heard it from him. I think it was in the pragmatic programmers book, you know, how do you. do you eat an elephant? I think is the joke. One bite at a time. And so like the point being you can't get to that perfect code instantly. And I think that's something that I try hard to remember when I'm trying to strive for the, the really nice looking code that we've been talking about here. not gonna get it right away. It's in, they didn't get it right away. To your point, like. a lot of time. It's a lot of refactoring. It's a lot of rethinking. It's a lot of different things that don't just happen overnight. especially if, like, in my case, I am maybe writing one feature every once in a while and try and make that feature look great, but then I'm pulled in five different ways and I come back to it like two weeks later. Of course, I'm not gonna get there. And you know, so things like that are definitely gonna play against it, but. Yeah, I, I think that's a really good reminder though. Like, it just, it takes a long time to get there, whether you're starting out or not. Um, and even like a new feature, you can't expect that to be written perfectly the first time you write it. know, maybe you can refactor it later before you merge it in or something, but it's not gonna be a, a one shot type of thing.

Ryan: 10:48

Yeah, and I, and I hate the word perfect or perfectly right? Like, to me that is never the, the goal, right? Because I don't, I don't think that even makes sense in most apps. I mean, you know, maybe if it's a really small, uh, perfectly defined, uh,

Brendan: 11:10

Yeah.

Ryan: 11:11

you know, thing, you could write something that is. You know, quote unquote, perfect. Again, I don't love the the label, but in most cases, software evolves, right? Like even if it was a perfect solution at the time, it may no longer be a day later, right?

Brendan: 11:28

Right.

Ryan: 11:28

Um, you know, so to me it's about. Just, it is more striving for the ideal, you know, perhaps, uh, of that. But, you know, just for arguments sake here, I wanna, uh, play the other side of this, right? Right. So if, if it is, you know, thinking of it from a business perspective, if this is something that you. You know, have to work at, and it takes, you know, years to get to a point where your software looks and feels like that. It's like, how do you, you know, on a day to day basis, how do you judge, you know, where you're at and how you spend your time. Right? You know, it's this, it's this good enough philosophy. Um, and I have some thoughts on, you know, how I might define that. But do you have any before I. Share those.

Brendan: 12:23

Um, yeah, I mean, a couple things that come to mind for me, like with my team, I, what I think of there is I've got so many different people, different, you know, skill levels, thoughts on good or, you know, good, good code. And it seems like, and this is just an outside impression with 37 signals, but it seems like they. From what I've heard, have at least some, uh, like understanding or like across the company, like they probably all feel somewhat similar to what Good, good Code looks like. And I don't know why I'm saying that specifically, but it just feels like, at least when David talks about it, that's kind of the impression I get. So they're a big organization. They're way bigger than, you know, either of our organiza organizations, so I could be wrong about that, but I find it hard. keep, you know, all the people on my team and it's like, you know, less than 10 in thinking about things the same way or like even sometimes caring about code quality in that way. Right? And so that alone, just the people part of it. Is difficult from, from my perspective at least. So the fact that they can write code that seemingly is, well, I guess we haven't seen a lot of their code, but the code we do see seems to be, you know, similar. And who knows, maybe this is all the code David writes and maybe other, other people aren't writing the code the way I'm thinking about it. But, um, that's really all I had to add there was just kinda like, it, it, to me, part of it is also. Having the you, you know, if you have a team, like making sure that they're striving for the same things, and if they aren't, it's gonna make it hard on its own.

Ryan: 14:02

Yeah, I mean, I, I was just gonna say like, I, everything has to be framed in the context of the business and the life stage of the business, right? So like. You know, you see a lot of stuff out there. It's like, I, I move fast, break things, fix them, learn, improve, you know, get product market fit. I mean, I, I think all that stuff can still be true, like for an earlier stage product. Um, you know, and you don't have to necessarily, um, you know, the code doesn't have to. Be perfectly maintainable. I'm trying to think of a different word for perfect than I, I can, right? So it's like I'm, I'm gonna fall back to that crutch, I guess, right? But it, it's okay for it to have some rough edges. Um, and then as you get to,

Brendan: 15:00

I.

Ryan: 15:01

you know, maybe a middle stage company, you start to care a little bit more about those rough edges, right? And you want a little bit more polish, and maybe you don't, you know, I think. You know, 37 signals often says, you know, they have to get to a, a specific level of polish before they're comfortable releasing, but it's not, again, they don't strive for perfection, right? They have bugs like everybody else. Um, and you know.

Brendan: 15:26

Well I think that just to to finish or not finish, but like add to that, like I think it's always good to remember that there's always trade-offs. No matter the best programmer in the world, you would know there's trade-offs. think to me. Thinking about those and not just writing code that works is the biggest differentiator because you're, you're right, you're, there's always gonna be bugs, there's always trade offs. Nothing is perfect, but think the teams that care about, okay, did I think about all the different edge cases, at least the ones that I can think of, and I'm not just writing code to write code. a differentiator on its own right there.

Ryan: 16:03

Yeah. All right. I don't know if I have too much more to add to that subject. Uh, before we pivot to something else, is there anything you wanna close out on?

Brendan: 16:12

Well, the only other thing I'll add is just the AI side of it, right? It's like talked to people that, know, they still care about their code, but they are also using AI to help them write code. So now that that's in play, they're not, don't, I've seen a less of a concern around, well, but the AI's gonna be writing this again or some, you know, something like that where maybe it's writing it in a slightly different way than what I would do, but it still works and it's still, you know, handling the things that we just talked about with edge cases and, and whatnot. But. And obviously then I don't even want to get into the whole vibe coding 'cause that's not even worth talking about. That's, you know, those people don't care about the code. Um, but I, it's something I just thought I'd bring up that like, as ai, as more AI writes code for people like us, like how much are we going to care about the way the code looks versus the way it works? I think I'm always going to care. that's one thing that I. Find difficult with having AI write my code is that I still want to review it. I still want to understand it, which I think is good and important, but then it's like, what are you getting out of the ai ai writing your code at that point? If you're essentially doing the same thing, it's like, should I have just written it myself? and we don't have to dive all the way into the AI stuff.

Ryan: 17:32

Well, I,

Brendan: 17:32

that layer to it.

Ryan: 17:34

yeah, I mean, I had a couple thoughts as you were talking there. One is I, you know, just like there's different levels of, you know, coding based on the, the maturity of your product. I think there's also, I, I can think of different levels of AI coding, right? So you said. You know, AI might write something very differently than you would

Brendan: 17:55

Yeah.

Ryan: 17:56

now. I tend to care less when that's at the unit level, right? At a method,

Brendan: 18:01

Hmm.

Ryan: 18:01

right? Like I,

Brendan: 18:02

Right.

Ryan: 18:02

in fact, most, most of the time they come up with a better way of doing it at at that level, you know? And if it's only a few lines of code, I can usually understand it pretty quickly and. That to me that's good. Like that. That's good difference, right? Like, I don't, I don't care about that. They didn't write it like I would write it because it accomplished the requirement and I can still understand it.

Brendan: 18:25

Right.

Ryan: 18:26

where that falls apart is when you start to go up the, you know, le the levels towards, you know, the architecture, right? And it's like,

Brendan: 18:33

Yes.

Ryan: 18:33

when I have, you know, this is maybe a, a. I'll give two examples 'cause they're a little bit different, right? But it's like, all right, you get into a controller and it's like, I always want, you know, restful, resourceful controllers

Brendan: 18:50

Yeah.

Ryan: 18:50

and, you know, AI typically, you know, when you ask it to do something that's outside of that, they just add a, a method to, you know, an action to the controller. And I'm like, no, no, no, no. Let's just, like, that's not how I'm gonna do it. Right? Like, create a new controller for this, right? And make it a create action, right? So like, you know, that, that level I care about, you know, the other one is like, on the view side that I can think of, right? Is like, all right, you know, all our views have, you know, you know, in our, you know, call it the, the back office quote unquote admin area, right? They all look the same,

Brendan: 19:23

Mm-hmm.

Ryan: 19:23

And they follow this, they, they use the same design layout.

Brendan: 19:27

Yep.

Ryan: 19:28

you know, that matters, right? And when AI introduces something new there, I'm like, what are you doing? Right? Like, don't, don't do that. Right. Follow the, you know, look at every other view file and do it exactly the same way and just change the, you know, the quote unquote body. Um, right. So as you go up, you know, my opinion of AI differing from, you know, the way it's done in the app,

Brendan: 19:51

Yep.

Ryan: 19:52

more important. And that, and that on, on its own is challenging because. You know, as you grow as a programmer, right, you may start to adopt, you know, these habits like we were talking about. Like, oh, it's like, uh, you know, you know, striving for this ideal, uh, that you have in your head of what your coach should look like.

Brendan: 20:10

Right.

Ryan: 20:11

And now. AI can't tell the difference between, you know, the older, you know, way of doing things in the newer way. So you have to give it guardrails on that. Um,

Brendan: 20:22

Yep.

Ryan: 20:22

and then you get to like the top level where you're making architectural decisions and how to lay things out. And generally, I, I find AI to be complete garbage on, on that. It, it's much better off using planning mode to be like, let's come up with ideas and discuss, and then you make a decision and tell it which one, uh,

Brendan: 20:38

Mm-hmm.

Ryan: 20:39

you're gonna move for. So like, there's levels, right? Um, uh, uh, of, of things that I care about in terms of when AI can do things differently than me or the team or whomever, or, uh,

Brendan: 20:51

Yep.

Ryan: 20:52

but I think that's also important to keep in mind is not all different, is bad.

Brendan: 20:58

Right. Well, I mean, maybe that's, uh, something we could touch on a little bit more since we're talking about AI stuff, is I, I know we've talked about it a little bit. You know, throughout the year here with our, our other episodes. But are you having AI write code for you at this point?

Ryan: 21:17

Uh, quite a bit, uh, to the point that I am maxing out my subscription of, uh, uh, Claude Code, uh, at this point. Um, I hit their, you know, five hour limit or whatever it is, fairly frequently. So, I mean, it, it's a lot. Um, but I mean, it's the. I would never describe how I use AI as vibe coding. Right? Like, I am never gonna let, I, I, first of all, I never let it make changes without asking.

Brendan: 21:49

Yep.

Ryan: 21:49

Right. That's a, a hard no for me. Um, because it's too easy to lose track of the thread and then I don't have confidence

Brendan: 21:58

Yep.

Ryan: 21:58

ship it to production. Um, I try to be. I try to give it focus on every request. Um, in general, how, how do I wanna say this right? Because it's, it's not that I, you know, micromanage the ai, you know, step by step. I, I usually let it go, but I try to give it guardrails as I go. Um, and I will very often say, no, don't do it this way, do it that way. Um. I mean, it, it would be, I feel like the only area, and I, I don't even like to admit this, that I let it do a little bit more is when it's writing tests.

Brendan: 22:46

Mm-hmm.

Ryan: 22:46

Um, and I think that is just because. I'm still getting comfortable with the, you know, how to, I don't wanna say how to write tests, but how to write tests the way I want to write them.

Brendan: 23:00

Right.

Ryan: 23:01

Um, and by that I mean like, I want it to be a specification of how the software should behave, um, versus, you know, test the behavior rather than the implementation.

Brendan: 23:13

Yeah.

Ryan: 23:13

Um, and AI is. Not great at that, right? So there's some work to be done, but oftentimes I feel like, all right there, it's writing tests. I can scan it, it's, it is testing edge cases. So, you know, for better or worse, in most cases, I say, all right, this is better than what I have.

Brendan: 23:34

Or, or better than nothing.

Ryan: 23:35

Better than nothing.

Brendan: 23:36

an approach. I've looked at it as well.

Ryan: 23:37

Yeah, so I, I, I let that go a little bit more and I know that, you know, in my head I'm accumulating some tech debt there that will have to be fixed at some point, but for now, it's better than nothing. Um, but otherwise I'm pretty strict about what I allow into the code base, especially on the non-test side of things. Um, you know, is that consistent with how you're. Thinking about it right now.

Brendan: 24:07

Yeah, I, I think so. And you know, a couple thoughts I had about your answer there is where we started, you know, here about clean code, manageable code, all those sorts of things. And then you saying, and, and me too, like we both let AI write a lot of our code. It's kind of interesting to think about that. We care, we still care about what the code looks like, even though the AI is writing it despite, you know. A couple things we already talked about with maybe the, the way they write. It's not the way we would've, but I I, I'm wondering though, like at, at what point are we going to continue thinking about, or maybe stop thinking about the manageability of it and just because the AI's writing it, you know,

Ryan: 24:51

Well,

Brendan: 24:52

not as big of a deal that it looks like 37 signals or the books are reading and things like that.

Ryan: 24:58

I, I don't think. That ever is gonna change.

Brendan: 25:03

Mm-hmm.

Ryan: 25:03

What I think will change is what that means, right? Like AI needs to understand your code just as much as a human reading it,

Brendan: 25:14

Right.

Ryan: 25:14

right? And it, it may be that human readable code becomes less important, but AI readable code becomes more important, right? And what that means, I don't know yet.

Brendan: 25:28

Mm-hmm.

Ryan: 25:29

But given that AI is currently changed, uh, uh, changed, trained on human readable stuff

Brendan: 25:39

Right.

Ryan: 25:40

at the moment, until that model changes, I think writing good code is still, you know, human readable code is still the ideal to strive for. I ha

Brendan: 25:49

Yep.

Ryan: 25:50

that has changed yet. Now there are problems with that, right? AI is still not great at it, right? And you know, maybe that's the reason it changes in the future is we find a better way to communicate with the AI that is not, you know, a human first approach.

Brendan: 26:07

Right.

Ryan: 26:08

But that's not gonna happen with the current models because that's not how they're trained, right? So like, either the model is gonna get better at understanding humans, or there's gonna be a completely new approach. Um, and only time will tell on that front. But you know, in my opinion for now, it is less about. I think the ideal is the same, and the goal in the short term until new evidence is, is presented to the contrary, is to figure out how to get AI to follow it.

Brendan: 26:41

Right.

Ryan: 26:41

Right. Follow the pattern consistently. Right?

Brendan: 26:44

think that's been the trick I've

Ryan: 26:45

Yeah.

Brendan: 26:46

is making sure that it's actually doing the things you want without having to fight it

Ryan: 26:51

Yeah.

Brendan: 26:51

much.

Ryan: 26:51

And that will, when that problem is solved. May, maybe I say this, you know, very maybe, right. I'll stop worrying about it so much. Right. And let AI write a little bit more for me. Um, you know, that is the promise of ai.

Brendan: 27:08

Mm-hmm.

Ryan: 27:09

I mean, we're not there yet. That doesn't mean ai, you know, again, isn't a very valuable tool that just needs to be babysat. Um.

Brendan: 27:16

Yep.

Ryan: 27:16

It still makes you more productive, it still makes you faster, it still provides a ton of value. It's just not free.

Brendan: 27:24

right, right.

Ryan: 27:26

Um,

Brendan: 27:26

Yep. Yeah, I mean, one of the other things that was thinking of while you were talking about tests, you know, is. I've been listening to Justin S's podcast, uh, breaking Change

Ryan: 27:37

Yep.

Brendan: 27:37

a bit, the last like six months or so, and he has a lot to say on the AI stuff and coming from test double where, you know, testing is a big thing for them. His, his thoughts on how AI writes tests are, it's pretty bad at it, and I, I don't have the insight he does. I'm, I'm a lot more like you where it's like I would, I love to write tests. I would love to be better at writing tests, I'm still gonna let the AI write tests because it's easier and better than not writing tests at all. But it, it just kind of makes me wonder, like when I heard him say that in whatever episode that was, just made me think like, man, do I, I feel like I need to buckle down and actually understand testing better, so that I'm not letting the AI write a bunch of tests that are either worthless or worse than that. They're like, you know, harmful in some way that I'm trusting them, you know, and it's like letting things slip through. don't know if you have any

Ryan: 28:37

I, I do, I have, I have two things, but before I get into the testing piece, you said it makes you want to buckle down. That is like the, that was what we were, I think the feeling I was searching for at the beginning of this conversation. It's like every time I see these things, these ideals that I agree with, right? It makes me wanna buckle down and spend,

Brendan: 28:57

Yes.

Ryan: 28:57

you know, the next, you know, whatever, 12 months, two years, whatever it takes to just like, all right, I need to instill. You know, some new coding habit,

Brendan: 29:09

Right? Yep.

Ryan: 29:10

So that I can meet that ideal that I have set for myself. And I, I, you know, maybe that's like the way I need to think about it, right? Is like, Hey, this isn't about perfection. It isn't about doing it the 37 Signals way. It's about doing it a way that makes sense for me

Brendan: 29:28

Yeah.

Ryan: 29:28

as a coder, but more importantly for me as a business owner. It's like, all right.

Brendan: 29:33

Mm-hmm.

Ryan: 29:34

This, I, I like this ideal because it will help me move faster as a business, right? And it'll help me provide a better product, right? Like, I don't, I don't necessarily care otherwise, right? I'm not writing it to write good code,

Brendan: 29:47

Right.

Ryan: 29:48

it for a business purpose. All right, so now back to testing. The, I haven't experimented with this, but I really want to, 'cause I, I think there is something to it, which is. And I, I, I almost hesitate to say it'cause it, it is gonna feel like we're going back to the nineties with like waterfall approach of programming. Right. But it's like, how would AI react if I gave it a spec, like an actual spec said, here are the. Here's what the, the, the software has to do now that in general is fraught with challenges. And I think we all know what they are. Like you don't always know the, what the spec should be and you don't wanna spend, you know, a year building a spec and then, you know, whatever. Okay. All that stuff is given, right? But if at a micro level I could say, you know, you know, would AI do better at writing code and. Testing in general, if you took A-A-T-D-D approach to writing code where it's like, all right, here is the spec for this one small piece.

Brendan: 31:03

Yep.

Ryan: 31:03

Here are the thing, like, go write this to make the test pass, right? And then creating these small feedback loops, right? Like I think AI could be much better in that scenario. Now that requires me to completely change the way I code. Like I've never done TDD, like I like the ideal in a lot of cases. You know, the one argument I've always had against it is I don't always know what I want. Right? But that doesn't necessarily invalidate TDD because right. If the loop is small enough, it's not painful to unwind and throw away. Right?

Brendan: 31:39

Right.

Ryan: 31:43

Thing that I've seen, and this was from OB Fernandez, I believe, is this idea that, um, I think we've talked about this a little bit before, but like if you have a bunch of agents that are good at, like different parts

Brendan: 32:00

Yeah.

Ryan: 32:01

of coding, right? Whether it's, you know, a controller agent or a model agent or you know, whatever. I'm greatly simplifying it, right? But his argument was that if you have. Code, you know, code that has good boundaries,

Brendan: 32:15

Mm-hmm.

Ryan: 32:16

right? Which I think is just a good coding principle anyway,

Brendan: 32:20

Agreed.

Ryan: 32:20

right? Then you know this, you know the swarm, right? Agentic coating. I feel like there's something to that. Now, I know a lot of people are like anti that approach, but I think they're anti that approach because they don't necessarily follow like the, you know, the. The best coding principles, you know, that exist, right? Like if you have very dry code and you have good boundaries and you only have public APIs and you know, those are well defined and you're doing TDD, you know, I think a swarm of agents actually could do fairly well. Now, that is a hypothesis that I have not tested and probably never will, but, um. You know, it, it is an interesting idea to me. Um, my code base would not do well in that situation because the boundaries aren't as well defined as I'd like them to be.

Brendan: 33:12

same

Ryan: 33:13

Right. But, you know, I think there are some code bases that it could probably do well. Um. And I'd be very curious to hear how it would do on like a Basecamp code base. Now they have very, like, from what I understand, strict sort of patterns and things they do. Um, and it's been suggested that AI would not be good at following those, but I'd love to hear from them on that. Um,

Brendan: 33:39

Yeah.

Ryan: 33:40

so yeah, I, I don't know if I actually answered a question there or went off on a tangent, but either way.

Brendan: 33:46

No, I think it makes sense. Um, I don't think there was a specific question anyways. Um, yeah, I don't know. I, I, I feel like that covers quite a bit. Do you have anything else you wanna add or should we maybe just wrap it up here?

Ryan: 33:59

Yeah, why don't we, we call it there. Um, you, I did wanna maybe talk about delegated types a little bit more. Uh, but maybe we, we'll save that for a future, future episode.

Brendan: 34:09

All right, cool. Sounds good.

Ryan: 34:11

All right.

Brendan: 34:12

All

Ryan: 34:13

Later.

Brendan: 34:14

see.