Code with Jason
Code with Jason
307 - Kody Kendall, Co-Founder and CEO of LlamaPress AI
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode I talk with Cody Kendall about building software for his dad's HVAC business, learning usability testing, pivoting from contractor software to AI-generated code, and why he built LlamaPress.
A Snail‑Mail Newsletter For Devs
SPEAKER_01Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly dot com. That's nonsense monthly dot com. I'll say it one more time nonsense monthly dot com. And now without further ado, here is today's episode. Hey, today I'm here with Cody Kendall. Cody, welcome.
SPEAKER_00Hi, great to be here.
SPEAKER_01Um, so we've found each other via Reddit. I put up a post saying that I'm seeking guests, and you raised your hand, uh, which I appreciate. Um, so tell us a little bit about yourself, and I'm curious what caught your eye about that post. Uh, how come you're interested in doing a podcast?
SPEAKER_00Yeah, Reddit's uh a great, great community just to kind of meet people and you know, particularly the Rails subreddit always has interesting stuff coming through. So saw another Rails enthusiast wanting to have a conversation about Rails and uh definitely uh a Rails enthusiast. So um yeah, my name's Cody. I've been a Rails engineer since probably about 2019 when my professor uh David Bean in our computer science program uh had us use Ruby on Rails for our web architecture programming class. And I remember at the time I was so annoyed because you know, being an opinionated, you know, you know everything about the world, right? When you're an undergrad. And I remember thinking, like, oh, Ruby on Rails, you know, is that is that really the right thing? And so that's kind of my exposure to Ruby. And then by the end of the class, I kind of saw the magic and I, you know, realized how amazing it was and how rare that was, too. Like, I don't know how often Rails is taught at a university setting, but definitely gave me an introduction to it. And then I did my senior capstone project with Ruby on Rails, and we built an app for my family HVAC business, which then turned into me kind of joining forces with my dad, built a business around it, and Rails was just an amazing you know, set of tools for building a business around. And so looking back in hindsight, that was probably one of the best things that happened to me in my career. So love Rails and very excited to just kind of talk more about Ruby on Rails. I also think it's really relevant with all the AI stuff going on. Yeah. Um, and I have kind of my own my own thoughts around that, but would love to dig into it.
SPEAKER_01Yeah, yeah. Um, so I'm I'm curious with that uh with using Rails in that class, what were your like hesitancies or whatever? I'm curious about that.
University Projects To Family Business
SPEAKER_00You know, at the time, um I really wanted to use Java in Spring for whatever reason. And I think I just thought, you know, I have a good foundation with with Java, with C sharp, that type of syntax. And it just seemed like kind of this niche thing. Um but you know, I think probably it just came from a place of ignorance more than anything.
SPEAKER_01Okay, and then and then you started using it, and obviously it changed your mind because here you are. Was there anything specifically that that did that for you?
SPEAKER_00I think I think once the once the mental models kind of clicked into place, just like the model view controller architecture, and being able to like very easily just kind of modify the controller code, modify the user interface, the models, all of that, it just started to click into place. So, in particular, just as I started adding more features um for the actual software, and I could just easily scaffold something, I could easily um do those things. I just I just kind of fell in love with it and really liked it. And I had another friend who actually ended up using Java in Spring for their senior capstone, and she said it was probably one of her biggest regrets, and she wishes she would have just used something like Ruby on Rails because they were just re-implementing so much stuff that that took them forever. Um so yeah, that's that's kind of the the main thing. Probably another another big moment was in the capstone presentation. We added an HTML to PDF uh generator, right, where we'd have like an invoice that was in HTML, and we were able to just install the Wicked PDF gem, and it just worked like magic. And I remember uh when I was presenting it, one of the students raised their hands like, how did you get it to go from HTML to PDF? And I, you know, I think they were expecting some like really technical answer. And I said, Oh, there's just this uh you know, this third-party library called Wicked PDF that we installed, and it just worked. And the class's reaction was just pure jealousy. And so Rails kind of in a way pampers us in that way, right?
SPEAKER_01Yeah, interesting. That's great to hear. Um, and I'm I'm curious about uh what you did with your dad's HVAC business. Uh tell me about that.
SPEAKER_00Yeah, so uh growing up, he had this little composite notebook that he'd carry around. And it was him and just like maybe two or three employees. And so he'd fix and repair people's furnaces and air conditioners. But I remember one day at the airport, I was probably in high school, and he lost his notebook. And it was like the biggest disaster ever because he would have three weeks worth of jobs lined up with the addresses, the customer's phone numbers, all these things. And so every time he'd lose his notebook, like time would stand still, and we'd have to go scour the airport, we'd be calling them, we'd be like looking everywhere for it. And he did have a little uh kind of like spreadsheet of his customer information, but none of that held the time of the appointment, any details about what what was going on, or even their addresses. So he just was totally screwed whenever he would lose that. So that's kind of where you know the idea came from. Hey, I have to do this Gapstone project. Why not do something that's useful for my family and for him? And that's build a scheduling app, a customer database. We'll build some invoicing into it. And that's that's kind of how it all started.
SPEAKER_01Oh wow. Um, and did your dad actually end up using that in his business?
Field Work, Invoices, And UX Lessons
SPEAKER_00He did, but it was very painful to get him to use it at first. And this was definitely there's definitely a lot of lessons just around entrepreneurship and startup stuff in general from this, but um definitely we had the uh solution in search of a problem. So when the computer science program tells you you have to build software, right? Suddenly you start looking for problems to solve with software, right? Um, but ultimately we did get him to use it. It was after the capstone, and it actually took me riding alongside him in the van, trying to get him to use it, and him pointing out every single flaw and every single wrong thing about his invoicing, about all these assumptions we had made that were just incorrect, and me riding alongside and programming it, you know, using Ruby on Rails and making changes in real time, pushing out updates, having it deploy, and then having him test it. And eventually we got him into a good kind of habit loop centered around the invoicing was the main the main thing that kind of took hold. And then estimating and scheduling and everything kind of grew from there.
SPEAKER_01Yeah, I think that's worth noting. Like the fact that you actually rode with him and you were like in person with your dad, uh, gaining an understanding of of what he did. Because like there's this there's this idea in software that you're supposed to like listen to your customers, which is like not exactly wrong, but it's like not nearly deep enough. Um because your customers will tell you all kinds of stuff, but there's a bit of a game of telephone, um, like even though there's very few people involved, like there is the day to day-to-day experience that the customer has, and then they perform a translation um unconsciously in their head, um, and they try to communicate to you what what they think you should build. And if you just listen to that and do it, that's a total, frankly, abdication of responsibility. What you should do is is go and understand the customer's world and understand their job, and listen to them also, of course. Um, but you have to be the designer, don't outsource the design to the customer. Yeah.
SPEAKER_00Absolutely. They'll tell you what they think the app needs, such as a certain button here or certain input field here, but like they don't they don't really know, right? Like they're they're kind of uh yeah, they you know they'll they'll say they'll say that, but yeah, that's dig deeper, you know, ask why um you know, five times, do it, do it yourself, go through the workflows yourself. A good example of this is we had the invoicing interface, and a lot of softwares, they kind of have like almost the QuickBooks style of invoicing where you have these like line items and they're all basically input fields, right? You got three or four input fields, you add a line item, there's five of them. And um, but as you're editing or creating the the invoice, it doesn't actually look like the end result, really. Um it's just a lot of input fields. And then you have to go into a second step that's kind of like a preview step that shows the actual printable version of the of the document of the invoice. And for whatever reason, um when I was trying to get him to use that, which was that's the version we had built in the capstone, he was just totally confused. And you know, going from a paper notebook and uh from that kind of system to a system of a bunch of just input fields, like really confused him. And you know, to your point, kind of the jump I had to make was he needs to see something that is going to look like the end result. And that's where we actually created the basically the user experience was that the invoice looked exactly how it was going to look when you presented it to the customer, and he would just click onto the fields and they would become editable when he clicks onto the actual like place where the data is is held, such as the description on the line item or the quantity or things like that. So yeah, I totally agree with what you're saying and had to learn that lesson the hard way.
SPEAKER_01I'm I'm really curious. In this process, did you ever show your dad something and like it was like different from how he expected it to look or something, or like he used something and you felt like he used it wrong, or like he didn't get it? Like you you felt like your dad was wrong when he when he was looking at something. Did you ever have that feeling?
SPEAKER_00Um I can see how that could be common. I think my approach from the beginning was very much like like I would find him, he would always be apologizing, like, oh that's just user error. That's my fault. Right. My response was always no, no, no, that's that's not your fault at all. Like that's that's a flaw with the system. Or he would, you know, he would think, oh, I just have to know how to like do this workaround or do this thing, you know, sorry for bugging you. And I think that's the I don't I don't think that's the right mindset if you're the developer, if you're building a system, like you know, user operating error, um, usually there's a design flaw in there, right? If there's something that's confusing them.
Designing With Users, Not For Them
SPEAKER_01Yeah, yeah. It sounds like you have kind of a natural knack for you know what what all this is, I think, is usability testing. Usability testing and UI design, product design, and it sounds like you have kind of an intuitive understanding for it. Um and the reason I asked that question is because it's a really easy natural feeling to have. Like I'll show somebody something I designed and they like use it wrong, and I instinctively think, like, no, like you're wrong. You shouldn't want to do that. Um, but and I have to remind myself that they're never wrong. Um, the thing, if anything's wrong, it's the design. Because they're gonna do what they do. They are who they are, they live in the world that they live in, and the software needs to mold itself to shape them and their world, not the other way around.
SPEAKER_00Absolutely. There's an iterative kind of kind of process with it. And I would say too that I was I was always wrong. You know, I would create something and you put it in front of them, and this is why it's so important to get user feedback immediately, is you put it in front of them and you just see the confusion and you see them try to wrestle with it. And ideally, you wouldn't have to educate them how to use it, right? Ideally, it'd be close enough that within a couple of clicks or a couple of seconds looking at it, they can start to click, they can start to type. And it kind of, you know, follows that principle of least surprise where it just kind of works how they think. And what I would do is when I would see it clearly did not work, that's when you're kind of going back to the drawing board and you have to quickly make a change, put it back in front of them again. And I would even ask them as they're using it, you know, you know, what are your thoughts? Like I would always have the narrate, you know, kind of what they're thinking is, what they're trying to do. And in a way, too, it's like I never would like to sit down and like make this master design plan. It was almost this like software that was just evolving and growing out of the almost the desires that they would have. Like, you know, they'd be like, Oh, I just need a way for it to do this, and you know, maybe if there was a button here, and then you'd see that pattern across a couple users, and all of a sudden, like, oh, I need to add something there, I need to add a button. It's almost like the software is being pulled out of the marketplace, out of the user feedback in a very evolutionary kind of way. And that did lead to some designs that were not like super standard, and I would get feedback from other designers that would say this isn't a standard way to do it. And they could be right, but I also knew that the users understood how to use the software for that specific demographic, people like my dad, they were able to pick it up pretty quickly. Interesting.
SPEAKER_01Um how did you learn about all this stuff?
SPEAKER_00Um I think so. My first programming job, there was I had this experience where we had this big list of requirements that the project manager gave to me. And I spent a whole summer, this was like my internship when I was like a second-year computer science student, building to this list of requirements. And near the end of the summer, we give it to the client, and he's like, This doesn't work at all. You know, where is this functionality and this functionality and this functionality and this functionality? And the senior engineer that was mentoring me was like the project manager screwed up, right? Like he had taken the translations from the client and had put it into his own version of understanding it, and the client signed off on it, probably didn't double check it, and that's what I built towards for three months. And the senior engineer's response was the PM screwed up, this isn't your fault. Um, you know, whatever it was, we need to do change orders, we're gonna charge the client more, the client was upset. And my response was okay, but you know, let's fix this, and I'll just meet with the client directly rather than going through the PM. And the senior engineer was, oh, that's really nice, but you don't have to do that. But my thought was, I just want this project to succeed. You know, it's my project, I'm on the project, the client's not happy. And I just worked directly with the client, and they pointed me to the source of truth, which was actually a government reporting standard called NIBERS. It was like FBI crime statistic reportings. I'd be in a very specific format. And I just went to the source of truth and worked directly with the client and worked really hard. And by the end of the summer, we were able to still launch the project. And so um, I would say the takeaway I had from that was just how important it was that you work with the end user and the end client directly. And anytime you try to like think too far ahead or plan things out too far ahead, there's always a risk of like what you mentioned, kind of this game of telephone, or you're kind of trying to read their mind. But really, you just need to put software in front of them and have them give feedback and just iterate quickly.
Prototyping, Paper Tests, And Fast Feedback
SPEAKER_01Yeah, yeah, that's so great. I had the exact same experience repeatedly. Um, and I think maybe you learned a bit quicker than I did, but I would have the experience of gathering the requirements for something, and then I would go off and build it and Maybe it wouldn't be a client, maybe it would just be my boss. Um, and I would go off and spend a week and I'd build it, and then I'd come back and I'd be all proud and stuff, and I'd show it, and they'd be like, uh, this isn't what we talked about. I'd be like, What the fuck? This is like exactly what we talked about. Right. But there was there was the the feedback cycle was too long, and so there was too much room for me to go in the wrong direction. Um, so then what I switched to, I'd I'd read this book, which I've never heard anybody else talk about, and I keep recommending, and I I really want somebody else to read this so I can talk about this book with them. But uh it's called User Interface Design by Soren Lausen. Um it's this big thick book, but it talks all about usability testing. And so then I adopted this practice where I would get together in a conference room with somebody who was either a user or like representative of the user, and I would just um draw up wireframes with pen and paper. Um and I would I would act like the browser, like I would pass pieces of paper across the table and give them a pen. And I would say, fill out this form using this pen, click on stuff using the tip of the pen, and they would submit the form by passing it across the table to me, and I would submit the response by passing a different piece of paper back to them. Um and the first try almost every time was just like way off. We would be like dead in the water right from the start, and I would need to go back and fundamentally rework it. So I'd I'd learned that it was wasteful to put very much time into the first pass because no matter what I did, it was probably going to be wrong.
SPEAKER_00Um interesting. That's fascinating.
SPEAKER_01Yeah, and and I made sure to never ask them not never, but I wouldn't take an approach of like what do you think about this? Because if you ask somebody what they think, they will almost always be polite and be like, oh yeah, this this makes sense, this looks good. Uh, but then leave them alone with it and let them try to use it, and they may well be lost. So instead of that, I would give them a list of scenarios and tasks, and I would say, I wouldn't say what do you think, I'd say use this to do this particular task. And they can't fake that, they can't be polite and fake their way through it. They either can do it or they can't. Uh, and once I started following that process, things started going way more smoothly, and I would gradually get more sophisticated. I would start with paper wireframes, then I would build like a uh a quick prototype in real software and uh keep the investment proportionate to how much that that UI had been tested.
SPEAKER_00That's fascinating. And you're doing it with just paper, just drawing it out with a pen and then letting them react. Yeah, that's fascinating. I I think probably one of my flaws a little bit is when I'm doing that approach, I'm actually implementing that the software I'm putting in front of them. And even that, like, I mean, your feedback loop is what seconds in real time sitting with them. Um and so, yeah, definitely, definitely your approach is uh very interesting. And yeah, I can see how things could be different if I had started that way as opposed to the opposite direction. How do you how do you view this stuff changing now with uh kind of AI prototyping tools? I mean, I'm not sure if you play around too much with the you know some of the latest tools that are coming out, but even just HTML, CSS, JavaScript, uh prototypes. I mean, it's so it's so good. Have you have you played with with those much?
AI Prototyping Tools And Pitfalls
SPEAKER_01I use cloud code very heavily, but I I think I'm like really behind on a lot of stuff. I will comment real quick that like I try hard to make a distinction between principles that will never change no matter what, and other stuff that will change depending on the tools and stuff like that. Obviously, like understanding the user's world and understanding what you need to build, that's never gonna go away. You can't just tell the AI to like go get an understanding and you build it, and I'm not gonna bother to understand it myself. That's never gonna make sense. But what what what what do you mean when you when you say uh when when you refer to these tools? What kind of stuff?
SPEAKER_00I mean, even tools like like lovable is a great example. Have you heard of Lovable at all?
SPEAKER_01I've heard of it, I've never used it.
SPEAKER_00So it's a it's a browser-based coding tool. Um, almost as if you had quad code, but the chat interface is accessed through a browser tab, and then you have like a little iframe app preview on the right-hand side that will kind of show the app in real time as it's being built. So a lot of people talk about how this is great for prototyping, right? Maybe not so great for production, but great to kind of put ideas out there, put it in front of users, give them a fully clickable prototype. They can change pages, change different things, um, those those types of things.
SPEAKER_01I think that kind of stuff is a little bit dangerous because I I've I've encountered situations before where you show somebody that you show somebody something that looks polished and it looks superficially like it's almost done. Like, oh, this is great, when can I start using it? It's like, uh, give us like six months. And it's like yeah, I'd I'd rather start actually by showing them something really, really rough. And there's this other thing, this kind of pet peeve I have. Um you can make something that looks graphically very impressive, but from a usability standpoint is still very poor.
unknownSure.
SPEAKER_01But having said that, I I also want to be very careful not to dismiss any of these new tools, and I want to evaluate them thoroughly to s to see if they can help. Have you found that kind of stuff helpful?
From HVAC App To Field Rocket
SPEAKER_00So as far as lovable and bold and those types of tools, um they can be they can be helpful to get ideas out there quickly. Um but I think that obviously there's always a deeper level of engineering that that goes into it. And so um, you know, kind of so eventually I'll just tell the story really quick and I'll lead into kind of where I'm going with this and where it's interesting, this kind of idea of prototyping quickly with users. So my dad's company started using the app that we built them and iterated very heavily with them. We were doing invoicing, we're doing job scheduling, and the company grew pretty rapidly. We also implemented some kind of new marketing and sales things. We now had like a source of truth for the customer records, all the employees could access. Employees could access their own schedule, they could do their own invoicing. And then we also started to focus a little more on sales and marketing tactics. So the company grew pretty quick. Um, we had kind of doubled, we doubled the revenue, the profit went up very quickly. Uh, we you know tripled the profit, and we actually ended up, I was a partner with him in the company at that point, and we sold the company, um, which was great. He was a little bit older, and I was kind of wanting to exit uh that space, but we sold the company, and then I took the software from the company, and that's where I started my first startup, which was called Field Rocket. So I kind of launched that into its own product. I did that for a minute. One of the things with Field Rocket that we realized too is we started with a solution in search of a problem, which we were building software for residential contractors. And what I learned taking this to market is that people like my dad, you know, these smaller companies that didn't have an office manager or receptionist, you know, they had five employees or less, they really did not want software. They're pretty happy with their composite notebook, right? And or they'd use their phone's calendar, they'd use whatever it is. And that was a tough and bitter pill to swallow. But we did what we learned they did care about was getting jobs and growing their company and those types of things. So one of the things we started doing is we made a little database table that could store HTML code, and we added in web pages to the application where they could build their own little websites and web pages. And at the time, this was when uh ChatGPT had just been released. And so we started using ChatGPT to generate these web pages and put them into the database table and render the actual page. And this was definitely something that we got a lot more interest in when we were taking this to market. We kind of repositioned the company to not be like, oh, we'll help you with your scheduling and your invoicing and your operations. We repositioned it like, oh, we'll help you grow, we'll help you get clients. And that definitely helped unlock a lot of energy and momentum. And that's when we actually started to get something closer to product market fit, where you have uh the market, they're willing to pay you more. They're usually a lot of these guys were paying marketing agencies almost a grand per month to do things like website work and blog posts and those types of things. And so we were able to kind of position against that and charge a lot more and get a lot more interest. What we realized too is when we were building these web pages, is we saw a very clear progression from where the large language model started to get a lot better with the code generation. So it started off with HTML pages that were pretty bad. And we so we kind of started with the template and we would like tell it, just replace the business name, here's the phone number or the address, and the LM was able to do that kind of stuff. But when Claude 3.5 uh Sonic came out, that's where we saw actually a big leap forwarding capabilities where we were able to have Claude create very original HTML pages and just put it into the database. And we were just doing so many of these because it was part of our sales process, that we kind of realized, oh, this is gonna be a thing where you're able to just like have an LLM generate code and then it shows it shows it in real time, it shows it immediately. And it was just so much fun that we kind of realized, oh, you know, um what if you had a little chatbot rather than us going to the you know uh Claude Vaud's web portal and typing in, telling it to do it and copy and paste it. What if we tied it into the API and we had a little chatbot where the user could type in what they wanted? And then it would just put the HTML directly in the database, refresh the page. And so that's when we that's when we kind of started going down that path. And showing that to people, this was in 2024, definitely got a really strong reaction. And that's when I realized, hey, I don't want to be selling marketing and lead generation to contractors. Like this is so much more fun. I'm having a blast. I'd kind of lost a little bit of the enthusiasm for the business. And the reaction I was getting from people by showing to them made me realize, oh, we need to pivot. And that's where we pivoted into Llama Press, which was there is you know a chat interface that you would talk to and it would generate code, put it directly in front of the user, refresh the page, and that's kind of that's kind of how we pivoted and got into that space.
SPEAKER_01Interesting. And I'm curious what makes you say like you didn't really want to sell to contractors and stuff that much anymore.
Finding Product Market Fit Through Marketing
SPEAKER_00There's a couple things. One thing was that the business model uh, you know, it's a very tough kind of business. And we definitely fell into a trap a little bit early on, especially before pivoting to the marketing stuff, where we were like, wow, there's no competitors in this space. There's so few, right? Like this is amazing. Look at the opportunity. You know, you look up the data, and there's millions of these small contractors across the United States, across Canada, across Mexico, let alone around the world. And so our thought process was wow, it's a wide open market. And then you realize, you know, two years into it, you know, maybe there's a reason. There's no companies. Maybe there's a reason. Yeah. Yeah, maybe there's a reason. Um, so you know, part of that goes to the idea of like they're they don't want technology, they don't like they have their notebook and it works. And they'd be like, well, don't you want to grow? Don't you want to grow the company? Don't you want to like make more money and all that? And the answer is quite often, no, I'm good. Thank you, though. Right? Like they're happy, they're you know, they've got a good business, they can make good money, you know. And this was my dad for years. You can make good money, you can support a family, and you don't have to worry about all these things that you don't really that you're not comfortable with, such as technology and you know, the cruel basis of accounting and business management and all this stuff. You can just build a really great business and you have customers that love you, and that's that's plenty for for a lot of people. And so we kind of realized, oh, we positioned ourselves in a part, you know, in an industry and sector of the economy that just has some structural challenges. So that was that was one part of it.
SPEAKER_01Uh-huh.
SPEAKER_00Um and then the other part was just I really miss just working with other engineers and working with people that uh come from that business background and working with a little bit of larger companies. Whereas a lot of the people I spending time with and talking to was more of this contractor type, which I love deeply, right? That's where I come from. Um, but also they they don't know anything about ChatGPT or LLMs. Like it's not as exciting to them. And I spent some time in San Francisco, got really excited about the people I was meeting there, the conversations, the energy, and that's also what kind of led to this pivot. And so yeah, I I'm very happy about that, and uh definitely definitely something I don't regret at all.
SPEAKER_01Yeah, that's so interesting. Um, I had a similar experience. So the the the product that I'm working on now is developer focused, and it's the thing that I've spent the second most years on out of anything I've worked on. Um but the thing I've spent the Saturn Saturn CI. Mm-hmm. Saturn CI. Um the thing I spent the most years on was scheduling software for hair salons. And I learned some of the some of the same lessons. Like I looked at the offerings and I'm like, wow, all the software for salons is like terrible, like all of it. Um and later I learned that there's a reason for that. Um, it's because it's a really hard market to go after. Um uh stylists and salon owners uh are are cut from a different cloth than people like me. Um and I found the same thing. Like a lot of them didn't want technology, they were totally happy with pen and paper, um, and they were not interested whatsoever in business growth or anything like that. Um and it took me a while to learn that like uh there are different kinds of people, and not everybody thinks like me. And it's like, why would you not want more money? Why would you not want to grow your business? It was like incomprehensible to me, but there's different kinds of people, and it took me a long time to like figure out to like mentally model that kind of person, and it's just a totally different kind of person, and that's probably not the kind of person you want to go after. They're great people, but it's like that's great people, but not the best customers to go after if you're like a solo bootstrapper. Uh you don't want to play it on hard mode.
SPEAKER_00Yeah, absolutely. Absolutely.
SPEAKER_01Yeah.
Pivot To LlamaPress And Why
SPEAKER_00Yeah, great, great people, hard workers, you know, and very down-to-earth and very um but you know, you gotta find your tribe and the people that get excited about technology, and so yeah, it's uh definitely a lot of lessons, a lot of lessons in there. So this is your second, your second, I guess, company that you're you're doing is the Saturn CI.
SPEAKER_01Yeah, it's it's a lot more than the second one. There was a lot in between there. It's just uh the it's the one I've spent the second most time on. I I cycled through a lot of ideas that were like, you know, I just barely got started and then abandoned it because I decided it was a bad idea or whatever. Um, but a difference with this one is it's not speculative, it's it's not a novel idea, it's not experimental. Like I know that people need CI. It's an existing product category. It's pretty much apples to apples with like circle CI, GitHub Actions, that kind of stuff. Um do you use something like that for your product?
SPEAKER_00Yeah, we I we just use GitHub Actions, but but it's relatively you know, somewhat new to me, actually. You know, I um with Field Rocket, all that stuff, I actually just had a Git hook that would run my system tests or run all my test suite locally before allowing it to do the push. And then I recently I've come around to the to GitHub Actions and um over the last you know six months or whatever, 12 months, and it's yeah, it's been amazing. So definitely useful to have that, especially as you have like other developers and team members and that kind of stuff.
SPEAKER_01Yeah, yeah. So again, it's an existing category. You know, look if you know what GitHub Actions is, then you know what Saturn CI is, basically. It's just, in my opinion, a better version of that same thing. And what that allows me to do is it allows me to totally commit. Like I know that there's probably never gonna be a reason for me to abandon this idea. Like I'm never gonna discover that for some reason this isn't a good idea. I can't imagine what that possibly could be. Um and so I can that allows me to know that if I'm not succeeding, it's not because it's a bad idea that's doomed to failure. It's just because I'm not doing a good enough job yet. And that's a very it's a feeling that I really like because it gives me like certainty and it it shows me very clearly what I need to do, and I I don't have the struggle between like, am I being stubborn or am I um uh just not being am I being persistent and I'm right about that, or am I being stubborn and I'm wrong about that, you know?
SPEAKER_00Have have you read any of the Paul Graham essays?
SPEAKER_01Yeah.
SPEAKER_00Yeah, he has one that's yeah, reminds me of what you're talking about a lot. Just which which is it's tough, right? Because being an entrepreneur, uh pretty much every entrepreneur is going to be stubborn and disagreeable to some extent, right? I mean, you kind of have to be to do that. And yet it's like this weird skill of knowing when to be stubborn and when to be flexible. And that's hard. It's it's really hard. But I I like how you frame that though, and I like what you said earlier in the conversation about like what's true today that will always be true. And sounds like what you've kind of circled around is developers are gonna want you know continuous integration and automated testing and uh cooling around that. And so um I mean you need it yourself as a developer, right? So you're kind of your own first user, your own user in a way.
Saturn CI And Choosing Certain Markets
SPEAKER_01Exactly. Yeah, and it's a pain that I've felt. Um, and it, you know, not everybody feels this way, but I use Circle CI and GitHub Actions, and they just really like uh rubbed me the wrong way. And and so I'm like, this I hate this. And years went by, uh, and like nothing got better with any of these products, and finally I was just like, fuck it. Like, I don't care if this. This works out as a business or not. I'm just like so unhappy with the existing offerings that I'm gonna build something myself that I can use. And I got far and and it's a huge technical challenge. Uh the existence of AI is the only reason I even felt like I could take a swing at building the thing at all. Um anyway, I'm I'm curious with your like pivots and stuff like that. Did you did you have that struggle between like persistence and stubbornness and and stuff like that?
SPEAKER_00Yeah, I mean, I still have that struggle, right? Like I I haven't hit my big breakout moment where I'm like, you know, a gazillionaire. And I've also realized that that's not that's not even the the main point, you know. Um obviously you want to have that breakthrough moment, but it does come into one of those moments of just like you know, that does deeply kind of touch your identity and who you are and what you're doing and why you're doing it. But you know, I think I think the pivot into AI generated code and building Ruby on Rails applications and building a product more around that ecosystem in that space, as opposed to building something for residential contractors, um, was kind of that realization of just if if I spent 30 years, 40 years doing this and never had that big breakout success moment, what would I rather be doing? Would I rather be selling to businesses that I'm kind of selling to just because I naturally kind of fell into that? And that was kind of where I thought there was an opportunity, or would I rather be doing something that's a lot more intrinsically exciting and motivating and aspirational? And the answer is pretty pretty clear to me. And then the other thing is just seeing the energy and the big unlock that's come from large language models and how good they've gotten, and as we've scaled these things up and their capabilities have increased, that I know if I were to look back 30 years from now and I spent my entire career chasing this this other this other space, that I would regret that. Like it seems like we're in a pretty potentially transformational period, um, especially for IT and software development. And so I'd be kicking myself if I didn't you know jump into that, especially especially just seeing what I saw and kind of knowing where the trends are going and being an early user of those tools.
SPEAKER_01Yeah, yeah, that totally resonates resonates with me. I'm so glad that I left the salon stuff behind, because like you know, frankly, I have no interest in any of that stuff. I don't care. Sure. Um and so you don't care about people getting their haircuts and hair dyed. Right.
SPEAKER_00Um, so to to be doing this your dying passion in life, exactly.
SPEAKER_01Um it was only a means to an end, you know. But with the stuff I'm doing now, it's more intrinsically interesting. Um so I'm I'm curious about your product now and and where it's at and where you're trying to go and all that stuff.
SPEAKER_00Yeah, so so we started with basically a chatbot that would build HTML pages. So static, you know, HTML, CSS, JavaScript pages. That's how we started. And we made the full pivot back in August 2024. And so now we're about a year and a half in. And I made another pivot in about it's about July or August 2025. So we kind of bridged our way into a chatbot that builds web pages, and that was kind of the original Lano Press idea. And we were really inspired by WordPress. So, I mean, really just inspired by open source in general. But WordPress is a really fascinating um story, and something like 43% of all websites are WordPress as of like 2024 or something. And it's pretty mind-blowing because if you look at WordPress, if you've used it, have you used WordPress at all? Oh, yeah. Well, what are your thoughts? Like, how how's the user experience in WordPress to you?
SPEAKER_01WordPress is a colossal piece of shit.
Persistence, Pivots, And Identity
SPEAKER_00Right. Well, I mean, a lot of so so what's interesting is when you tell people WordPress powers 43% of the internet of all websites, the response you get from a lot of people who don't know that is, what the hell are you talking about? Right. And so there's this cognitive dissonance that I that I had in 2024, you know, as all this stuff is going on, I'm thinking about pivoting, which is how can something that has such a negative reputation in many ways, of course, there's it has a positive reputation in many other ways. If you have people who are power users of it, they love it. But for the vast majority of people, if you talk about WordPress and you tell them that it powers 43% of the of the internet, it blows their mind. And so there's that piece of cognitive dissence like, why? Why is that? And I'm curious, like, what do you think? Like, if you had to give an answer, like, why does it dominate so much, even though the user experience is is pretty terrible, if you were to ask most people.
SPEAKER_01Oh, that's a good question. And by the way, for the user experience, I think that's really not that bad. Um, it's just if you have to get into the internals at all and deal with it's like super broken, incoherent uh conceptual model, uh, that's when things fall apart. And the plugins and just any kind of non-trivial maintenance, that's when things fall apart. Um I don't know why it has gotten um so prolific, but it's like good enough, and there's probably some factor of like right place, right time, that kind of stuff, and other like incidental historical accidents and stuff like that, but I really don't know.
Why WordPress Won And Open Source Power
SPEAKER_00Yeah, yeah. I think I think those are definitely um definitely components of it, and I agree with them. I think that I think that if you go back to 2004 when Matt forked WordPress from this other tool called it's like I think it was like B2 Cafe or something. It was this other kind of previous blogging tool that was open source, and he forked it to build WordPress after it got abandoned. The project got abandoned. In 2004, that's when there was this big kind of craze around blogging. And back then, a lot of web development was direct HTML, CSS, JavaScript, PHP, right? Like you had actual developers who were like hand coding these things. And so he he created like a tool or you know, with the fork that allowed people to publish a blog, which that's what they wanted to do. They wanted to have a website and put content on there, but they didn't have to know anything about HTML, CSS, JavaScript, PHP, they didn't have to hire a developer. And he made it completely free. It was completely open source, it was completely free. He had a five-minute deploy, like the famous five-minute deploy, where you could take any server, like Linux server, run a little install script, and you'd have a working WordPress interface within five minutes, and you could like register for your account and then set up the blog, all that kind of stuff. They also built themes into it and later plugins, um, which was also kind of wrapped in this GPL open source license, which made, which meant that any theme that you purchased or used, you had access to all of the source code uh just by the license terms. If you develop a theme or you develop a plugin, you have to expose the source code uh to the to the person that purchases it. And they also have the right to modify that source code if they want to. And so with those kind of key pieces and just being at the right place at the right time in 2004, um it was free, it was much cheaper, it was much easier. And then over time, they grew these network effects because it was free, because it was so easy to set up. You got a big install base, then you had a bunch of developers that were building plugins and themes, and it branched out much bigger than just blogs. You know, there's plugins for you know e-commerce, there's plugins for uh user management, like you can build all sorts of things with it. So it's really an amazing story. And I think to me, it just speaks to the power of open source and free software. And you know, a lot of people too, especially in when I, you know, my business friends I've talked to in San Francisco, they don't understand open source. And they think, well, you're basically a charity, right? You're giving away all this stuff. How are you gonna monetize it? You know, uh you're gonna have Wix, and you're gonna have Framer, and you're gonna have all these other tools completely destroy WordPress's market share, and you know, it's doomed and all that stuff. But what you realize is that, you know, if you look at Matt Molenwig and you look at Automatic, which is the company around WordPress, he's not hurting for money. He's made he's made hundreds of millions of dollars. Automatic is worth, I think, over$4 billion as of 2026. And so they're not hurting for money at all. And so the power of free software at the right place, at the right time, and the ability to extend through plugins, through customization, through these types of things, I just think has massive competitive advantages. And also clearly it's good for the world, right? You're giving a massive amount of value away for free. So something about that story really resonated with me. And he had come and spoken at a conference in Salt Lake, at the Silicon Slopes Conference when I was living in Salt Lake, and he basically challenged the audience. You know, he told his story about WordPress, and he said, you know, if you're thinking of building a software project, consider open sourcing it, consider doing what I did. And you might be surprised like how well that works out for you. And that just kind of really stuck with me. So around that same time, you know, the question I had in my hand, in my head, was what is the 2024 analogy, right? So if WordPress or something like WordPress was built in 2024 instead of in 2004, but it followed some of the same principles, you know, you you had that great point of what's true today that will always be true. If you kind of followed the same kind of philosophy about um open software and and networks and those types of that type of thinking, what would that look like in 2024? And that's kind of where the idea of Obama press uh started to really take hold. And you know, it kind of goes a little more philosophical as we kind of look into the future. But what is the future of software development and what is the future of new software that's being created? You know, we're not just creating blogs anymore, we're creating much more sophisticated applications. Um and so yeah, I'm curious, I'm curious what you think about the future of software and the cost to develop software and all those. I mean, you you said you're using cloud code.
SPEAKER_01Yeah. Yeah, and wow. Uh I just gotta say that I'm like blown away by that because it looks like it sounds like you really went and developed a deep understanding of the whole trajectory of all that and why it happened and and all that stuff, which is uncommon. Um I think in American culture, uh creativity and brainstorming and stuff like that are really valued. Um, but unfortunately, research and knowledge and understanding are relatively undervalued. And so to go and and gain that deep historical understanding, uh I really respect that. Um the future of development, I don't know, and that's not something that I necessarily think about very much. I mean it is, but it's so it's so unpredictable. Uh one thing I definitely believe for sure though is that AI assisted coding is never gonna go away, it's here to stay.
SPEAKER_00What what makes you say that or think that?
SPEAKER_01Oh, just because like why why would it go away? Like it's obviously so helpful and it's only getting better and better, and like yeah, you you can pry it out of my cold, dead hands, you know, and pretty much everybody else who uses it feels the same way.
SPEAKER_00Yeah, like how would you feel if they just cut off your access to cloud code?
SPEAKER_01I would feel about the same if they had like cut off one of my hands.
What Programming Will Always Be
SPEAKER_00Yeah, yeah. Yeah. It's power, it's it's so powerful. It's I had a friend who they were doing like a research project. This is in San Francisco, where they were trying, they were basically, they would they said, okay, look, you're doing an open source project, right? I was like, Yeah, it's okay. We'll pay you$50 an hour to work on your own open source project. And all you have to do is before you do an engineering task, you submit the task to our web portal, and then we're gonna randomly pick if you can use an AI coding tool, or if you have to do it like the traditional old school way, like no LLM assisted coding. And the offer was essentially we're gonna pay you$50 an hour to work on your own project, which that's like, you know, for a for a bootstrapping entrepreneur, that's you know, that's pretty good, it's hard to beat. And yet when it came time to use it, I just I just couldn't. There's something to me that feels like the opportunity cost of being able to use these AI-assisted coding tools was larger than$50 per hour, which is a bounded, clear, kind of expected value,$50 per hour. Whereas what I'm working on now with with Law Press and my startup and all that, it feels infinitely larger the opportunity cost to not be able to move as quickly as possible, to not be able to use these tools. And so ultimately um it just the math just didn't make sense to me. But so I I totally agree with what you're saying. It's like an extension of yourself at this point. It'd be like it'd be like them trying to say you can't use Ruby on Rails ever again, right?
SPEAKER_01Like that would be absolutely catastrophic to be like, yeah, or just like trying to do some arithmetic with no calculator or something like that. It's just like, why would I do that?
SPEAKER_00Yeah, yeah. Yeah, so I I totally agree with you. I just I just don't see it. The genie's kind of out of the bottle with it. And so as far as like developing software, it's just so much faster to use these tools and so much more fun as well, so much more enjoyable. It takes a lot of the drudgery work out of um you know the debugging cycle and the researching cycle, and you have to look up on Google and Stack Overflow, and that's so much just kind of drudgery to get to the same end result of just seeing the app do what you want it to do. Right. And so that loop is so much smaller now. But it's so interesting too because we have all these conversations going on in the media and around the world about like, you know, are we in a are we in an AI hype bubble, right? And I don't know, what are what are your thoughts? Do you think there's a there's a bubble going on here?
SPEAKER_01Well, I think that's not really the right framing. I think there's a lot of bubbles, but I don't think there's a bubble. Um there's you know AI is overhyped and underhyped at the same time. Um and there's there's a lot of different stuff going on with it. So like, yeah, there's there's bubbles, and those bubbles will pop, but it's not as though it's just one thing that can either be a bubble or not a bubble. It's too uh multifarious to be looked at that way.
SPEAKER_00Yeah, yeah, it is interesting. I know there's a lot of money, a lot of money being put into the infrastructure and the data centers and all of that. I I agree, it's like it's too broad to just paint with the paint with the broad paintbrush and say, oh, you know, this whole thing is just this hype and it's like this bubble is gonna pop. You know, there might be market corrections, there might be things like that. But if if you look just at the AI code generation space, clearly to me as a user, this is this is a completely different paradigm as opposed to five years ago. Like a completely new set of rules. Um, it's just unleashing so much productivity. And I think that like people, it's like it's almost like people who are closer to AI generated code, like you know, in the IT, like deeper in the IT stack on the engineering side. To us, it clearly doesn't feel like a bubble because you can see it in real time. Like it's just so obvious. But as you get farther out from that kind of epicenter, which that's one of the best best use cases right now, is AI generated coding. Um, as you get more maybe into the business world or people who aren't touching code on a daily basis, what are what are their benefits? I and I know like the researching tools, like the deep research is helpful, but I just think that maybe when you're as you get farther out from that kind of epicenter, maybe that's where things start to feel a little bit unclear as to why people are so bullish. I don't know.
Rails Leverage, Abstractions, And Bets
SPEAKER_01Right. Yeah, it's it it reminds me of that expression that the future is already here, it's just unevenly distributed. Um because like, you know, there's hairstylists and uh HVAC contractors and whatever who don't really have any interest in using computers, period. Um and they're still they're still making new ones of those, you know? Like there's there's like young people who are like not into computers, it's not just an age thing. Um and and I don't know if I want to say most people, but a sizable proportion of people just fundamentally don't get it, and including a lot of programmers. Um it just like they they don't really, it never occurs to them how AI could fit into their work. And that's really interesting to see. That's not something that I would have predicted. Um, but a lot of times when like I don't know, like okay, this is not exactly a new thing, because for the last like 20 years of working with other programmers, um, somebody would be coding and they encounter an error message and then they like stare at it and you're like, huh. And and I'm just like, bro, like don't think about it as the first resort, copy and paste it into Google and see what comes up. And then if if nothing comes up, then like think more deeply about it. But like you're wasting precious mental energy on something that the computer can do for you. And it's the same with this, like you encounter an error message, uh, like don't think about it, just copy and paste that into an LLM. Or, you know, now like don't even not be in the LLM in the first place. Like, just be in clawed code all the time so that when you get an error message, uh, you don't even have to do anything. It just automatically sees, oh, I see that this went wrong, let me try to diagnose that bug, whatever. But that's I I don't know what proportion of developers are working that way, but certainly not everybody.
SPEAKER_00Yeah, totally. I mean, by the time you even consciously are realizing that there was an error, Cloud has already tried two or three different solutions, right? If it wasn't able to figure out the first workaround attempt, it's already trying a second or a third. By the time I mean sometimes I'll go and you know get my cup of coffee and go by the fridge, and you know, you always gotta check and see what's you know, a little snack can I grab. And by the time I get back to my desk, there was an error, and Claude worked around it, maybe tried two or three things. The third one worked great. But maybe that's dangerous. Like I had a reaction on LinkedIn where a guy was pretty unhappy where he he basically said, Um, you know, there's gonna be a day where all the code that you're generating is gonna break, and you're not gonna you're not gonna understand it well enough to fix it. And there's definitely a truth to that. Like even with a lot of the stuff that I'm building now, there are certain things that I know if there's like an issue, I do have a little bit of a feeling of like, ah, damn, like I know that I don't know how that works perfectly, and I'm gonna have to go and look at it. But then that's I think where being an engineer does always have that advantage because you always have yourself as the backstop. Like if you ever really need to like get down into the nitty-gritty details for whatever reason, if Clot Code can't figure it out or any other tool, then you can still go and read the code and you can peel back into whatever libraries you're working with, you can think through things, but you're doing all that stuff with a thought partner as well that can maybe help you troubleshoot and debug. So even if that is true, that is true, that's that's also true for like engineering managers that manage a team of developers. They're not going to understand the nuances of every single detail. But if they needed to get in there deep, they could go and they could read the code or they could have a senior engineer with them and they could like kind of brainstorm and think about it. So um, I don't know. Do you think there's a risk of us just kind of turning over our mental faculties to the or in our in our engineering instincts to the LLMs?
Framework Trade‑offs And Maintainability
SPEAKER_01Yeah, that is one of the mistakes that I always try to caution people against. Um is like there's there's two mistakes you can make. One is to like use your um finite brain power to do something the computer could have done, and that's a mistake, but you can also like delegate too much to the machine and pay less close of attention than you should have, and the computer does something stupid and you didn't notice, and and then you create a problem for yourself that's a ticking time bomb that's gonna blow up at some surprising time later on. And I I look at all these things as um bets and risks and investments and payoffs, and this is something that's been true before AI, and it'll always be true. Um every time you write a piece of code and you either invest time into making it easy to understand, or you don't, um, you're making a bet. If you spend time making it easier to understand, you're basically making a bet that says uh my investment policy is to make my code easy to understand with the expectation that my overall investment portfolio will give a positive return on investment. I know that not every single individual investment is going to have a positive return, but in general, my expectation is that this policy will have a positive return, otherwise I wouldn't behave this way. And when you do the opposite, when you don't take the time to make something easy to understand, you're saying that I'm I'm making the bet in the other direction. I'm I'm betting that I'm not gonna have to uh understand this code later. And if it turns out I'm wrong, then I'm gonna pay a price for that later and I'll end up upside down on my bet. And I think everybody makes bets in both directions. I know I do. Um my default bet is to bet that I'm gonna have to understand it, because the vast majority of the code in the code base, you're gonna have to understand it again later at some point. But if there's something that's like if you think of a code base as a tree and there's a trunk and branches and leaves, if there's a piece of leaf code that nothing else depends on, and maybe it's it's really cheap just to even blow that leaf code away and rewrite it from scratch, who cares if it's easy to understand or not? Uh, that's a bet that you can afford to lose. But if it's like a deep uh architectural design or something like that, that's an area where you uh it's a much smarter to bet that you're gonna want to make that easy to understand because so much stuff depends on it. And if it's hard to understand, you're gonna pay a big price.
SPEAKER_00Yeah, no, it's really interesting. I mean, very relevant to startups because you're placing many different bets across the entire life cycle of building, and the stakes are very real, right? Like time is a very real factor that you have to like always just be pushing and pushing and pushing, and you're like threading a needle constantly. Um but but also another thought that comes up while you're talking about all that is it does make me think a little bit about Ruby on Rails and the tooling and the benefits that you get from using a framework like Ruby on Rails, just in the sense of how much farther you go with Ruby on Rails versus other versus other frameworks, and kind of you're placing these bets, but with Ruby on Rails, in a way, a lot of these bets are like de-risked a little bit, right? Because there's certain I mean have you have you worked with other frameworks uh very very much besides besides Ruby on Rails? I'm curious to hear your perspective about like the Rails advantage and you know how that's relevant to these bets and the time frames of developing these products.
The Cost Curve Of Change In AI Era
SPEAKER_01Yeah, that's an interesting question. Before Rails, I used uh the Symphony framework for PHP and also a framework called Zen for PHP, Code Igniter, um, maybe some others, pretty much all PHP stuff. Um, and there was a lot more manual work, especially in Zend. It was like Zend was barely anything. I don't even it's hardly fair to even call it a framework because they give you so little. Um, but Rails gives you abstraction and leverage. It like there's conceptual abstraction where you don't have to understand as much stuff. There's like, for example, the whole uh HTTP life cycle, a lot of that stuff is abstracted away, whereas with like Zend or something like that, you might have to deal with that stuff a lot more directly. Um and then you get abstraction in terms of the work that you do, like, for example, with creating a scaffold, you can manually create all that stuff, or you can just get the same exact thing that you would have created anyway by running a single scaffold command. Um and so I don't know how that might relate to this idea of making bets and stuff like that, but it definitely gives you abstraction and leverage.
SPEAKER_00Yeah, or like maybe part of what triggered that thought process too is like, you know, for I mean, for I mean, even yeah, you mentioned the HTTP lifecycle, that's a great example. Another example is even just SQL code, right? Like, you know, the active record model and all that abstracts away so much SQL code, and obviously for more complex queries and things, then you you end up wanting to try to write your own SQL code anyways. But one of the contracting gigs I took on, they're using TypeScript and just directly connecting to a Postgres database. And also they're using Docker and some other things. I remember having a moment of, you know, it was my first kind of project with TypeScript. There was a learning curve, and a lot of the code that had been generated, um, yeah, I think this is true of many other frameworks, you know, JavaScript or Python, is you're making these engineers are placing these little tiny decisions and like these little tiny bets. Little tiny just micro decisions. What do I name this file? What do I name this folder? How do I put my folders in relation to each other? Little tiny things like that. And then also the SQL code, like you know, how you're writing the SQL code, all that. And I came to this realization of wow, did I screw myself in some ways of over-relying on Ruby on Rails in the sense that there was so much friction and so much annoyance dealing with this code base? And one could make the argument, oh, well, Ruby on Rails is dangerous because it insulates you from the real world, it insulates you to where you don't have to worry about these smaller details. And maybe it even like I felt maybe I'd been a little bit pampered. And so, in that sense, like, you know, in terms of the argument you were making, which was interesting, is like, well, you're gonna have to understand it on a deeper level at some point, anyways, right? And so maybe it makes sense to understand that that code. Like, there's kind of a maybe a parallel analogy here of like understanding deeper nuances of of a code base versus understanding deeper concepts like the HTTP lifecycle or or Postgres or like you know, SQL statements, versus relying on like a higher level, kind of nice, safe abstraction that RHEL provides, or even maybe the LLN is working on some of these details. And I don't know, I just think that's I think that's really interesting in terms of how we're kind of climbing up this abstraction layer um with our yeah, yeah, that's really interesting.
Vibe Coding, Context Limits, And Caution
SPEAKER_01And this would be like a whole nother episode in itself. And I've I've never talked about this exact topic on the show before, but like uh I forget exactly how you put it. Like, are we depriving ourselves of something by relying so much on on Rails and stuff like that? And like I think totally, yes. Like, I challenge anybody to write a non-trivial program in just bare Ruby or or something like that, like not a web application, um, just some program that that does something non-trivial and only use a programming language. Uh if you do that, there's nowhere for any of your design flaws to hide. A hundred percent of everything you've written is your own stuff. Um and it's a really like it's a really educational experience because it forces you to um it it forces you to control everything and decide everything and stuff like that, and if you have gaps in your in your design skills, they'll really show.
SPEAKER_00Yeah, yeah. No, it is interesting, and you know, and then you could make the argument, well, you know, why reinvent the wheel? Or like I've heard arguments from people that are like, well, back in my day, you know, we had to write everything and see and assembly and all this stuff, and you know, students these days are relying on these higher-level languages like Python, and but they just don't understand as deeply. So, you know, they're uh they're not going to be as good of engineers. But I think a similar argument can be made with like large language models and like this type of generated code as well, which is like if you have a large language model that's generating the code, and you're not having to worry as much about the nitty-gritty details, you're just kind of verifying at the user interface level, at the behavior level, you know, kind of the workflow level. Is there um like maybe maybe that really is the future? Maybe the LLMs are just good enough to where any issues that do come up, you just feed the issue in directly to the agent, or the agent can just see the issue come up in real time from the logs, and it can just deeply diagnose and fix, fix the issue and not have to worry about um some of the lower level details. And maybe it's still too early for us to think that that's where things are are gonna be. Um, but maybe not. Maybe it's just a kind of continual pattern of we're just getting moving up the abstraction level and focusing on a different part of the problem, I guess, more in the domain logic rather than in the code implementation details.
LlamaPress Thesis And Closing
SPEAKER_01Well, I think this is another area where it's helpful to think about uh like what'll always be true versus what won't. Like in the activity of programming, what are the essential activities that a human always sh should do because if you don't, you'll hurt yourself. And what can you leave to the machine? Um and that makes that makes me ask, like, what is programming? Um and to me, programming is the uh design and construction and maintenance of a software system. The you know it's it's not exactly coding, because like we write code to define the behavior of the system, but that's a little bit incidental. Um and you could abstract away the code, but you're still designing a system and the the high-level components of the system and the way the system is conceptualized and stuff like that. Um that stuff is independent of the code. Um and there's still a lot of room to make different choices. Like two programmers might make significantly different choices about how to architect something. And I think a concept that you will especially appreciate based on your appreciation for UI design and usability and stuff like that, is that uh the the code is downstream of the product design. Like the concepts the concepts that appear in the code are dictated by the concepts that appear in the product. Um and if your product is conceptually incoherent, then the code will be too and so we still have to make those decisions um from a product design perspective, or else we can leave them up to the to the machine and maybe the machine will do a great job. But like maybe not, and like there's no such thing as like the objective right way to do it, and so like the machine will do something and maybe it'll be pretty good, but uh maybe it won't be exactly what you want.
SPEAKER_00Yeah, it's interesting. I I almost think this is this is the flaw with I heard it's I don't know, it's like this kind of new generation of programmers, like the vibe coders, right? Um, you know, can they can they build a program? And you kind of have, you know, for example with Ruban Rails, with it being super opinionated, you kind of have this like strong set of defaults where you're removing that decision making in a way, you know, when you take on a framework like Rails, they're kind of adopting its strong opinions and its conventions, like even just that it's model view controller, and we're gonna name things exactly like this, we're gonna name folders exactly like this. And um I agree, I don't think that you can like let the large language model make these design decisions, especially if when you're in a framework like more in the JavaScript ecosystem. So, for example, Lovable and Bolt, you know, the kind of the other browser ones, they use um it's like a React front end, and then they use Superbase as the back end. And that's like kind of their opinionated defaults that you go to. And there's benefits to that because then you get like this hosted back end with superbase. It's like really easy, you know, it has like all the database stuff out of the box. And then you have like these React pre-built front-end components. So you can build a lot faster, especially if you're not like a developer. But there's there's these trade-offs of having superbase as like this managed back-end service. Like one of them is, you know, these are things too that non-developers wouldn't even realize, like these trade-offs. But like one of them is that you're using a managed database for the full stack, right? Like superbase is based, it's just a Postgres database, and then they have row-based authentication and row row level security for like kind of scoping things to kind of handle that like multi-tenant aspect that a lot of apps have. But then you're ending up with like C and like you're ending up with like SQL code in the React code because you're like writing these SQL statements, or the LLM is writing these SQL statements, and then it's having to deal with row level security in the front-end React code, right? And so you get these like trade-offs, but maybe like it helps you like get something built quicker, like kind of like a more prototype type thing. But once you start layering this, layering in this deeper domain and kind of business logic, you start having just this kind of code spaghetti, right, of these SQL statements mixed in with the front end and like um all these role-level securities, and you kind of lose that benefit of having like a more, I guess, monolithic, kind of opinionated, full stack kind of structure.
SPEAKER_02Yeah.
SPEAKER_00And so it's interesting, like those little design trade-offs. Maybe there's like wisdom in not you know, and in choosing the right framework to begin with, because then you're not making these like design decisions and like the level of abstraction that you're working with is more centered on the business logic, and the LLM can focus more on the business logic and the domain logic layer, as opposed to having to deal with this like SQL code and the front end and like these other kind of kind of issues.
SPEAKER_01Yeah, I think what is happening is there's a curve um um from the beginning of a project to its death, um, where pre-AI the curve starts. It's like the Y, the X-axis is time, um, and the Y-axis is the cost of making the next change. And it starts off very low and then it goes up and up and up, and at the end there's like an asymptote where it becomes infinitely expensive to make any change and and you're dead. Um and I think that point of death is kind of the ultimate fate of every project, probably. The only question is how long you can stave off that death. Because the even though you might have local drops, um globally the cost of adding the next feature is never gonna go down. Um and I think what's happening now is that first part of the curve it's it's making it go way down. The cost is smaller for longer. Um but then it it's making the curve go way up, way faster, because like if you are a non-programmer, um you can create something a lot faster of prototype quality, but it's gonna be really quick before it's it's so expensive to change it that you can't, and the LLM won't even be able be able to figure out what to do next. I've hit that point myself with scratch projects where I'm just like messing around and then like before I know it, I don't understand. anything and the changes that I want are impossible because I can't figure out figure it out and the LLM can't figure it out. And so I think that's the change that's happening.
SPEAKER_00Have you heard the saying it's like I heard this early in my programming career and it's always stuck with me. And it's that when you're when you're writing new code there's only two people that understand what it does you and God. And in three months and in three months it's only going to be God that understands that is so funny. I haven't heard that one. So now it's kind of like if you're vibe coding there's only two people to understand the LLM and God. Right. And then in five minutes when you get a new context window it's only going to be God that understands it.
SPEAKER_01Yeah. Yeah that's very true. We should probably start heading toward a a conclusion um even though I I would love to dig into these topics deeper and deeper.
SPEAKER_00But um where can people go if if they want to learn more about LlamaPress and anything else that you're up to yeah so um then go to llamapress.ai that's our our main landing page and you know basically it's just a chatbot that builds Ruby on Rails apps. So rather than building it in React and a superbase backend you're building a Ruby on Rails application from the beginning. And the hope is that the long-term maintainability of the application because you're using a monolith structure a highly opinionated framework that's been around for a long time means that the large language model is more able to understand the code base over a longer period of time and it's going to follow the strong default opinions of Ruby on Rails and that even if you are going back and changing things in the you know in the future the LLM is able to read and understand the the Rails code to a much higher degree because it's not making these little tiny decisions. If it's following the Rails convention the entire engineer during the entire engineering process then the hope is that the same benefits that Ruby on Rails gives to the human engineer which is a cohesive mental model being able to understand the code those types of things that those same benefits will transfer to the large language model and that you'll actually have a more maintainable application especially if you're not an engineer to begin with. So that's kind of our thesis and so yeah we'd love to we'd love to have people check it out.
SPEAKER_01It's lamopress dotai all right well we'll put that in the show notes and Cody thanks so much for coming on the show.
SPEAKER_00Thanks Jason great talking with you