Geoff Mazeroff

AI

I Did The Maths McKinsey Didn’t, and Their “The state of AI in 2025” Report Falls Apart

• McKinsey’s “The State of AI in 2025” report was built around the winners (i.e., those that are making money of AI investments)
• 88% of organizations use AI, but “use” essentially mean regular use of AI in at least one function. That function could be using AI to summarize meeting notes. And regular use could mean daily or even monthly.
• The report shows 32% experimenting, 30% piloting, 31% beginning to scale, 7% fully scaled. This means that 62% of those 88% of organizations are not beginning to scale.
• Costs savings were reports in software engineering, manufacturing, and IT (the production units). Revenue growth was primarily in marketing/sales (but the production units are 5th, 6th, 7th).
• Earn functions are typically marketing/sales and product development (not engineering). AI doesn’t typically show up as revenue for production units.
• Out of 1,933 companies, no company has exceeded 10% adoption at scale for agents. McKinsey frames this as early days and the floor. It’s worth nothing this is only one snapshot. You can’t make inferences with only one data point.
• “[Agents] need defined workflows, predictable decisions, tolerance for errors, and good feedback loops. Now, most functions don’t have this kind of certainty. They involve judgment, context, ambiguity, and compounding consequences. Now, those are the kind of tasks that only humans can do.”
• McKinsey defines benefits as (1) 5%+ of EBIT impact being attributable to AI, and (2) organizations seeing “significant” value from AI use. Only 100 companies fit these criteria, and McKinsey investigated the high performers to see what they did differently. Those companies were more likely to pursue transformative change, more likely to fundamentally redesign workflows, had senior leadership ownership and role modeling, and had defined roadmaps / talent strategies / agile operating models.
• 35 of the high performers spend more than 20% of their digital budget on AI, but 77 companies also spent big; therefore, 112 companies spent big. If you spent more than 20% of your budget on AI, you have about a 30% chance of being a high performer.
• The above is survivorship bias — only analyzing the traits of “survivors” while ignoring the much larger group that followed similar strategies and did not succeed. Correlation doesn’t equal causation. McKinsey isn’t incentivized to look at the other side — i.e., why some companies didn’t make it.

Software Engineering

AWS re:Invent 2025 – Keynote with Dr. Werner Vogels

• This keynote by Amazon’s CTO talks about the Renaissance Developer who has the following qualities:
  • Is curious
  • Thinks in systems
  • Communicates
  • Is an owner
  • Is a polymath
• There’s an implied sixth quality: Has pride in their work.
• The talk includes an interstitial segment from an engineer for Amazon’s new IDE (Kiro). I find it amusing that there’s been so much buzz about spec-driven development (Kiro, GitHub Spec Kit) as if it was novel. ATDD and BDD (and Cucumber) have been out since the early 2010s.
• It was also amusing how the talk surfaces concepts like systems thinking and TPS’ andon cord (which have been around since 1913 and 1948 respectively) almost as if they just figured this out themselves.

We Tried Trunk-Based Development… The Results Were Shocking.

• Trunk-based = commit to main, push to origin, deploy frequently, gather feedback
• This case study involved a realistic team (not utopian) building real stuff under pressure.
• No pair programing, no strict TDD, no PR gates, no rigid review; small increments, feature toggles, validate in production (see below about how this worked)
• They asked questions from the book “Accelerate” such as “Main is often broken and we can’t build”, “Our service has an overall good quality”, and measured change lead time, deployment frequency, change failure rates, and failed deployment recovery time.
• “This success wasn’t magic — it was engineering!”
• (1) Small batches reduce risk. (2) Fast feedback hardens the system. (3) Low transaction costs encourage good behavior. (Anti-patterns: blocking PRs, long-lived branches, formal/heavy QA)
• Low cost of change = changes are small, safe, observable, and recoverable. This also encourages a more collaborative working style.
• Non-blocking reviews were not well-regarded. The reviews need to be valuable (and the team must agree on what value is).
• Small batch size + fast feedback = better outcomes.
• Unit testing and TDD will improve your experience with trunk-based development, but they aren’t prerequisites for it.
• The team succeeded not by adding ceremony but by removing friction.