The Bootstrapped Founder

Arvid: 00:00

Hey, it's Arvid and this is the Bootstrap founder. This episode is sponsored by Paddle.com, my favorite payment provider. I use them on several of my software projects and I've been very happy with them over the last couple years. They take care of sales tax and expiring credit cards, invoices, all that kind of stuff so I can focus on my business instead of chasing money. They can do that for me.

Arvid: 00:26

So go to Paddle.com to check it out. It's one of those important foundational choices you have to get right for your business. Pabbel.com. The way we build software is changing fundamentally and I wanna talk about this today. We have these AI systems and they are transforming the process of creation into something very different.

Arvid: 00:48

Something almost like a managerial thing. Like now as a developer, as a technical person, you're gonna have to manage an AI instead of writing code. Like, you get to manage a junior because AI often behaves like a junior developer in terms of their competency and their vision of the product, but you get to manage them. You have to manage them and then deal with the fallout of this. So when you build software with AI assistance, you become less of an explorer or less of an implementer and more of a validator or a verifier.

Arvid: 01:16

So you are the person who checks and judges the quality of code instead of generating it. We're moving from generators to validators, from creators to judges in the best sense of the word. And this shift got me thinking about how we have all those famous laws and principles that have guided software development and entrepreneurship in the past and how those things might be changing in this new AI assisted world. You know the ones. Right?

Arvid: 01:40

Like Murphy's law, Brooks law, Conway's law, those short phrases that people attribute some kind of truth to. So I wanna explore how developing software and software enabled businesses, particularly with AI assistance, changes these laws and maybe affects them in some way. Sometimes you will see laws that are still the exact same and others, they are flipping around. That is a very interesting development. So let me share some insights from my own personal experiences building PodScan with AI assistants and how those classic laws now apply or don't in this brave new world of prompts and completions.

Arvid: 02:17

One of the clearest and most applicable laws when working with AI systems is Kidlin's law, which states that if you write a problem down clearly and specifically, you have solved half of it. And this becomes even more true than ever before with AI assistants. The specification of how you want to get your work done through a well formulated prompt to an AI system involves most of the actual thinking, if you're working like this. Consideration of things like structure, tasks, specific subtasks, the results you want, the inputs you have, the outputs you expect. When I provide a prompt to any AI system, I'm communicating this intention with varying levels of inputs.

Arvid: 03:02

Sometimes it's just create a list of x, y, z to something like a much more complex set of instructions with like 10 different things that I give as context to a machine. For example, I might say here's my existing code base and I want a feature that takes data from this database with this schema and deploys it on a page that looks kinda like this one or uses a back end processor transform it into something else that fits into this database. In this prompt, you kinda have already defined the input like the data structure and the code that currently handles it and the output what I want the result to look like. Sometimes that's visual, sometimes that's code and often even how the transformation should happen. I might explicitly state things like aggregate this data over a seven day time frame when it comes to kind of time frame analytics or implicitly figure this out from the existing code that describes how this data is currently being handled and displayed.

Arvid: 03:57

You can put all of this in there just to different degrees how you define it will impact the output. So Kaitlin's law applies even more strongly than before because of old style specs being more vague in the sense that they left a lot of room for experimentation during implementation. Software specs, particularly the waterfall specs, try to be precise, but they can't really be as precise as they need to be to be super precise, if that makes sense. There's still room in there for the developer to actually implement that. And even if you build software in an agile way with sprints and rough planning sessions, there's always room for discovery during the actual implementation process.

Arvid: 04:37

And with AI assisted development, that room gets much more granular. When I write a spec for a feature, I want it to be so well defined that the machine that I hand this task off to has minimal room to get it wrong. The thinking about structured tasks, parts, results, input, outputs, that kind of stuff all needs to be a well formulated prompt that includes most of this work upfront. That is novel because most of the developers that I know were used to reading a spec and dealing with it, not to create one as a form of code. In a way, writing a good spec is coding because it's just like if you write Java code that then gets compiled into bytecode.

