Dear founder,
If you had asked me a couple of years ago if I loved coding and software development, I would have given you a resounding yes. No other job had ever been as enjoyable. No other activity had ever been as rewarding as building software, writing code, building systems that do what I want them to do in ways that other people couldn’t.
But if you ask me this now, I have a much more nuanced perspective. And it comes from two places: having been a software entrepreneur and developer for well over two decades at this point, and having experienced the fundamental change that is software engineering with AI assistance.
A quick word from our Sponsor, Paddle.com. I use Paddle as my Merchant of Record for all my software projects. They take care of all the taxes, the currencies, tracking declined transactions and updated credit cards so that I can focus on dealing with my competitors (and not banks and financial regulators). If you think you’d rather just build your product, check out Paddle.com as your payment provider.
Here’s what I’ve recently realized: I never really loved coding. I just always thought I did.
The Illusion of Love
I thought I loved coding because that’s what I could do, and what I was able to do very effectively. It felt like it was the thing for me to do, and nothing else ever came close. It was my superpower, my identity, my craft.
But now that I have AI assistance, I’m realizing that the coding part was never actually the thing. Watching an AI agent solve problems much faster and much more comprehensively than I ever have has given me a completely new perspective on what coding actually means to me.
Because in the past, you really had no choice. Either you figured it out or you didn’t. Either you made the machine do the thing you wanted it to do, or you didn’t. Anything you couldn’t figure out was impossible for you to solve. The act of composing text into lines of code, deploying these lines, testing each individual line, building a strong mental model of the whole codebase in your mind and then implementing it into a text editor – all of this stuff that makes coding possible was inseparable from the outcome.
But now we’re using AI systems to build things for us. And suddenly, coding isn’t required anymore. Not in the traditional sense. I’m not hiring somebody else to do my code – I’m hiring a machine to execute the code implementation function.
The Podscan Evolution
I’m realizing this particularly with my current project, Podscan. Podscan started out as 100% coded by me. I had a blast building the first prototype, building the first couple stages of the tool. Everything was hand-crafted, every line considered, every pattern deliberate.
Then, over time, AI-assisted coding happened. I started copying and pasting modules and functions into OpenAI and Anthropic systems, having them optimize the code, having them give me feedback on how to do things better, more effectively.
About six months ago, I started diving into agentic coding, and I’ve never looked back.
Right now, whenever code is added to the system, it usually originates from me prompting an AI and then code reviewing it. I write tests that ensure the rest of the functionality isn’t impacted by changes. And what I’m noticing is profound: I seem to enjoy the orchestration of code, but never the construction of it.
The Developer-Entrepreneur Divide
Maybe this is the big differentiator between a software developer and a software entrepreneur. I’ve always considered in the past that each software developer is just one choice away from operating their own software business. But I’m realizing now – both from making that shift myself and from having a couple decades of experience working with other software people – that some people are just wired differently.
Some people enjoy not the solution of the problem, but solving the problem. It’s the journey, not the destination, that a hardcore software developer truly enjoys. Once it’s solved, there’s this fleeting moment of pride, but then the next challenge is immediately tackled.
For an entrepreneur, it’s a different story. Each feature, each implementation, is a pivot towards more success or a mistake that has to be rectified. It’s never the most rewarding thing to build a feature. The rewarding part is if it makes the business more performant, if it makes you more money, if it attracts more customers, if it retains more customers.
A pure logic thinker, a person who really loves coming up with a technical solution to a technical problem, doesn’t want to have to think about business. They don’t want to have to think about the customer-facing impact of their software. They just want to have a highly efficient solution to a mathematical puzzle.
And as much as I enjoyed solving these puzzles in the past, I’m realizing that my ultimate goal was never related to the puzzle in the first place. It was always very much concerned with whatever the puzzle was surrounded by – the operational framework that the puzzle happened in.
The Identity Crisis
For a lot of software entrepreneurs who come from a background of crafting really high-quality software, this transition to agentic systems that write good code on a good day and mediocre code on a bad day – it feels like you’re losing a point of pride. You’re losing some sort of your identity as somebody who’s been building things for many years, even decades at this point.
Jack Ellis, the co-founder of Fathom Analytics, has been very outspoken on his Twitter feed about his failed experiments with AI systems in maintaining the quality of a codebase or adding features to their quite high-throughput, high-performance software suite. A lot of people have chimed in and agreed that their initial contact with AI coding has been explosively negative, structurally defeating, because the tools were just not up to scratch. They weren’t creating code as the original author would have wanted it to be.
But here’s the thing: I look at my work with Podscan, and it’s been working out every single day for half a year. It can’t be that I’m a significantly better prompter, or that my configuration of my AI agents is better. We’re both using the same tools, and we’re both capable of clearly expressing what we need.
So it must be in what I allow to be the right code, or what my code reviewing process doesn’t flag as a problem.
The Flexibility Mindset
I’m quite liberal when it comes to patterns that I may not have implemented myself but I understand. When I look at the code suggestions that Claude or other tools give me, occasionally they’re using things I would never have used. But then I try to figure out why they’re being used. I engage with the system in a conversation. Either it’s explained to me and I agree with it, or we iterate to find something better.
I’m very flexible in accepting that the first implementation of something – provided it actually works – is a solution I’m willing to allow into the codebase, as long as I fully understand it and have had a conversation with the developer (which in this case is an AI system) about feasibility and alternative approaches.
Our expectations for what “good code” means are wildly different between developers, and what acceptable code is as well. I’ve always been flexible there. If this does the job, then I’m good with that. I’ve never been so committed to creating the perfect software implementation of a feature that I would dismiss a non-ideal variant of it, that I would dismiss a preliminary version that works well enough but may not be perfectly crafted.
This might be the perspective you need to have, particularly in early-stage software businesses where velocity, shipping speed, and flexibility are more important than pristine code. Something that I believe is only pristine for a while anyway. There are always optimizations to be made. You can always find ways to improve things. Having code that is perfect – it’s only perfect until you decide it’s not. And my threshold for deciding that things are not good enough is pretty high. Something needs to be really bad for me to call it not good enough for now.
The Incremental Change
What I’m trying to say here is that just like choosing a new continuous integration chain because it’s more effective, or porting part of your system to a new, more performant programming language, or choosing a new vendor for a higher-performance database system – making some kind of incremental improvement on your business – allowing yourself to let go of the notion of having to love coding, having to love the act of writing code, is one of these incremental changes in your entrepreneurial career.
We’ve all figured out that we interface with AI systems very effectively when it comes to writing emails, when it comes to having the AI play devil’s advocate for certain communication or customer problems. We’ve all learned that these tools are really good at helping us with that, and they can be very persuasive when set to solving a particular problem.
So the last question for many software entrepreneurs is having these tools touch their codebases. People hesitate a lot, and for them, it’s a big change, a hard change to deal with. Maybe it really is just letting go of a self-assigned identity – that you are only a true programmer if you program.
The Delegation Reality
Here’s something to consider: eventually, once your business becomes bigger, you’re going to have to delegate development anyway. Someone is going to write code differently from you. It’s just that now we have access to that somebody else for twenty bucks a month when we use Claude or OpenAI’s Codex or Gemini or whatever it might be.
It hits us earlier as developers now – that the delegated parties that write code for us aren’t writing code as we would. That’s one of the changes we have to embrace. And once we do, all of a sudden, the shipping velocity and the feature agility that we have in building software businesses is just massively bigger. It’s quite the advantage.
The Path Forward
I wonder if there will be more and better tooling to help developers who have these extremely high standards get to the level of quality they want anytime soon. I would certainly hope so, because the benefits of building from an orchestrator’s perspective, compared to typing every single thing into your development environment perspective, are so massively outweighing the drawbacks for me right now that it would be very hard for me to get back to actually coding as I did two years ago.
If you find yourself experimenting with these tools, and if you find yourself questioning whether your die-hard approach to hand-crafting software is a relic of the past or a hill you’re willing to die on, maybe consider that it really has a lot to do with not what the job to be done is – why you’re writing this piece of software – but what the goal of the surrounding system is.
Are you building this because you enjoy building? Or are you building this with the ulterior purpose of facilitating somebody else’s job, helping people be more efficient, helping people waste less time? Is this a self-centered activity, or is it an externally-pointing activity?
For many people, this transition is shaky, filled with disappointment. But I hope people allow themselves to not be trapped in the perfect coder mindset anymore. Because what I’ve discovered is that I feel the same level of enjoyment – if not more – from looking at generated code, making sure it works, and making sure it implements the features I want in a way I find appealing, than I would have gotten from actually writing the code myself.
It turns out that it’s not that I love coding. What I actually love is getting code written and getting code deployed. Getting it deployed quickly. Getting it into the hands of users who can benefit from it.
And if AI can help me do that better, faster, and with less personal strain – well, that’s not a loss of identity. That’s an evolution toward what I was always meant to be: not a coder, but an entrepreneur who happens to know how to code.
The code was never the point. The business always was.
We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!
Thank you for reading this week’s essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
