Jonathan Wondrusch (Block): Raising Ambition in the Singularity

Jonathan joins Alex and David to talk about what actually changes when agents get good enough to do the work. He walks through the 60-service monorepo migration that convinced him the ceiling had moved, why "raising ambition" is now a real coaching conversation with his team, and how Block is using linters and LLM-as-judge to keep GraphQL API design honest.The conversation goes past the usual velocity story into the harder question: engineering is multiplayer, and most AI tooling is still single-player. Jonathan makes the case that the human touch points — design reviews, pairing, cross-functional feedback — are the part you have to deliberately protect, not the part you optimize away. Plus: adversarial code review with mixed models, why he'll let an agent write his code but not his voice, and the trap of low-hanging fruit that doesn't compound.https://x.com/JWondruschhttps://x.com/davidnoelromashttps://x.com/voidfiles

Karla joins Alex and David from Sydney, where she's been building security-conscious AI workflows at Lorikeet--a customer service automation company where writing code by hand has officially become "artisanal."https://www.lorikeetcx.ai/https://x.com/tetrakazi

Dylan Vassallo is an engineering manager at OpenAI leading the People Innovation Labs team — an eng, product, and design team embedded within the People org, building AI-powered tools for recruiting, HR, internal comms, and the employee experience.In this episode, Dylan talks about what it actually looks like to be an engineering team inside a frontier AI company, how non-engineers are becoming builders, and what the "graduation" process looks like when a prototype needs to become a production system.Links & Referenceshttps://x.com/dylanveeOpenAI Codex - https://openai.com/codexLattice - https://lattice.com — performance management platform mentionedLinear - https://linear.app — used for team project trackingWorkday - https://workday.com — referenced as system of record

Hosts: Alex Kessinger & David Noël-Ramos Guest: Karynn Ikeda — Former Engineering Manager → AI Enablement Program Manager at Babylist @ktikedaKarynn Ikeda shares the full arc of how Babylist adopted AI across its engineering organization — from a six-week Windsurf pilot on a single team, to company-wide Claude Code adoption and a bold initiative to onboard product managers and designers into the codebase. She discusses leadership buy-in, measuring developer sentiment over raw velocity metrics, the shift toward agent orchestration, and why the return of joy and creative empowerment may be the most important signal of all.Links & ReferencesKarynn Ikeda (@ktikeda)Babylist  babylist.comShopify CEO Tobi Lütke's AI Memo (April 2025)  Original post on XAnthropic Code Review for Claude Code  claude.com/blog/code-reviewClaude Code  code.claude.comDevin (AI coding agent by Cognition)  devin.aiCursor  cursor.comWindsurf windsurf.comLovable (vibe coding tool)  lovable.devV0 (by Vercel)  v0.dev

Will Maier leads growth engineering at Stripe, where he's spent the last five years working across nearly every surface of the product. His background isn't CS — it's the history of science — and he's been through enough industry shifts (racking servers, the cloud transition, DevOps) to know when something really big is happening.Find us now also on YouTube: @StaffEngPodcoastIn this season premiere of StaffEng, Will joins Alex and David to talk about what changed for him after November 2025, why he spent the holidays building a Lua distribution from his phone while doing laundry, and how he thinks about the organizational dynamics of AI adoption inside a large engineering org.Topics covered:Why Will hasn't opened an IDE since November — and what replaced itThe psychology of AI adoption: shame, hallucinated PRs, and "AI vegans"Skills as the new packages: how improvised markdown files are changing how teams share leverageWhy measuring token usage (the wrong metric) surfaced the right insightsThe case for making the incident report critic, not the incident report writerWhat the cloud and DevOps transitions teach us about where AI is headed

After 3 years, we’re coming out of retirement, because something fundamental broke open in the last few months—something that changes everything about how we work.We Don’t Know How to Learn This YetAI coding tools promise a 10X—maybe 100X—productivity boost. But here’s what we’re seeing: most engineers don’t know how to learn these tools. The old playbook—read the docs, practice, master—doesn’t work when the tools are fundamentally stochastic and changing weekly. Even worse, there’s nowhere to go for real instruction. Documentation tells you what features exist, not how to think differently about your work.I’ve never felt this much behind as a programmer. The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse and between. I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year… - @karpathyDeep Conversations with PractitionersWe’re rebooting the Staff Engineer podcast with a specific focus: practitioners using AI to deliver valuable outcomes with specific examples.The Future Isn’t Evenly DistributedRight now, there are deep pockets of breakthrough AI usage everywhere. From engineers, to philosophers. Small teams moving at speeds large organizations can’t match..These practices exist, but they’re isolated.What We’re Looking ForPractitioners over theorists. We’re not interested in abstract conversations about what AI might do. If you’re using AI to deliver outcomes and have specific examples of what worked and what didn’t, we want to talk.Details over declarations. “AI made me 10X more productive” is a headline. “I rewrote my entire workflow around X pattern, which failed until I realized Y, and now I’m shipping features in days that used to take weeks” is the conversation we want.Diverse domains, unified question. We’re starting with staff engineers because that’s our foundation—engineers expected to show great judgment at scale. But we’ll talk to anyone whose work sheds light on our core question: What does good engineering judgment look like when the tools are stochastic, the landscape changes monthly, and the bottleneck shifts from implementation to direction?Our ThesisA fundamental shift is happening in how we work. The engineers authoring this future—not just experiencing it—will have massive advantages. We choose authorship.But we don’t know what that looks like yet. We don’t have the playbook. That’s what we’re building.How to ParticipateWe’re setting this up in two ways:1. Join Our Listening SessionsBefore we start recording episodes, we want to hear from you. We’re organizing Zoom sessions to discuss:What you’re running into with AI in your workThe problems you’re facingThe surprising winsThe bureaucratic barriersThe things you wish someone would talk aboutSign up to join a session2. Suggest Guests (Including Yourself)Know someone doing interesting work with AI? Are you doing interesting work with AI?We’re looking for:Practitioners (not people selling AI tools)People delivering outcomes, not just observingSpecific examples of what worked and what didn’tWillingness to go deep on the detailsFill out form with your suggestions