Arvid: 05:23

The bytecode is what runs. You could argue that if you have a website of let's say PHP that the spec that you write is similar to the Java code that an AI then compiles into the PHP code that then runs on your website. It's It's kind of a shaky example, but you kinda know what I mean. Right? It's one abstraction layer on top.

Arvid: 05:42

It's just like we had machine code, we had assembler, we had compiled code, we have interpreted code, and now we have generated code. That's the thing on top of it. And the better you define whatever you need, the better that abstract thing gets at being the exact thing or being kind of compiled down into the exact thing that you want it to be at the end. And here's another interesting flip in terms of a law, Postel's Law, p o s t e l, also known as the robustness principle. It traditionally states, be conservative in what you send and liberal in what you accept.

Arvid: 06:15

And it was meant to express that a system is best assigned if it's very limited in the randomness of the data, the structure of the data that it sends out making it more reliable. But be good at interoperating with other systems by accepting different various kinds of data. It's kind of network thinking. Right? Like, if I can send a very specific kind of data out there, others will integrate with me and because I want to integrate with others, I will take whatever random stuff they send.

Arvid: 06:43

Makes perfect sense. But working with AI systems where you as a person are the sender of information and the AI kind of replies back to you, I found that this has completely turned around. When communicating with AI, I wanna be or you wanna be very liberal in what you send. Because you don't fully understand how AI systems interpret information. Still kind of black box ish, but you must be very conservative in what you accept from the AI.

Arvid: 07:11

Case in point, when I code with AI for PodScan, the more context I provide, the better the result fits my needs and the less I have to discriminate against the code that comes back. The more often I give a lot of context, the more often the result is good enough for me to say, yes, this is allowed in my code base. I don't have cursor write all my code and just build my code base for me. I still give tasks to AI to generate code which I then manually take back into my code base because I feel I cannot let a random tool randomly change my code base. I would completely lose oversight and an understanding of my code base.

Arvid: 07:50

And as a solopreneur, I cannot have this. So I'm not a cursor user for PodScan. It's too big to fail, you know, for failure to happen. But that is the reason why I say no to a lot of code generated by AI. When building a feature, I try to find every single file that touches the data model or the request flow that the feature involves and I hand it over as context to the AI system.

Arvid: 08:15

For instance, when I need something related to podcast episodes, I get the podcast episode data model, the database schema for episodes, the controllers that touch it, maybe views that show that model so the AI will know what kind of information is relevant and what is not. There are a lot of different things in the code base that I find and put into my prompt as context for the machine. So I'm very liberal in how much data I supply, how much I send. Even if many of the podcast model functions have nothing to do with the feature that I specifically might want. Right?

Arvid: 08:43

If I have something that is supposed to change a style of transcription from having time stamps to not having time stamps, but different encoding or whatever, A lot of the logic on, like, how an episode is liked or disliked or exported, that's really irrelevant. But I give that context with it so the machine can see how the code feels because I still want the AI to understand how I usually interact with data, how I write it to the database, and how I handle caching on most occasions. The AI needs to get this feeling for the smell of my code, the processes and the concepts that are integrated into the system. But other side, I'm really extremely conservative in accepting what fits back into the codebase. I frequently find myself saying, nope, this is completely wrong or this doesn't follow how I want that data to be handled.

Arvid: 09:32

Or this implements a completely new paradigm of data interaction. Don't do this. The AI has to do it as it has seen it in other functions I provided, not introduce new paradigms. So liberal in what you send, conservative in what you take in. This brings us to Gilbert's law, which says that when you take on a task, finding the best way to achieve the desired results is always your responsibility.

Arvid: 09:56

I kinda like this generally as a law in life. Whenever you do a thing, finding the best way to do it is your job and nobody else's. Until software is written completely by autonomous agents without any human involvement, you will be responsible for verifying or dismissing what the machine produces. When I tell an AI system to write code for PodScan, I need to read every single line of it. I have to make sure that the intention of what I had in my task is to build this feature accurately and is reflected in the code.

