Episode 2: The Developer Role Is Changing

James was at a local tech meetup when a seasoned developer - someone who’s been in the industry as long as Lee and James - asked for help with a coding problem. He’d spent hours on it, Googled it extensively, asked other developers at the meetup, and nobody could crack it. James suggested he paste the error into an LLM. The developer’s response? “I don’t have an account for that.” James pointed out there’s a free version. Four weeks later, at the next meetup, the developer was stunned - Claude Code had fixed the issue in seconds, explained what the problem was, why it was a problem, and how it made the fix. And not a single person in the original conversation had thought to suggest AI as a solution.

This isn’t an isolated case. At a recent meetup dedicated entirely to AI, James found that developers from all backgrounds - startups, enterprise, education - still viewed AI as jumped-up predictive text. They’d tried it twelve months ago when it wasn’t great, and they’d never gone back. The incremental improvements had passed them by completely. James admits he did the same thing with Claude. He’d tried the web interface early on, found it terrible, and dismissed it. It took weeks of his developer circle banging on about Claude Code before he finally installed it. The moment he did, he stopped using Cursor - a tool he’d paid for annually - and never looked back.

The core of this episode is about how the developer role itself is transforming. Lee and James make the case that typing code was never the valuable part of being a developer - understanding the problem and knowing how to solve it correctly was always the real skill. With AI increasingly handling the typing, the role is shifting toward what James calls spec-driven development. Instead of getting a vague ticket description and spending days going back and forth with product owners and project managers, the future developer sits down in one session, thrashes out exactly what needs to be built, defines use cases, acceptance criteria, and coding standards, and hands that specification to an AI to execute. The developer then becomes the first level of code review - checking the output, validating it works, and passing it to QA.

This leads to a provocative prediction: the project manager role might be the one that disappears. Lee and James argue that the gap between the technical and non-technical has always been the source of friction in software teams. Developers understand systems but often can’t communicate with the business. Project managers understand the business but can’t validate the technical output. If the developer role shifts toward understanding and documenting requirements - essentially absorbing the product management function - then the traditional PM becomes redundant. The developer becomes a technical product manager who can both define and validate the solution.

James turns the question around: does the PM learn to be technical, or does the developer learn to communicate? Lee’s honest answer is that most developers he knows are terrible at documentation and hate talking to clients. But equally, teaching non-technical people to understand software deeply enough to guide AI-driven development is an even harder ask. The shift will likely come from both sides, with developers needing to improve their communication and documentation skills while business people develop more patience and literacy with AI tools.

The episode’s most memorable segment comes from Lee’s ongoing quest to design a doorstop. His apartment in Abu Dhabi has balcony doors that catch a crazy side wind, and he can’t find a product that solves his specific problem - a U-shaped weighted stop that wraps around the door with a rope handle. He takes this to Google’s image generation tools and demonstrates in real time how AI iteration works. The first attempts are hilariously wrong - door handles at borrower-height, misplaced rope, wrong proportions. But with each prompt refinement, it gets closer. James draws a sketch on paper, feeds it to the AI, and the results improve dramatically. The point they’re making is that AI requires iteration and patience, and most people give up after two or three attempts. Be it a doorstop design or a coding problem, the people who succeed with AI are the ones willing to refine their prompts, provide more context, and keep pushing.

James also shares his journey from Claude sceptic to convert. What blew him away about Claude Code was watching it think. Unlike ChatGPT at the time, which would just produce a single answer and move on, Claude Code would start building something, pause, review its own work, decide it wasn’t right, go and read the documentation, discover there was a newer API version, and rebuild using the better approach - all without being asked. It was, for all intents and purposes, thinking about the problem in the same way a developer would, just faster. James is careful to note this doesn’t mean it’s always right - you still need to review the output - but the self-correcting, self-reviewing workflow was a genuine paradigm shift for him.

The conversation takes a serious turn when they address the elephant in the room: if AI doubles developer productivity, what happens to the workforce? Lee frames it starkly - companies have three choices: lay off staff, pursue significantly more work to justify the same headcount, or pay people more because the value being created has increased. He doesn’t think most companies will choose options two or three. James backs this up with real examples from his career - building a system that reduced call centre volume by 94 percent, automating a documentation process that made an entire team’s daily routine obsolete. In each case, the company chose to reallocate staff rather than sack them, but he acknowledges not every company will make that choice. The difference now is that AI is pointing the productivity gun at developers themselves, not just the departments they build tools for.

They close with a call to action that runs through the entire episode: experiment. Build something. Use the tools. The industry is splitting into AI-augmented teams and non-augmented teams, and the gap between them is widening every month. Whether you’re a developer, a project manager, or a business owner, the time to figure out where you stand is now - not in three years when the shift has already happened.

Subscribe, share, and experiment - the industry is shifting whether you’re ready or not.