I've been having the same conversation with my colleagues for months. What does it mean to create educational content for developers when the audience is shifting to people who may not write code at all?
In Episode 7 of Making Software, I talked to James Quick, Developer Educator at Cloudflare. He's been in developer relations for 13 years, starting at Microsoft before most people knew that was a job. He hasn't written a line of code in 8 months, and in that time he's built more than ever before.
The audience we've been building for has quietly changed. We call them builders now. People who want to ship things and don't want to understand what's underneath. That changes what educational content is actually for, and most people making it haven't updated yet.
Building for yourself has a different math now. James built a Frame.io clone for his team, cancelled his QuickBooks subscription, and replaced Descript. His point isn't that everyone should do this. It's that the cost of building something for yourself has dropped enough that the old calculation doesn't hold anymore.
AEO is the thing most teams aren't thinking about yet. Cloudflare is actively working on what it means to show up when a builder tells an LLM "deploy my app." Answer Engine Optimization. Most developer tool teams haven't started on this.
Every app you build should have an MCP server. James says he can't think of a single thing he's built that wouldn't benefit from being agent-accessible. Manual data entry is just the worst version of any workflow.
Things that stuck with me
I admitted something in this episode I've been avoiding saying out loud. I miss coding. But the second an LLM does something in seconds, I catch myself thinking "do I really, though?" James is on the complete opposite end of that. He told me:
"Not writing code is not a concern for me at all. Like, I don't miss that one bit."
Two people doing the same job, arriving at completely different places about what this shift means. I found that more useful than any hot take about whether AI is taking developer jobs.
The Twitter argument about QuickBooks stayed with me. Someone pushed back on James saying he hadn't really replaced it because he was missing credit card integrations and enterprise features. His answer:
"I don't need to build a SaaS product that works for other people. I am the user."
That reframed something for me. I always default to thinking about what something would need to look like at scale, about what it would take for other people to use it. He just didn't. That's a more useful default than I've been giving it credit for.
And then there was Dropcast. He was drowning in things he wanted to learn and built a tool that takes links, crawls them, generates a podcast episode, and pushes it to an RSS feed he listens to on his commute. I immediately thought: I need this.
I left this conversation still unsure whether I miss coding or just the feeling of having written something. But I'm thinking about the build vs buy question differently now.
Are you still thinking of yourself as a developer, or has that shifted to something else? I'm curious how people are sitting with this. Let me know in the comments.
Listen to the full episode
Available on YouTube, Apple Podcasts, and Spotify.
Check all episodes: https://makingsoftwarepodcast.com
Thanks for reading! 👋
Top comments (5)
The shift from "writing code" to "building software" that James describes is exactly what I experienced testing AI tools this year. The bottleneck has moved from syntax to architecture — knowing what to build and how to compose existing services matters more than typing the implementation yourself.
The AEO (Answer Engine Optimization) point is fascinating and under-discussed. When a builder tells an LLM "deploy my app," whoever's tooling shows up in that answer wins the distribution. It's the new SEO, but the rules are still being written.
One thing I'd push back on slightly: "every app should have an MCP server" is directionally right, but the security boundary question matters here too (see the recent Anthropic incident discussion). Making every app agent-accessible without careful permission scoping is how you get blast radius problems. The MCP server should expose a narrow, well-defined capability surface — not a general-purpose API with full credentials.
The part about replacing SaaS subscriptions with self-built tools is the real economic insight. When the cost of building drops by 10x, "buy vs. build" flips for a lot of tools in the $20-200/month range.
This matches my last few months more than I would like to admit. I still open the editor, but most of my time now goes into describing the problem well and checking the output rather than typing the lines. The part nobody warns you about is how much harder reviewing gets when you did not write the first draft.
My real job title now is babysitter. Manager on a good day.
The agent types everything. I write the rules it isn't allowed to break, and I catch it being confidently wrong. Somehow that still feels like engineering, just aimed at a coworker instead of a compiler.
The strange part: my brain works harder now than when I wrote the code myself. Typing was the rest period, it turns out. Now the whole day is decisions. What to build next, is the output actually right, which corner did it quietly cut. And since I build way more than before, there are way more decisions.
The "I am the user" reframe is the part I keep turning over. Working on static analysis tooling, I notice that when the builder and the user are the same person, the pressure to reason about what the code actually does essentially disappears — and that's fine until it isn't. AI-generated internal tooling is the new shadow IT, except the blast radius is often harder to contain because the author couldn't have explained the behavior to a linter, let alone a reviewer. Not a reason to stop building, but it's the accountability gap this whole conversation is dancing around without naming.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.