Arvid: 10:32

The machine's best way, in quotes, might not actually be the best due to a lack of context or the wrong context or the wrong prompt or the wrong examples that it has in its training data. I don't know. My responsibility is to take the code and judge it harshly. Not because the machine did something wrong, but because I don't know what the right code is until I see a result that fits. I might need to ask the AI to rewrite it in a different style to better fit my code base or building it differently for future extensibility.

Arvid: 11:02

There are many reasons to change things. And that judgment remains my responsibility. And that is something that Gilbert's law still captures perfectly. Falkland's law states that if you don't have to make a decision about something, then don't decide. I'm a big fan of abstractions and that's why I'm mentioning this here.

Arvid: 11:21

In making things more extensible from the start, you don't need a full rewrite when extensions are required later. So AI systems are surprisingly good at building things in an extensible way without over optimizing for future extensibility. So in my prompts, I often specify make it extensible, but not crazy extensible. Make it extensible enough so I can switch email providers if needed or so that if I need a new payment platform, I can easily integrate it or make it extensible so I can switch the back end for this microservice. That is the kind of extensibility you can tell the machine to implement and then neither you nor the AI has to make decisions about direct implementation.

Arvid: 12:00

That can be just an interface. The AI can implement the interface or module or whatever is appropriate in your language of choice. But there's an abstraction layer in there that makes it more flexible. And this extensibility is particularly important because when you later extend the code, the surface for error becomes much much larger if you didn't build it with extension in mind. When AI tooling takes old code to rewrite it, it might forget that other components depend on it.

Arvid: 12:28

Starting with reasonable extensibility helps with those future headaches. It helps avoid them. I often put this in my prompts, and it usually does it the way I want it. And, again, put in the context of how you made other things extensible, and it will make them extensible just like it. It's really nice.

Arvid: 12:45

Give code examples. It's really what it is. And Cursor and all these tools, they kinda do it by, hopefully, putting the right files that you're working on into the context, but you can do this consciously. So learn how to do this. This is a new developer skill.

Arvid: 12:59

It's a skill to be able to prompt. Obviously, you should definitely figure out how to prompt effectively, but also to understand what information might be useful. Not required, but useful is a new skill to develop. So if you haven't really looked into this yet, talk to your peers that use it a lot and ask them how they do it, what the thought is that comes to mind which file to attach. They will tell you, and you will hopefully figure out how to do this with your own code.

Arvid: 13:28

Now let's look at some laws that are being challenged by AI. Brooks law is one of them. Brooks law states famously that adding manpower to a late project makes it later. It's the mythical man month compressed into one sentence. And, honestly, with AI tools, it's kind of feeling different for me.

Arvid: 13:48

Your mileage may vary here, but for me, hey, if you have agents building software in the background, if you have Claude up here, Cursor up here, ChatGPT up here, and they're all doing stuff for you, Adding one more agent, particularly if then these things start communicating with each other in the future and can test their solutions, then that might actually benefit development speed. It does clash with what we just discussed in Gilbert's law. You're still responsible for integration, but the more we move towards self contained agentic coding systems that can build, run, and verify code, adding more engineering power actually becomes a benefit rather than a drawback. I think AI spawns additional people, and that is something that the man power and the man month never really had to take into account because resources like good developers are pretty scarce. But if your AI system is better than 95% of all developers out there and you can easily spawn a new one for, like, what, 5¢ an hour, it becomes a different story.

Arvid: 14:54

The less human verification is needed in those moments, and these these things will get better and better. And the more machines can verify their own creations, writing code, compiling code, running code, checking the results, the more we might be able to overcome the limitations that books identified decades ago. Having multiple agents working in parallel could fundamentally change the economics of software development here, and I'm all for it. I envision a world where I push some code, because I still wanna do that. And then in the background, hundreds of machines start running this code and making small changes to it and looking at the database.

