Show Notes
Coding Chats Episode 83 - In this episode, VB from OpenAI’s developer experience team explains why he thinks plan mode is obsolete and how coding agents have shifted from step-by-step instructions to outcome-driven, long-running work. We cover how to write a good agents.md, why tests still matter when agents write the code, spec-driven development, and why cloud agents may be the future of dev tooling.
We also get into the practical details: how prompt caching works and why running one thread per task can cut your cost and latency, plus the biggest announcements from OpenAI’s Dev Day, including GPT 6.1 Sol, ultra fast inference, plugins, and proactive async agents. VB closes with the Codex Ambassadors program and Codex for open source. If you use Codex, AI coding agents, or any agentic coding workflow, there’s something here for you.
00:00 Introduction to Developer Experience at OpenAI 03:29 Bringing AI Models to Developers 06:06 The Shift from Planning to Outcome-Focused Development 09:05 The Role of Testing in AI Development 11:51 Creating Effective Agents.md for AI Projects 17:17 The Evolution of Developer Tools at OpenAI 25:21 Cloud Development: The Future of Coding 26:48 Insights from OpenAI's Dev Day 28:00 Revolutionizing Development with GPT 6.1 Soul 32:35 Understanding Caching for Developers 39:02 Proactive Agents: Enhancing Productivity 42:39 Community Initiatives and Open Source Contributions 48:36 Exploring Related Content
VB's Links: https://openai.com/
John's Links: John's LinkedIn: https://www.linkedin.com/in/johncrickett/ John’s YouTube: https://www.youtube.com/@johncrickett John's Twitter: https://x.com/johncrickett John's Bluesky: https://bsky.app/profile/johncrickett.bsky.social
Check out John's software engineering related newsletters: Coding Challenges: https://codingchallenges.substack.com/ which shares real-world project ideas that you can use to level up your coding skills.
Developing Skills: https://read.developingskills.fyi/ covering everything from system design to soft skills, helping them progress their career from junior to staff+ or for those that want onto a management track.
Takeaways Plan mode is obsolete because current models plan inherently, so you’re better off spending your time up front defining the outcome you want. Developers are moving from prescribing steps to defining intended outcomes (like “get this CI green”) and letting the agent plan, execute, and adjust on its own. Spec-driven development has its place, especially for API-shaped work, but it backfires if the spec isn’t kept in sync with every change. A strong but lightweight agents.md should cover where code lives, how the agent knows it’s doing a good job, your style rules, and what a good PR looks like. Tests still matter when agents write the code, because they catch regressions before merge, but the agent needs guidance on which tests are worth writing. Treat agents.md as a living document that grows as you work with the agent, not something you get right in one shot. To get the most from prompt caching, use one thread per feature and a couple of narrowly scoped subagents instead of running a dozen agents and letting the cache go cold. Coding workloads have large inputs and small outputs, which is why caching makes them so much cheaper and faster than typical chat use. Cloud agents are where dev tooling is heading, since they remove “works on my machine” problems and free long-running tasks from your laptop. If you’re still on the fence about coding agents, give one real task to an agent, watch how it interprets your request, and refine your instructions from there.
More from Coding Chats
Coding Chats Episode 82 - John talks with Dave Westgarth, head of delivery at a Databricks consultancy. Dave shares his path from a psychology degree and McDonald's into tech, and they discuss why the Scrum Master role is so misunderstood, how it differs from a delivery manager, and whether either needs to be technical.They also look at how AI is changing delivery work. Faster code just moves the bottleneck upstream, John argues there's no AI-specific skill you can't learn in a day, and engineering fundamentals are what make AI useful.
Coding Chats Episode 81 - Ben Howdle talks to John Crickett about being a first time CTO in a start-up. Ben, author of The First CTO, shares what changes when you move from building technology to leading a technical team: the pressure, the trade-offs, and the realization that writing code is only part of the job.Drawing on startup experience and lessons learned the hard way, Ben discusses how to balance quality against runway, manage people, and communicate technical decisions in terms that founders and other non-technical stakeholders can understand. He also explores why resourcefulness, resilience, and comfort with ambiguity matter so much—and why CTOs often spend more time selling ideas than they expect.Whether you’re stepping into your first CTO role or leading a technical team at an early-stage company, this conversation offers candid insights into the realities of technical leadership.
Coding Chats Episode 80 - start-up advisor Alexander Berkovich shares his expertise on building successful start-ups, hiring strategies, CTO roles, and the importance of communication between technical and business teams. Discover practical tips for navigating the challenges of early-stage companies and how to align technical excellence with business goals.
Coding Chats Episode 79 - Richmond Alake, Director of AI Developer Experience at Oracle, joins John to discuss agent memory — how AI agents store, retrieve, and adapt to information. He argues that developers building memory on flat files are naively reinventing the database, and that once you factor in concurrency, security, and scalability, a proper database is inevitable. The conversation covers the full memory stack and how Oracle's AI database keeps embeddings and data together without shipping sensitive information to external providers.
Coding Chats Episode 78 - John Crickett talks to Robert Harris, an experienced engineering leader. Robert shares hard-won lessons from years of leading software teams, drawing on a distinctive "human systems" lens to explain why so many engineering organisations struggle — not because of bad people, but because of broken systems, misaligned leadership, and invisible cultural forces.