Returning to the Low-Code CTO: Lessons from the AI Fast Lane
How a whirlwind of AI insights and hands-on experiments is reshaping how we build, debug, and deliver value.
6 min read
The Wrong-Right Way
Look, I know it’s been a while since the last issue of this newsletter, and it’s not because I’ve run out of ideas or conversations. Honestly, the sheer speed and volume of what’s happening in the AI space has been eating up all my external bandwidth. But as we roll into the holiday season, I’m making a little time to get back to writing and share what’s been on my mind. So here’s a quick rundown of the insights and conversations that have been brewing both in my head and around the Launch by Lunch community.
What I’m realizing is this: AI isn’t changing what we build—it’s exposing how we think about it.
Developer Pushback on AI
So one of the very common pushbacks I get from very technical people in my network is, “Oh, it’s really great these people are building without code, but the reality is when it breaks, they’re going to have to bring us back in, and they don’t know how to read it.” And I don’t know if I agree with that, because I no longer write legacy code. I always use an AI proxy that sits between me, because it gives me a space to think about the “why” before I decide whether any line of code needs to be changed.
And so my pushback to developers is: why do you think you actually need to come in and solve someone else’s problem? Are you expecting these founders to fail? Because these founders are not expecting to fail. They know they can build with it. They don’t want me or anyone else at Launch by Lunch to fix it for them. They want to understand where their thinking went wrong and how to fix it.
“Legacy Coding” is the name I give to how I used to code before AI and MCP.
Where do Junior Developers Sit?
Then the next thing I’ve noticed—and there have been some blog articles on LinkedIn about this—is that junior developers can build quickly, but they don’t know how to debug. We’re in this in-between time where people who were educated to value code and syntax because that was the only way to deliver value are now seeing a new tier of people who maybe don’t code everything by hand, but they get context differently. I had this happen recently with my own proof-of-concept. Instead of just coding it all myself, I asked the AI to plan and refactor as if it were a seasoned Google engineer. It wasn’t about learning to code better myself, but framing the work differently.
[
Great post on the state of junior developers.
And here’s an important point: there are actually a phenomenal number of things in the real world that people don’t know how to use at a deep level. Most of these students, for example, have no idea how a TCP/IP stack works, and almost no developers today can read raw assembly language. We don’t expect someone to understand how a cell tower hands off your call as you drive down the highway. We use these layers of abstraction and move on. So understanding an idea is different from executing every technical detail.
So maybe we are not teaching CS the right way? Perhaps we are educating new developers using a fundamentally old model. A model that is getting discarded and rebuilt by non-developers?
Waiter, Software for One…
This ties back to the idea of software that fits like a glove versus one-size-fits-all SaaS. We’ve talked before about how founders don’t necessarily need to become master coders when the tools they use are tailored to their unique needs. It’s about making sure that the technology molds to them, rather than forcing them into a generic mold.
And the last concept is this: when we look at companies built with AI right now, we’re seeing fewer handoffs between idea and execution. Founders are maintaining the fidelity of their ideas by removing layers of back-and-forth. Instead of an idea being diluted across multiple team members, the person with the concept works directly with the AI. We’ve seen this at Launch by Lunch—founders are quietly showing us how they’ve used vibe-coded solutions to boost profits in ways that no off-the-shelf SaaS could. The magic is that they’ve cut out the middle steps, and the idea goes straight from founder to AI and back, with no loss of signal.
Leveling up my AI Approaches
Finally, I’m super excited because I have a developer in my network who actually schooled me on this just last week at an event. He’s going to come into Launch by Lunch and do an expert session. What he showed me is that even though I push hard to use an AI proxy everywhere, I was still working in a single-threaded, developer-centric way. He showed me how to layer multiple threads of AI agents so I can get three times as much done at once.
I tried it out, and within two hours I had 84% code coverage—meaning 84% of the application’s lines were now covered by tests. That means every time I make a small change to the API, the tests are automatically written or rewritten, and my code is essentially tested by something other than me. It’s a massive benefit because it lets me operate at a higher level and stay focused on the big picture. So in our upcoming session, we’re going to dive into how even someone fully committed to the AI proxy model can still level up. I’m super pumped to share that journey.
Once my cursor AI noticed all my tests, it started updating them as I fixed other bugs. Wow, wow, wow!
Come join the LBL Expert Session with Dave Strickler on December 15th. Get your mind blown, just as mine has been.
He is going to show us his tooling, approaches, and how he thinks about the tools. Tooling show and tell. This is as technical as we ever get these days.
Across all of this—developers, juniors, founders, tooling—the pattern is the same.
We’re not struggling with code.
We’re struggling with clarity.
Clarity of thinking.
Clarity of structure.
Clarity of what the system is actually doing.
Most founders I talk to don’t have a clear way to explain how their system works today—especially once AI is involved.
And that’s where things start to break.
I’m running a few 15-min Tech Stack Clarity Checks to help founders quickly see where their system is unclear, fragile, or hard to explain.