Dear founder,
Just a few years ago, I was a wholly different coder. At my best, I was breezing through documentation and writing mostly functional code. At my worst, I’d be chasing typos and strange bugs for hours, to no avail.
Not once would I have thought of using AI to help me — because it didn’t exist.
But things have changed.
🎧 Listen to this on my podcast.
We now live in a world where software developers who don’t use AI tooling to write code are becoming extinct. The technology available to us, either extremely cheap or free, is so ubiquitously useful and impactful that coding as it was five or 10 years ago will be completely replaced.
With a cost.
This shift comes with several advantages in terms of productivity and speed, but it also heightened a lot of fears and exposed potential problems worth exploring.
As someone using AI tooling to build software products, I want to consider why we’re on this trajectory, what risks exist, and how we can mitigate them. I also want to explore what this means for people who are just starting to learn how to code and build software products in a world where AI is an expected part of the software development process.
The Power of AI in Coding
The clear advantage of using AI is simple: it types faster than you. AI generates code faster than a human could ever write. Even the most recent non-AI code writing tools of a certain complexity are slower than what open-source AI can currently do. By AI, I mean large language models trained specifically on writing code or generic enough to have the capacity to write code for the user. ChatGPT, Claude, and others are capable of writing code, with some better than others at producing software that actually works.
As a software entrepreneur, I have to balance my willingness to solve interesting technical challenges with business necessities. Anything I can do to write good, functioning, reliable code faster is something I must explore. When the first AI coding assistants hit the market, I quickly noticed their power. For an experienced developer, these tools are incredibly useful because they can create code that I can quickly scan and approve or reject.
And that’s the crux here: you have to know good code to approve good code.
There’s something about being already experienced in coding that makes these tools extra useful. You’re effectively outsourcing the process of writing logic, and all you do is constantly code review. Everything an AI does is like a pull request for you to review. This means two things:
- For experienced developers, these tools are massively impactful on the quality of work.
- For people learning to code, there’s still a necessity to understand how coding works at its core to judge the AI’s results effectively.
The Learning Curve and AI
This is the core problem I see people voicing: if you’re learning to code with AI, you might never truly understand the solutions you need to judge the code against. You need to understand the ingredients and how recipes work before you can cook; otherwise, you’re just destroying food in the process. The same applies to code – you need to understand syntax, grammar, evaluation, and execution.
There’s probably a stage in a developer’s journey where writing with AI-generated code is a hindrance to their skill development. If you don’t know how to code, you cannot imagine what the overall system will look like in the end, against which you judge what the auto-generated code is and does.
This level of experience, up until now, took a lot of time to develop.
I see a lot of people fear-mongering over this particular problem. They’re upset that people today don’t have to learn how to code anymore to produce somewhat useful results. They fear that people will never get the experience to understand how code works and will only create mediocre, unmaintainable code. And still make money, much earlier in their career.
The “Kids These Days” Phenomenon
This reminds me of a recurring meme about how “kids these days don’t want to work anymore.” It’s a theme that resurfaces every decade, a kind of self-delusional perception that I also see in technology. There’s a visual meme going around that shows newspaper clippings from last year, going back decades, even into the 1850s, all saying essentially the same thing: there’s a moral failing in the youth because they don’t want to work anymore.
I find it very funny to think that every single decade, somebody comes up with the idea that “back in my day, everybody wanted to work, but nowadays nobody wants to work anymore.” This self-delusional perception has been repeating for hundreds of years, and we see a similar pattern in technology.
The Evolution of Programming
Looking at the development of programming itself, we’ve seen similar transitions:
- From punch cards to digital systems and machine language
- From machine language to compiled languages
- From compiled languages to interpreted languages
Each time there’s a quantum leap in technology (or the way we interface with it), you have a group of traditionalists or purists who believe the new thing is causing a loss of knowledge. They think it makes people less good at their job because they need to understand less about what coding or programming is about. And every single time, these people are proven wrong.
When people went from machine language to compiled languages, the accessibility of coding went up. You didn’t have to understand what registers are or what a jump-not-equal event is. You just needed to understand what an if-then-else is or what a variable assignment is. That’s all you needed to know, and from there, you could build code that ran the thing you wanted it to do.
The jump from compiled languages to interpreted languages made things like JavaScript in HTML, PHP, Ruby on Rails, or even Java much more available to more people. You could just put a file somewhere, and if it’s loaded the correct way, it will be executed exactly as you want it to be. This accessibility led to more interesting and better tools being built, and with those tools, solutions were architected that put prior systems to shame.
The Current Leap: Generated Code
I believe we’re at the precipice, if not already in the middle, of another such leap. We’re moving from programming as a means to instruct a computer to generated code – code created from a prompt. It’s another rung up the ladder of abstraction, away from the underlying system.
Recently, I experienced this firsthand when I needed to convert a transcript into an SRT subtitle file format for my business, Podscan. Instead of writing the code myself, I instructed Claude AI to take a stub of what I’d written and create a function that would translate my transcripts into valid SRT data. The result was a working function that reliably did the job.
I told Claude, “The input for this will be a text like this,” and I posted a part of our transcript that I wanted to translate. Then I said, “I want the output to be valid SRT data,” and I hit Enter. What came out was a working function that reliably translated my transcripts into an SRT file.
The Changing Nature of Coding
This experience made me realize that coding is evolving. It’s no longer about typing out every line of code; it’s about knowing what needs to be done and instructing AI to do it. The mental model of the function – taking data, splitting it by line, processing each line – remains crucial, but the implementation is delegated to AI.
Part of me, the developer side, still struggles with accepting this change. The fun part used to be parsing the data, splitting the line apart, taking the timestamp, moving that one line, taking the text and moving that into the next line, and then putting the index of that line in the whole file in another line. But in a way, it really isn’t the fun part anymore.
I would wager that probably every single day on this planet Earth, somebody implements this feature. Somebody takes a file and turns it into some other file that is a well-defined format that somebody else has probably written a library for already. And what I realize is that why developers are so well paid, and why developers are so needed to build these systems, is not that we know how to split a file into individual lines and then take individual parts of that file.
The True Value of Developers
The fact that I can verbalize what needs to happen, what the inputs and the outputs and the general process are, that I have the mental capacity to say “valid SRT is the output I need, and this kind of structured text is the input you will get” – that is what software development is today, and that is what software development will keep being and grow into even more in the future.
Gone will be the days of chasing every single line and creating bugs all the time because we missed a comma or something here or there. Machines will handle that for us. What we’re left with is architecture – from the big picture stuff like designing a full application with 17 different things that all need to work in tandem, to the small picture stuff of defining individual functions.
The Future of Coding Education
We’re removing the executing part from coding and placing prompting and instructing at a much more relevant part of our journey as developers. To prompt and instruct accurately, we need to understand mental models of logic, process, data structures, and data transformation.
Perhaps teaching development will change, just as it has since the 70s or 80s when people were taught BASIC, COBOL, C, or Ada. Maybe instead of writing code, software developers will be tasked to become instructors. The earlier we understand that to be able to prompt and instruct accurately, we need to understand mental models of logic and process and data structures and data transformation, the more and the quicker we can establish a curriculum for developers of the future who do not have to dive into every single line of code manually.
Coding as Editing
For the longest time, I felt there was really no difference between being a writer and being a software developer. Both write text of an instructive nature – one writes for people, the other writes for machines. Now it feels we’re moving away from the writing part and becoming editors. We edit somebody else’s thoughts to fit with what we know the audience needs.
The audience for a book editor is the readership of the books that the publisher brings out. The audience of a software editor is the systems, the computers, the interpretive systems that execute the code created by these AI systems. If you want to write well, you need to understand what editing is. So if you want to code well, you also need to understand what prompting and instructing is.
The Road Ahead
There will likely be hiccups along the way. Many developers are defensive about this change, feeling insulted that something they spent years mastering can now be done so easily. A lot of developers are hyper-defensive about this because coding as it is now has taken many people a long time to learn and understand. So to have it be so easy for code to be generated feels like an insult to some.
But the benefits are undeniable. I personally benefit massively from the increased speed of generating code. It’s always easier for me to judge code, to look at it and read it, than to come up with it. That is why coding is fundamentally different now – the speed at which we get to not just write code, but to parse code and understand code and validate it. AI has made a mark that I don’t think we’ll ever walk back from.
In this new era of AI-assisted coding, our role as developers is evolving. We’re becoming architects, instructors, and editors of code rather than just writers. And while the transition may be challenging for some, it opens up exciting new possibilities for innovation and efficiency in software development.
As we move forward, we need to embrace this change while also ensuring that we’re developing the skills needed to effectively guide and instruct AI in creating the software solutions of tomorrow. The future of coding is here, and it’s a thrilling blend of human creativity and machine efficiency.
I'll share a few updates about my SaaS on the pod, and if you want to track your brand mentions on podcasts, please 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!