Dear founder,
A couple of years ago, I tweeted that “the best tech stack is the one you already know.” To this day, this is one of my most resonating tweets. People keep bringing it back, and founders who’ve been around for a while seem to particularly agree with it. They’ve gone through the learning experience of trying new tech stacks, only to find that investing a lot of time in new technology often isn’t worth it when all you wanted to do was actually build a business quickly.
A quick word from our Sponsor, Paddle.com. They’re a great example for a smart tech choice because they massively speed up and stabilize the early days of building a business. I use Paddle as my Merchant of Record. 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.
Recently, a peer of mine asked an interesting question that adds a layer to this idea. They suggested that at this point, the best tech stack is probably the one that the AI tool you use for coding knows the most about.
That’s a fascinating thought, and it’s partially true. For many people who don’t do their own coding anymore, the best tech stack might not just be the one they know best, but the one that the coding AI handles pretty well.
But here’s what I believe: the original statement still holds true, even in its inverted form. It doesn’t matter if the AI model knows a coding language or framework the best. The quality of code the AI produces, and the quality of code that ends up in your software product, is still directly connected to your capacity of understanding and judging, reviewing and debugging that code.
Let me explain why.
Understanding How AI Knows Code
To make sense of this, it’s really helpful to understand how these AI models are being built. An AI model is effectively a token guesser that builds upon existing examples of the written word. It has ingested hundreds of millions of documents: code bases, Stack Overflow conversations, blog posts, chat transcripts from IRC and forums. From there, it builds this internal model that makes it very capable of guessing what the next token should be in a series of tokens, which ends up being text itself.
The data that flows into these models, at least for the first couple generations, was what people had publicly provided. Open code bases on GitHub, GitLab, SourceForge, and other places where people deploy code. The AI was trained on this data, which makes it obvious that the AI has had the most exposure to the programming languages that were the most popular at the point of its training.
From a quantitative view, the AI is trained best on code that in aggregate has been most often used and most often written up until the point where the AI was trained.
So it’s only logical that the AI has had the most exposure to things like JavaScript, which over the last decade has had this massive renaissance. It works pretty well both in the front end and on the server, thanks to Next.js and hosted solutions like Vercel. JavaScript became one of the most popular languages, and a lot of people wrote code and published it, making it available for the AI to ingest.
Languages like PHP, Ruby, C#, and Java—equally popular frameworks with a lot of history in deployed code—are also best represented internally in these AI systems.
If you look for more esoteric code, more niche programming languages like Nim, Erlang, or Smalltalk, there’s still ample history of these languages being written. It might just not be as prevalent as the other languages, assuming all of this data made it into the training corpus.
The model can only know what it was fed. It can only assume things from the data it has been trained on.
So when it comes to making a technology choice based on what the AI understands, the answer is actually surprising: you could probably use everything that has existed in the past where there’s a written record of code for an AI to have been trained on.
If you go with JavaScript, PHP, Ruby, or Python, you’ll get very good results because the training data has been so plentiful. But even if you go with languages like Elixir, Scala, or Bash, you still have a massive data set for the AI to draw on.
The problem comes with languages or framework versions that have been created since the AI was baseline trained. The AI only remembers what it was trained on. Until we have AI systems that create their own training data without human intervention, you have to wait for a new version to be released that may or may not incorporate new features.
Now, obviously, the Model Context Protocol and the integration of tool calling in AI systems makes this somewhat moot. These tools are able to ingest the full documentation of any version of any framework and allow an AI system to update its knowledge on the fly as it’s working on a coding problem.
This means that if you have a proper MCP system that pulls documentation for any programming language you might want to use, any sufficiently capable AI coding system will be able to code in the language you choose.
So it really doesn’t matter which framework you choose for your coding projects. The AI system, with proper default choices or with proper instrumentation around non-default choices, will be capable of building this tool for you.
Why You Still Need to Know Your Stack
For some people, this might mean they think, “Hey, cool. If that’s the case, then I’m just going to build this project in whatever language I think is perfect for it.”
Maybe you’re a JavaScript developer and you’ve heard that you should really write everything in Rust because of memory safety and performance. You could probably instruct your coding AI system to build a backend server in Rust, and it very likely would be able to build code.
But this is going to be code that you don’t innately understand.
You’re going to be presented with code that your AI system will build for you, and you’ll have to say, “Okay, yeah, cool, sure, let’s run this,” or, “Hey, this doesn’t look right.”
If you’re not able to tell one from the other, then you are effectively building a black box—something so opaque that you just don’t understand how it works. You only see that it does or it doesn’t.
And if it doesn’t work, you can only tell the AI to fix it. But you can’t tell it why it should fix it, what it should fix, and to what end that fix should be better or different than the current implementation.
Obviously, all of these activities—debugging, expanding, and manipulating code—will be done by automation systems for many people in the future. For most developers in the future, and for many already. But your capacity to see errors and to understand the infrastructure of a coding project is still responsible for the maintainability and the functional capabilities of your coding projects today.
I strongly, strongly recommend that even though we have this magical tool that can build anything in any language, you should still learn and deeply understand a particular programming language.
Choose one that has a vivid ecosystem that an AI can pull a lot of documentation from. Choose one with a vivid community that an AI can pull conversations from and learn what the best practices are and why they are like that. Choose one with a strong historical backlog of existing projects—the Lindy effect, right? Things that have stuck around for a long time are likely to stick around for a long time.
AI systems are going to amplify this. The AI systems themselves are going to create artifacts in particular frameworks and languages by creating new projects that people then upload to GitHub, which then goes into the next generation of AI models as training data.
You want to choose a technology that you are versed in, that you understand, so that with every potential commit that the AI suggests to you, you know exactly what happens.
Because if you don’t, the AI will build what people who wrote code in that language thought in the past is going to be best—not what you think is best, not what you would build in another language, but what the collective implementation strategy of people in the past who used this technology looks like.
The AI is effectively going to build somebody else’s code with your instruction. And you don’t want that. You want it to build your code with your instruction.
For that, you need to still know and understand the language.
Making the Right Choice
If you’re on the fence right now about whether you should use another framework or tech stack that you know an AI understands but you don’t, go back to what you understand and slowly learn new technology.
Do not throw completely new tech on new projects and hope that the AI will save you. I don’t think that’s the case.
You need to be able to understand every single piece of code. You need to develop experience in potential scaling challenges, in esoteric edge cases, in handling small and frequent or large and infrequent data. You need experience integrating this technology with others and getting other people onboarded into this technology as your business grows and you’re hiring.
All of this requires you to have a solid, foundational understanding of the technology that you’re using.
Do not outsource this to the AI.
The AI is only going to be as good as the other people who used it in the past, and it does not necessarily map onto what you need. If you can’t reliably instruct your AI with these things, it will build something that somebody else would build, not something that you would build.
AI’s impact on tech stack choices is massive because you can do everything. But you should be highly restrictive with new technology choices that you outsource to AI, because that is outsourcing control. And that ultimately is outsourcing ownership.
If you can’t fix it, you have to hire somebody who can, and you pay money for this. If you can’t fix it, you’re going to have to rewrite it, and that’s going to cause financial damage to your business. You’re going to have to rebuild it in a way that you understand in the end, or you just have to sell it, or you have to stop using it and put the project away because it just spirals out of control.
You definitely don’t want that.
So do not make AI-centric tech choices. Make you-centric tech choices.
The best tech stack is still the one you already know—even in the age of AI.
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!