Arvid: 15:29

Did something change? Is it for the better? Is it for the worse? Are tests still working? Are new tests necessary?

Arvid: 15:35

Like, can I make it faster? All of these things work all the time. I go to bed and for eight and a half hours or however long I sleep, hopefully eight hours because you need eight hours of sleep, you get to have machines doing all of this work in the background. You come back to work in the next morning and you get presented the best solution from a hundred machines doing each eight hours of calculation on how to make your code more effective, plus testing and everything. And that's gonna cost you a couple bucks because that compute is gonna be cheap.

Arvid: 16:05

That is the future I wanna see. And And I think we're gonna go there. I've seen more and more people trying to build these systems already, and with compute costs coming down and effectiveness of these models going up, even having one agent run for you overnight is gonna be a massive impact on your productivity. And there's a similar law, Hofstadter's law, that says it always takes longer than you expect even when you take into account Hofstadter's law, one of the recursive ones that I really like. Software projects certainly take time, but AI might actually offer way to speed up development here by having multiple agents work simultaneously.

Arvid: 16:42

Give different systems the same task with slightly different prompts with slightly different priorities and have them kind of fight it out, have them built together, or just built individually and then compare at the end. I find it fascinating to imagine not just one agent working on your code the way it is right now, but several doing it concurrently and competing for speed, performance, reliability, maybe security, or anything else you can benchmark. Having multiple sources generate the same feature in different ways, then seeing how each performs, man, that's such an interesting prospect for AI assisted coding. It's like having multiple providers, multiple sources of code, multiple people working for you, but virtual people generating the same feature in different ways and seeing how they work out against each other. Competitive coding like this, I wouldn't want people do this.

Arvid: 17:30

Like, I I know that in the aviation industry, that's how it's done. Different teams develop the same software, and then they benchmark it against each other. But to have that be done for you in the background, that's really cool. And it might overcome some of the scheduling challenges that have played software development for decades. There's one law that will always be true here, and that's Conway's Law that states that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Arvid: 18:05

I believe we'll see the way people prompt AI become an organizational structure or a means of communication structures in organizations in itself. And that will produce certain kinds of code that others who prompt differently might not even understand. The benefit of working with humans in software development is multi level feedback. Your colleagues give professional expertise clearly, but they also provide feedback on communication clarity. Hey.

Arvid: 18:33

You're pretty unclear when you say this, and I think you mean to say that, but to me it means something else. Or here in this code your naming convention implies this but it really means something else to me. An AI system might not criticize your communication style. It simply tries to infer your meaning and projects that into the code but you might not be criticized for the way you communicate. It just tries to deal with it.

Arvid: 18:55

It just takes what you say and runs with it. And that means that something will be encoded in your work that isn't necessarily related to functionality. It's how you communicate how it should be. And since we all communicate with AI individually right now, we all sit in front of our computers and type into cursor, type into chat g p t, but just us and the computer, it's always between ourselves and the machine with nobody else seeing communication. I think there might be a fascinating challenge here.

Arvid: 19:22

Keeping prompting styles consistent and compatible within organizations. I haven't heard or read much of this yet because I think the fallout of this is only gonna come later. But I think we might see unexpected siloing even within smaller developer teams because different prompting styles start clashing continually. Perhaps we need prompt mediators or prompt translators that normalize communication styles to prevent Conway's Law from affecting code quality on a prompt basis. Something that I never thought I'd talk about two years ago.

Arvid: 19:53

Now I'm thinking about how prompting might affect enterprise software companies. I have no solution for this challenge yet, but I think Conway's Law will very likely affect code on a per prompt generation basis, which is pretty interesting when you think about it. Finally, because it's always funny to think about this one, there's the Peter principle. In a hierarchy, every employee tends to rise to his level of incompetence. And with developers using AI systems to write increasingly complex code, we'll find these systems pushed to the point where they become unreliable or frankly incompetent at creating solutions that actually work.

