This episode covers the 10 biggest AI stories of 2025—how DeepSeek’s R1 shook markets, pushed reasoning into the mainstream, and intensified the US–China model race. It also breaks down the massive AI infrastructure boom (Stargate, hyperscaler capex, energy + data centers), the nonstop AI bubble debate, and what enterprise adoption really looked like behind the headlines. Finally, it explores the rise of vibe coding, the standardization of agent infrastructure (MCP, agent-to-agent protocols, context engineering), and the “next leap” models—Gemini 3, Opus 4.5, and GPT-5.2—setting the tone for 2026.
Brought to you by: KPMG – Go to www.kpmg.us/ai to learn more about how KPMG can help you drive value with our AI solutions. Vanta - Simplify compliance - https://vanta.com/nlw
The AI Daily Brief helps you understand the most important news and discussions in AI. Subscribe to the podcast version of The AI Daily Brief wherever you listen: https://pod.link/1680633614 Get it ad free at Join our Discord: https://bit.ly/aibreakdown
Wes and Scott revisit their 2025 web development predictions, grading hits and misses across AI, browsers, frameworks, CSS, and tooling. From Temporal and AI coding agents to React, Vite, and vanilla CSS, they reflect on what actually changed, what stalled, and what it all means heading into 2026.
Xmas Special: Recovering the Essence of Agile - What's Already Working in Software-Native Organizations
In this BONUS Xmas Special episode, we explore what happens when we strip away the certifications and branded frameworks to recover the essential practices that make software development work. Building on Episode 2's exploration of the Project Management Trap, Vasco reveals how the core insights that sparked the Agile revolution remain valid - and how real organizations like Spotify, Amazon, and Etsy embody these principles to thrive in today's software-driven world. The answer isn't to invent something new; it's to amplify what's already working.
Agile as an Idea, Not a Brand
"The script (sold as the solution) will eventually kill the possibility of the conversation ever happening with any quality."
We establish a parallel between good conversations and good software development. Just as creating "The Certified Conversational Method™" with prescribed frameworks and certification levels would miss the point of genuine dialogue, the commodification of agile into Agile™ has obscured its essential truth. The core idea was simple and powerful: build software in small increments, get it in front of real users quickly, learn from their actual behavior, adapt based on what you learn, and repeat continuously. This wasn't revolutionary - it was finally recognizing how software actually works. You can't know if your hypothesis about user needs is correct until users interact with it, so optimize for learning speed, not planning precision. But when the need to certify and validate "doing Agile right" took over, the idea got packaged, and often the package became more important than the principle.
Four Fundamental Practices That Enable Living Software
"Every deployment was a chance to see how users actually responded."
Software-native organizations distinguish themselves through core practices that align with software as a living capability. In this episode, we review four critical ones: First, iterative delivery means shipping the smallest valuable increment possible and building on it - Etsy's transformation from quarterly releases in 2009 to shipping 50+ times per day by 2012 exemplifies this approach, where each small change serves as a learning opportunity. Second, tight feedback loops get software in front of real users as fast as possible, whether through paper prototypes or production deployments. Third, continuous improvement of the process itself creates meta-feedback loops, as demonstrated by Amazon's "You Build It, You Run It" principle introduced by Werner Vogels in 2006, where development teams running their own services in production learn rapidly to write more resilient code. Fourth, product thinking over project thinking organizes teams around long-lived products rather than temporary projects, allowing teams to develop deep expertise and become living capabilities themselves, accumulating knowledge and improving over time.
Spotify's Evolutionary Approach
"The Spotify model has nothing to do with Spotify really. It was just a snapshot of how that one company worked at the time."
Spotify's journey reveals a critical insight often missed in discussions of their famous organizational model. Starting with standard Scrum methodology pre-2012, they adopted the squad model around 2012 with autonomous teams organized into tribes, documented in Henrik Kniberg and Anders Ivarsson's influential white paper (direct PDF link). But post-2016, internal staff and agile coaches noted that the "Spotify model" had become mythology, and the company had moved on from original concepts to address new challenges. As Kniberg himself later reflected, the model has taken on a life of its own, much like Lean's relationship to Toyota. The key insight isn't the specific structure - it's that Spotify treated their own organizational design as a living capability, continuously adapting based on what worked and what didn't rather than implementing "the model" and declaring victory. That's software-native thinking applied to organization design itself.
Amazon's Two-Pizza Teams and Massive Scale
"Amazon deploys code every 11.7 seconds on average. That's over 7,000 deployments per day across the organization." (see this YouTube video of this talk)
Amazon's two-pizza team principle goes far deeper than team size. Teams small enough to be fed with two pizzas (roughly 6-10 people) gain crucial autonomy and ownership: each team owns specific services and APIs, makes their own technical decisions, runs their services in production, and manages inter-team dependencies through APIs rather than meetings. This structure enabled Amazon to scale massively while maintaining speed, as teams could iterate independently without coordinating with dozens of other teams. The staggering deployment frequency - over 7,000 times per day as of 2021 - is only possible with a software-native structure for the company itself, demonstrating that this isn't just about managing software delivery but touches everything, including how teams are organized.
Why These Practices Work
"These practices work because they align with what software actually is: a living, evolvable capability."
The effectiveness of software-native approaches stems from their alignment with software's true nature. Traditional project approaches assume we can know requirements upfront, estimate accurately, build it right the first time, and reach a meaningful "done" state. Software-native approaches recognize that requirements emerge through interaction with users, estimation is less important than rapid learning, "right" is discovered iteratively rather than designed upfront, and "done" only happens when we stop evolving the software. When Etsy ships 50 times per day, they're optimizing for learning where each deployment is a hypothesis test. When Amazon's teams own services end-to-end, they're creating tight feedback loops where teams feel the pain of their own decisions directly. When Spotify continuously evolves their organizational model, they're treating their own structure as software that should adapt to changing needs.
The Incomplete Picture and the Question of Universal Adoption
"If these approaches work, why aren't they universal?"
We're not trying to paint a unrealistically rosy picture - these organizations aren't perfect. Spotify has had well-documented challenges with their model, Amazon's culture has been criticized as demanding and sometimes brutal, and Etsy has gone through multiple strategic shifts. But what matters is that they're practicing software-native development at scale, and it's working well enough that they can compete and thrive. They're not following a playbook perfectly but embodying principles and adapting continuously. This raises the critical question that will be explored in the next episode: if these approaches work, why do so many organizations still operate in project mode, and why do "agile transformations" so often fail to deliver real change? Understanding the resistance - what we call The Organizational Immune System - is essential to overcoming it.
Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.
TL;DR: It’s Christmas Eve, so we’re republishing one of our favorite episodes from our podcast AI & I. Dan Shipper goes in-depth with Reid Hoffman, the cofounder of LinkedIn, author, and venture capitalist. They dive into understanding the way AI functions through the lens of philosophy and using it as a tool to make better business decisions. Though the conversation is from 18 months ago, the insights resonate even when we’re almost in 2026. Watch on X or on YouTube, or listen on Spotify or Apple Podcasts. Here’s a link to the episode transcript.
Was this newsletter forwarded to you? Sign up to get it in your inbox.
Reid Hoffman thinks a master’s in philosophy will help you run your business better than an MBA.
Reid is the cofounder of LinkedIn, a partner at venture capital firm Greylock Partners, the host of the Masters of Scale podcast, a prolific author, and an investor in Every. But before he did any of these things, Reid studied philosophy—and by helping him understand how to think, it made him a better entrepreneur.
A good student of philosophy rigorously engages with questions about truth, human nature, and the meaning of life, and, over time, learns how to think clearly about the big picture. This is a powerful tool for founders faced with existential questions about their product, consumers, and competitors, and enables them to respond with well-reasoned answers and enviable clarity of thought.
I've been diving deep into financial independence planning lately, and as a developer, I naturally wanted a tool that does exactly what I need—without the clutter, ads, or privacy concerns of existing calculators out there. So I decided to build one from scratch using GitHub Copilot's agent mode in VS Code. What started as a simple "let's see what happens" experiment turned into a fully-featured, privacy-first PWA with 9 different calculators, all built in a single conversational chat session in about 30 minutes.
I had a clear vision: a FIRE (Financial Independence, Retire Early) calculator that respects user privacy. No cookies, no analytics, no data leaving the browser. Just pure client-side calculations with the ability to share scenarios via URL parameters.
"I want to build a financial independence calculator app. It should be a React + TypeScript PWA with Tailwind CSS, dark mode support, and work completely offline. Privacy is key—no data storage, no analytics."
The plan agent got to work asking me questions along the way until it had the context it needed and I answered enough questions that I felt good about it getting to work. From there, Copilot scaffolded the entire project structure: Vite config, TypeScript setup, Tailwind with a custom "fire" orange color palette, and even service worker configuration for offline support. Within minutes I had a running dev server.
Iterating Through Features
What I love about working with Copilot in agent mode is the conversational flow. I didn't have to context-switch between planning and implementing. Each feature request built naturally on the previous one.
The Core Calculators
I started with the Standard FIRE calculator—the classic "25x your annual expenses" rule. Copilot generated not just the calculation logic but also:
Responsive input components with tooltips explaining each field
A beautiful projection chart using Recharts
Real-time URL parameter syncing so users can bookmark or share their scenarios
Result cards with the key metrics highlighted
Then came the variations:
"Now add a Coast FIRE calculator. Same structure but with the specific Coast FIRE math—how much do you need saved NOW so compound growth does the rest."
"Let's add Lean FIRE (≤$40k expenses) and Fat FIRE ($100k+ expenses) with appropriate warnings and lifestyle tips."
"Add a Barista FIRE calculator that factors in part-time income."
Each calculator maintained consistent styling while having its own personality—different color schemes, contextual explanations, and tailored result displays.
The Fun Additions
Halfway through, I asked for three more calculators that I hadn't seen done well elsewhere:
"Add these: 1) Savings Rate calculator that shows how your savings rate impacts years to FIRE, 2) Reverse FIRE that works backwards from a target retirement age, 3) Healthcare Gap calculator for estimating costs between early retirement and Medicare."
Copilot handled the math, the UI, and even added helpful reference tables and scenario comparisons. The Healthcare Gap calculator includes ACA subsidy considerations and strategies like health sharing ministries and Barista FIRE for benefits.
Real-Time Bug Fixes and Refinements
This is where the conversation got interesting. I noticed the Coast FIRE progress card was showing "2160%" instead of "21.5%". A quick:
"The Coast FIRE current progress card is showing an extremely high number—double check those calculations."
Copilot traced through the code and found the issue: the percentage was being multiplied by 100 twice—once in the calculation and again in the ResultCard's percent formatter. Fixed in seconds.
Another issue: the age input would snap to 18 whenever you tried to clear it to type a new value. Annoying UX.
"Entering the retirement age is weird because it sets it to 18 when I try to clear it out. Just don't calculate if invalid but allow entry."
The fix added local state management so users can freely type without the input fighting back, with validation only on blur.
Privacy and Polish
I asked for disclaimers on every page—this isn't financial advice, results are hypothetical, consult a professional. Copilot created a reusable Disclaimer component and added it to all 10 pages in one pass.
The app includes:
No cookies or localStorage - Your financial data never leaves your browser
No analytics - Zero tracking scripts, no Google Analytics
URL-based sharing - Save calculations in the URL, bookmark or share as you choose
Offline-first PWA - Works without internet after first load
Open source - All code available on GitHub for transparency
Quality of Life Features
Throughout the session, I kept adding small enhancements:
"Add a monthly/annual toggle to the contribution and expenses inputs."
"Put a progress bar showing how far along you are toward your FIRE number."
"Add milestone lines at 25%, 50%, 75% on the projection charts."
"Quick preset buttons for common scenarios—conservative, moderate, aggressive."
Each request was implemented cleanly, maintaining the existing code style and patterns.
The Tech Stack
For those interested in the technical details:
Vite + React 18 with TypeScript
Tailwind CSS with custom fire-orange color palette
Recharts for interactive projection graphs
React Router for navigation with URL parameter persistence
Vite PWA Plugin for service worker and offline support
GitHub Pages for hosting
The entire codebase is well-organized:
src/
components/
charts/ # Recharts wrappers
inputs/ # CurrencyInput, PercentageInput, AgeInput
ui/ # Cards, Buttons, ProgressBar, Disclaimer
pages/ # Each calculator as a page component
hooks/ # useCalculatorParams for URL sync
utils/ # All the FIRE math calculations
Key Takeaways
Conversational development works. Instead of writing detailed specs upfront, I could explore ideas naturally. "What if we also showed..." or "Actually, can you change that to..." kept the momentum going.
Copilot handles the boring stuff. Adding disclaimers to 10 pages? Tedious. Watching Copilot do it correctly in one multi-file edit? Satisfying.
Bugs get fixed in context. When something didn't work right, I could describe the symptom in plain English and Copilot would trace through the logic to find the root cause.
The result is production-ready. This isn't a prototype or demo—it's a real app I'm actually using to plan my own financial future.
Play with the parameters, bookmark your scenarios, and let me know what you think. And if you're curious about building your own apps with Copilot agent mode, just start a conversation—you might be surprised how far it takes you.
This blog was written with VS Code and Claude Sonnet 4.5 based on a conversational chat session. I also reviewed and slightly modified the content.
Log in
