Returning to the Low-Code CTO: Lessons from the AI Fast Lane

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.

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.

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.

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?

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.

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!

Three weeks ago, we soft-launched our Low Code Cookbook. This is the work of three years of research on how to build more with less code. It’s free with a subscription. It is the first of three products we are launching to help non-coding founders build and do the impossible.

Next up? We have on the drawing board a tool that plugs into OpenAI GPT to let founders talk with the cookbook, as if it were their “fractional co-founder”. Then, we are launching a tool that builds on the cookbook to help founders plan and socialize their technology stack, so fractionals can help them consider edge cases and approaches that speed up the process.