This episode is a celebration of the journey we have been on as this podcast comes to a close. We have had such a great time bringing you these interviews and we are excited about a new chapter, taking the lessons we have learned forward into different spaces. It's been a lot of work putting this show together, but it has also been such a pleasure doing it. And, as we all know, nothing good lasts forever! So to close the circle in a sense, we decided to host a conversation between the two of us where we interview each other as we have with our guests in the past, talking about mentorship, resources, coding as a leader, and much more! We also get into some of our thoughts on continuous delivery, prioritizing work, our backgrounds in engineering, and how to handle disagreements.  As we enter new phases in our lives, we want to thank everyone for tuning in and supporting us and we hope to reconnect with you all in the future!LinksDavid Noël-Romas on TwitterAlex Kessinger on TwitterStitch FixStripeJavaScript: The Good PartsDouglas CrockfordMonkeybrainsKill It With FireTrillion Dollar CoachMartha AcostaEtsy Debriefing Facilitation GuideHigh Output Management How to Win Friends & Influence PeopleInfluence

The structures of an organization can often be self-reinforcing, and in a changing environment, this becomes a recipe for future vulnerabilities. That is why senior ICs need to play a slightly discordant role at times by alerting teams to issues conventionally outside of their bubble of concern. Peter Stout is a Technical Director at Netflix where he has a cross-functional role at the juncture of business and technology. He joins us on the show today to share some of the finer details around what inhabiting this position in the above manner looks like. We start by hearing Peter describe himself as a generalist, and share how this played out in the broad focus of his college degree as well as in his career pivot from Chemistry into Software Engineering. We discuss the rapid growth of the engineering team at Netflix, how this has led to less tightly-defined roles for junior and senior engineers, and how this factors into the way Peter approaches his place in the organization. Peter talks about the shift he made from technician to technical director and how much of the skills he learned from the former position he brings into the latter. He talks about his tendency to seek out the blank spots in the organization and how he tries to focus on a long-term vision, using that to guide him as he connects the dots between teams and influences decision making. Here Peter considers his role as a disruptor and how he gauges how much pressure to apply while still staying largely in sync. We also have a great conversation about Peter’s approach to mentorship and his philosophy around how he grew into the leadership position he occupies. Tune in today!LinksPeter Stout on LinkedInNetflixRangeThe Leadership Pipeline

Often the biggest impacts a Staff Engineer can make in their organization are not technical but rather people-related. When teams are value-aligned due to good leadership, they go on to make larger impacts than they would otherwise have. As Senior Principal Engineer at Dropbox for almost a decade, James Cowling learned a lot about how people think and work together, and he joins us today to share some of his insights. Joining this conversation, listeners will hear about James’ experience at the helm of numerous high stakes projects at Dropbox, such as migrating the company off Amazon S3 by building their own distributed storage system. For James, the main job of a tech lead is getting their team to have a firm grasp of the why behind a project, and to become completely values-aligned as a result. James takes us through his approach to diagnosing struggles within teams and how he helps groups to step back and course correct by drilling down on their purpose within the larger organization. We talk about the strong culture that gets built as a result of this approach and the power it has to keep teams robust. In today’s conversation, James also gets into how Staff Engineers themselves can stay in tune with the larger company, the single most important quality to nurture in Software Engineers who hope to grow into leadership positions, and a whole lot more.LinksJames Cowling on LinkedInJames Cowling on TwitterConvexDropbox'Stepping Stones not Milestones'

Staff engineers may not get much time to code anymore, but this does not mean problem-solving and system design is not an integral part of their day-to-day. Today’s guest is Bryan Berg, Staff Engineer at Stripe, and he joins us to talk about the nuances of his position and his unique approach to the many challenges it entails. As a Staff Engineer, Bryan acts as Tech Lead of the Traffic team, and we begin our conversation by hearing about how he landed in this role. Bryan describes the ambiguous challenges he faced during earlier days at Stripe, and the knack he had for finding and working on processes and systems that were previously underinvested in. We then jump forward to the present and dig into what Bryan’s current role entails, hearing him describe a wide range of tasks from reviewing documentation, communicating between teams, writing vision documents, and ensuring the work he directs falls into the company and stakeholder requirements. We also explore the interesting concept of when to draw on past experience versus keeping an open mind when facing new challenges. On top of all this, our conversation covers how Bryan judges the success of his work, sustains faith in his ideas, pitches to colleagues, debugs difficult pieces of code, and finds inspiration to be a great technical leader.