Arvid: 20:28

Like I said, I'm not using Cursor on PodScan because it's already at the limit of keeping the system in its complexity maintainable. Because it's extremely easy to build a CRUD app with AI assistance. And as Peter Levels has shown, it is apparently very easy to build a flight simulator with three gs, a three d flight simulator with wrap sockets for multiple people with AI assistants. It's easy to build a game, simple game. But complicated apps, games with highly interdependent back end processes or AI systems or machine proximate code that needs to be memory safe and secure, AI might not match this tacit knowledge of experienced developers.

Arvid: 21:06

There's something in having a lot of experience in development that you cannot really communicate, cannot really say, but you do it anyway. And so far, at least, AI has not really figured that out. We will make more and more things with AI systems until we find their capability ceiling. And the AI's we use right now have a certain capacity and a certain limit. And of course, newer and better models will be trained on more reliable code and think about this though.

Arvid: 21:33

There might be skill atrophy in the humans using AI and then there's certainly a skill ceiling in AI systems trained only on publicly available code written by people with skill atrophy, which is its own problem. And, you know, the code itself may not be complete, capable, or secure. When you look on GitHub, a lot of code is good. Most code is not. Is that what AI's are trained on?

Arvid: 21:53

Right. You have to think about that too. There is a level of incompetence and even that might be very high right now. Hard to even reach for humans. Like I said, 95% of developers are worse than the best AI systems out there.

Arvid: 22:06

But I think that level of incompetence still exists for AI systems and it becomes ever more dangerous to let these systems run by themselves as agentic systems once they reach that level. So for now, as long as we still test and reliably verify the results of AI systems, hopefully we do that, we still have control. But if they run autonomously and get better and better, in quotes I guess, they might eventually hit a point where they actually get worse and worse because believing themselves to be correct due to a history of assumed correctness does not make you correct, but might well be a bias that these systems operate under. And most of these laws are still applicable in the AI era, and I think it's good to know them, which is why I mentioned them all. I have a little list of them that I regularly consult to make sure that I'm not making the biggest mistakes that I possibly could do as a developer and as an entrepreneur.

Arvid: 23:00

I think it's important to understand laws like this because in terms of the unintended side effects of prompting AI systems and using AI generated code in collaborative code bases, we need to keep an eye out for problems. The key takeaway from my experience here is the importance of clearly specifying what you want with as much context as possible to get results that don't come back to bite you. As much upfront as you can, context all the way. And as we transition from creators to validators to judges, the responsibilities shift. They don't diminish.

Arvid: 23:34

If anything, it becomes more crucial than ever to really, really pay attention. Some principles remain unchanged, some flip completely, and there are a couple that bring up challenges in this AI assisted world. And we got dynamics that we need to understand to navigate this weird landscape of AI that impacts everything we do as founders and developers. So I would love to hear your thoughts on these laws. Maybe I missed one or two and how you've seen them play out in your own AI assisted development.

Arvid: 24:04

I'm really excited to know more about this because these things are so omnipresent in our lives. Yeah. Are there any principles that you've seen that have changed for you? Do Do you have strategies for dealing with these new challenges? Well, let me know.

Arvid: 24:17

I'm always curious to learn from other founders and builders experiences in this super rapidly evolving space. And that's it for today. Thank you so much for listening to the Boots of Honor. You can find me on Twitter at Abed Karl, a r b I d k a h l. If you wanna support me in this show, please share PodScan.fm, my SaaS, with your professional peers and those who you think will benefit from tracking mentions of brands, their businesses' names, their own names on podcasts out there.

Arvid: 24:42

PodScan is this near real time database of podcasts with a really interesting API, a push and a pull API, so please share the word with those who need to stay on top of the podcast ecosystem. This episode was edited and mixed by my sound engineer, Danielle Simpson. Thank you so much for listening.