I listen to a crap load of podcasts. Historically, these have been mostly tech podcasts, but recently I’ve been falling down that morass that is American politics. I’m trying to get out of it, but it has a strange psychological pull. Its like a Game of Thrones show with lots of plot twists that I can’t help but think degrades my mental health.
On the tech podcasts side of things, I recently listened to this A16z podcast between Matt Biillmann of Netlify and Martin Casado from A16z. There were a number of “that’s funny because it’s true” moments that came to mind while I was listening to it. So I’ve decided to try out a different type of blog post, which is a commentary on podcasts I listen to. We’ll see how it goes. Might just be this one time, or it might be something that’s ongoing. I definitely won’t be commenting on politics and religion, as that way leads to the madness of King George 😊.
High Tolerance for Frustration (55:22)
“In the past before all of this AI when people asked what to do to be a good developer I said like just have a really high tolerance for frustration.”
This quote appears both at the end of the podcast and in a snippet at the beginning. It inspired this post and sparked my experiment with the podcast commentary format. The meme about software developers needing a high tolerance for frustration and failure is funny because it’s true. Communicating to non-developers just how much programming non-trivial software feels like continuously battling frustration and failure can be difficult. Complex frameworks amplify this challenge, a reality another quote later will address.
Historically, those who couldn’t persevere through continuous failure simply wouldn’t enjoy software development. Vibe coding’s rapid adoption stems directly from this dynamic. During prototype development, it offers developers a precious respite from constant failure. For a brief window, building software becomes free of relentless friction. This reprieve explains why so many developers say it’s “making programming fun again.”
The inverse reveals something equally important. Repetitive work that never involves failure misses what programming is really about. By definition, such patterns should have been automated through custom programs or frameworks. This creates a puzzling paradox for clients and managers. Projects that finish quickly, on time, and under budget with minimal fuss feel like successes.
Yet if teams regularly achieve this, they’re likely “leaving money on the table”. The underlying work hasn’t been examined for automation opportunities. This kind of meta-automation compounds value over time.
The need for high frustration tolerance will persist regardless of what happens with coding agents in the coming years. These tools simply raise the bar for what’s expected. Good developers must maintain exceptional tolerance for both frustration and failure. This fundamental truism won’t change.
Nobody Suddenly Loves HTML (11:31)
“I think it would be a weird coincidence that a lot more people were like, ‘I really like HTML now.’”
The barrier to entry for developing an HTML JavaScript app is definitely much lower than it used to be. I’m using that ability of coding agents to produce interactive mockups for clients and as part of the requirements gathering process to better understand the requirements by working through the development of the interactive mockups. However, there’s a big downside to it in that no matter how hard I try to communicate that it’s still a mock-up, the human visceral reaction is, “Oh, it’s almost done,” which is always a dark shadow over my thoughts. It’s always a concern because only developers can truly understand the massive part of the iceberg below the surface that end users just can’t see.
Accidentally Creating a React App (11:55)
“You have people today that accidentally create a web app in React… you prompted the right thing and suddenly it spins up a canvas and builds you all this stuff and you downloaded it’s like okay now where do I put it?”
I’ve had a slightly different experience with this. One of the frontier labs has created a closed ecosystem where it generates these nice little apps as part of an AI interaction. The problem is you can’t easily extract them. I ran into this when using Google Gemini’s Dynamic View feature (it’s still in labs, marked with the labs icon). Hopefully there’ll be a way to download and extract these creations in the future, but for now they’re trapped in the walled garden.
What I do find remarkable is that a single prompt can generate a substantial web app. Three years ago, the idea that you could describe something in plain English and receive a working HTML/JavaScript application would have seemed like science fiction.
Framework Knowledge is Wasted Brain Space (17:11)
“For me to understand Next or React or some weird CLI… there’s nothing fundamental. So it really is just wasted knowledge. I’m like using space in my brain to remember some dumb design decision from like some random person.”
I truly hate it when some technical area has a massive barrier to entry because it’s full of what I’ve called in the past “incantations.” This wasted knowledge isn’t fundamental and doesn’t cut across technologies. It’s arbitrary complexity that serves no one.
This is actually one of the areas I was most excited about with AI: the ability to semantic search large bodies of knowledge and cut through the pointless incantations to get to the true nuggets of understanding. The pattern extends beyond software development too. Think about enterprise documentation systems like SharePoint in a large organization. Finding anything useful is nearly impossible. It fits the same bucket of wasted knowledge, difficult to ramp up for no core reason, making everyone’s life harder.
The ability of AI to sift through the noise and surface what you’re actually trying to accomplish… I think this is incredibly important from an efficiency perspective across a surprisingly wide range of work. Hopefully there’ll be far less wasted time in the future.y
Content Negotiation: Markdown for Agents, HTML for Humans (21:14)
“For their documentation site use content negotiation. So when Claude Code asks for a page instead of sending the HTML, respond directly with the markdown so it uses less tokens to interpret it.”
I hadn’t really thought about having a version of the web solely for agents to use. It may well emerge naturally, but it’s not something I’d actively push for. It would be more of a side effect of benefits that accrue to end users.
That said, I sort of already do this to a degree. In Cursor projects, I’m putting together small markdown files that are token-efficient for agents to consume. This could easily be extended to a published website. It would be straightforward for this Astro site to have a token-efficient markdown version available alongside the HTML.
I can definitely see this happening for APIs first, because the needs of an agent are quite different from the needs of a deterministic program. Traditional APIs assume the caller knows exactly what endpoints exist and what parameters to pass. Agents need more context, more flexibility, and less rigid structure. Interesting times.
The $10,000 Coding Agent Bill (23:38)
“I’m going to have it just keep iterating until it passes the test and it ran for a few hours and it cost me $10,000… for those that are watching be careful. I was like, ‘Whoops.’”
I haven’t had a massive coding agent bill experience to date, thank God. I do have a problem with accumulating too many AI service subscriptions, but the business model of keeping a well-defined monthly amount is important. These fixed-price subscriptions are the thin edge of the wedge before usage-based pricing becomes the norm.
This reminds me of a long time ago, before the internet was really widespread in Western Australia. I used a service called CompuServe, a dial-up environment, and once got a $1,200 bill out of the blue. That was painful, and $1,200 was a lot of money back then (early 90s, I think). Not something I want to repeat with AI services.
CEO’s Mission: Code Without Coding (31:02)
“I want to make it my mission to become an equally good developer without writing any code myself. And ideally without looking at code.”
This hasn’t been my experience. I’ve always been coding, even as someone quite senior. It’s probably been to my commercial detriment, but I lose interest and get frustrated without interacting with code directly, without understanding what’s actually possible with the current set of technologies. There’s something about staying hands-on that keeps me grounded in what’s real versus what’s theoretical.
The Team Shouts at Me (31:56)
“Wait, but you haven’t looked at the code?” — “When I do PRs to our actual code bases, I do go and look at the code because I’ve learned the hard way that otherwise the team does and they shout at me.”
This is another aspect that hasn’t matched my experience. I’ve been coding consistently and involved in PRs to actual codebases, even when I could be viewed as senior management level.
That said, it does remind me of a scenario where I was working on a project with competing software developer supply companies. The positions of power shifted, and I found myself in a more subservient coding role rather than a management direction role. It’s no problem. If you’re no longer making the high-level decisions, I’m quite happy to respond to PR feedback based on the goals of whoever is managing the project.
So there’s a version of “shouting at me” that I’ve experienced. It’s not really shouting. It’s more like “do it this way.” I don’t see a problem with it. Okay, no problem, let’s do it that way and move on.
Checking Coding Agents at Dinner (33:42)
“I was at dinner… literally like a VC at a dinner like talking about deals, checking how my coding agents are doing.”
I did try using the beta of Claude Code for the web in this async mode where you’re out and about, checking in with the coding agent to kick it along. It wasn’t particularly successful, but that’s probably on me for not prepping the context well enough. You get into this mode where you keep pushing the agent, kicking it along when you know you should stop and review the context properly. There’s a psychological weakness at play: “if I just push it a little bit more, it’ll get over the hump.” It’s not always the case. This will be an interesting, evolving interaction pattern to figure out.
Every Technical Founder CEO is Coding Again (34:12)
“Every founder CEO with a technical background I talk to now are doing pull requests. It’s just really funny.”
I’m an advocate of using something like Cursor as a project documentation environment, not just a coding environment. There’s so much you can do with it.
This part of the podcast made me think: it would be valuable if non-technical roles used the Cursor AI environment in their workflow without necessarily coding. They could use version control to maintain their content, working in a PR-oriented workflow. Traditional office software environments are so far behind what you could do with something like Cursor. There’s a real value proposition there.
I’d love to see non-technical people adopt this workflow. I’m sure this is just me having too much of a developer mindset, but the workflow advantages seem clear: version history, branching, reviews, collaboration. The tools are ready. The cultural shift is the hard part.
The AI Content Cycle (35:00)
“The cliche is like to sound fancy I use AI to create something big and then to read it you use AI to summarize it.”
It’s quite easy to fall into something like this, or a variation of it, especially when you’re time-pushed. It’s definitely a potential problem. However, I don’t want to give up on using these tools to get things done better and quicker. I’m not precious about using AI for writing and diagrams. I view it very much as another tool in my toolset, but do recognize that it’s very easy to fall into AI-codependent patterns.
The Future is Weirder, Wilder, and More Wonderful (36:55)
“We’re going to have an unimaginable amount of more software… maybe some of it will be bad but there’ll also be a lot more. The future is going to be weirder, wilder, and more wonderful than we could imagine.”
This resonates completely. People underestimate just how much unwritten software the world needs. Countless tools and systems have never been started because the historical friction to begin and complete them was prohibitively high. Now that barrier has collapsed. We’ll experiment with projects and build tools that previously seemed too costly to attempt. This expansion represents a genuine opportunity. Software can do far more for people than current solutions address.
The challenge lies in managing expectations. Expectations have always run unrealistically high, particularly among those unfamiliar with the development process. The ability to accomplish more and implement additional solutions is undeniably positive. Yet expectations around delivery timelines will remain problematic, even as actual development accelerates.
This connects to recent conversations with customers about choosing Three.js over game engines like Unity. Unity’s absurd recent price increases make this comparison especially relevant.
Vibe Coders Today = Front-End Devs in 2015 (39:33)
“There’s still this notion of like ‘oh these vibe coders, they’ll still need like a real developer to come’… and we will give them the tools and we will just see this massive [expansion].”
And coincidentally again, I’ve been talking about the same thing with my customers in terms of leveraging non-developers who have taste and sensibilities in other areas—designers, 3D artists, writers. Software developers may feel protective, like “this is my patch,” you know—a don’t-move-my-cheese sort of deal. But from an organizational perspective, being able to expand software development, or at least the prototyping of concepts, to a broader population has significant benefits.
Software Development Becomes a Universal Skill (40:30)
“I think software development will just be a skill. Just like with writing, there’s still professional writers, but all of us also have to know how to write as part of our jobs. I think development will become like that.”
I find it difficult to imagine that software development would be just another skill. There will still be a need for specialized software developers. But yes, it will also be a skill that cuts across many professions.
I view this as analogous to how people use Excel today. You have professionals across different fields—not software developers—who use Excel in extremely technical and deep ways. They may not follow good patterns, but they understand and leverage Excel as a professional tool.
I think these new coding agent tool sets will work the same way, but with even greater impact. They’ll accelerate and amplify people’s abilities far beyond what Excel currently does, enhancing professional skills across disciplines.
Code Will Become a Niche Thing (43:15)
“Code as we know it today is going to be much more of a niche thing that’s not really very involved in the daily process of software… everything is so code-centric right now. All of that I think is going to evolve to a level of abstraction where it’s much more about understanding the outcome of what the agents do.”
I’m not convinced by this argument, though I understand the reasoning. Computing has been moving up abstraction levels since the beginning. I wrote a Z80 assembly game as a teenager, but I haven’t touched assembly code in any meaningful way since. So there’s certainly a case for working purely in natural language, with code becoming a background concern—something you rarely examine directly.
But I don’t believe code will become niche. Understanding code will remain essential for achieving reliability, at least for the foreseeable future. Whether that’s five years or ten, I can’t say, but the need won’t disappear soon.
This does raise an interesting question: could we develop new programming languages designed specifically for human-AI collaboration? Languages that remain deterministic but are fundamentally different from what we use today, optimized for a world where both coding agents and humans are integral to the development cycle. I can envision this happening, though I’m uncertain what form these languages would take.
One thing seems clear: jumping directly from AI-generated requirements to assembly code would be a mistake. That gap is too large. When things go wrong—and they will—we need the ability to look under the hood of deterministic software rather than relying entirely on non-deterministic, probabilistic AI systems.
People’s Attachment to Their AI (45:35)
“You see people have history with their ChatGPT or Claude and they really have a preference. They don’t want to go to the bank’s AI and talk to that. They just want to interact in that way.”
I haven’t experienced this sort of attachment to artificial intelligence and chatbots. Maybe it’s because I use them in a purely utilitarian way to get tasks done. I certainly understand the potential in this area. Perhaps when I’m older and in the twilight of my life, it may be more of a comfort to have an AI to chat with. I don’t know. It’s a tough area, and it’s easy to see how there could be mental health issues associated with unhealthy attachment to AI interactions.
I do get frustrated, however, when vendor-provided AI is clearly way behind modern frontier models or the ones I commonly use. Microsoft’s Office Copilot exemplifies this. It promised so much initially but hasn’t delivered. I’d rather vendors let me bring my own AI service to their data instead of forcing a completely canned experience.
”You Are the Developer” Philosophy (47:47)
“Our approach has really been like ‘you are the developer’… if you want to go on this journey, you’re now a developer and you have to learn things. You have to understand how software is built. Code is a little part of it, but you have to know some element of what’s happening in the world.”
This extends what the podcast mentioned. I think there’s something that applies to AI use in general: you are the final arbiter. When you use AI to produce content, you’re putting your stamp on it. You have a responsibility to ensure the work gets done well.
This isn’t quite what the podcast emphasized, but it’s what came to mind. Don’t use AI blindly. In the end, you remain the developer, the lawyer, the teacher, or whatever role is leveraging AI. The professional responsibility stays with you.
Reclaiming Power from Junior Devs (50:01)
“Maybe that’s why all founder CEOs are now programming with agents because… you start hiring these developers and they come back with a thing that’s like pretty cool but it’s like ‘why did you do it that way’… you’re almost like reclaiming power.”
This blog post started with a “it’s funny because it’s true” reference to developers needing to handle continuous failure. I laughed at this statement too, embarrassingly, because it’s funny. Because it’s true.
People complain about coding agents not being deterministic and not doing what they expect. But you get that with people too. You define requirements, explain something clearly, and it comes back in unexpected ways. The typical response is “you haven’t specified it correctly.” Sometimes that’s true. But sometimes we’re literally dealing with probabilistic, non-deterministic systems—namely, the wide variety of people who develop software.
People think differently. They lack shared experiences you assume they have. They push back because they don’t share your experience and won’t accept it. I’m not saying I’m always right. But sometimes people lack the experience to know it’s better to follow instructions rather than override them based on existing opinions. This is hard to describe without sounding overbearing, but software developers can be frustrating in similar ways to coding agents.
There’s a certain liberation when a coding agent simply does what you asked to the best of its ability. I know you’re not supposed to anthropomorphize, but when it tries its best and doesn’t push back based on opinion—when it just does what you say—that’s empowering. That’s why these guys laughed about the pattern recognition between junior devs and coding agents.
You Still Have to Put in the Work (55:02)
“It’s not like labor is being removed. The best people still work the hardest at it. The best people still spend the most amount of time… It is managed magic in that it gives you a result, but it is not magic in that you still have to put in the time and the effort to learn it.”
This is the perfect closing note. AI tools are remarkable enablers and accelerators, but they don’t eliminate the fundamental need for effort, learning, and persistence. The craft itself is evolving. The barrier to entry has lowered dramatically, but excellence still requires dedication. Now I just have to convince stakeholders and customers of this while managing expectations… so things haven’t changed that much 😁.