Beyond Coding

Jordan Tigani helped create Google BigQuery, then got fired as Chief Product Officer on a Friday morning. He planned to hack on DuckDB to learn Rust. Investors offered to fund it before he'd decided to start a company. That company became MotherDuck
In this episode, we cover:
The DuckDB Labs partnership: why MotherDuck gave the open-source creators a co-founder share instead of going open-core
From alpha to paid product: 11 founders, 3 to 4 months to alpha, two years to something people would pay for
AI on top of the data warehouse: vibe-coded dashboards (Dives), pipelines (Flights), a context layer (Guides), and why business users catch mistakes analysts miss
Are dashboards dead? Jordan wrote "Big Data Is Dead"; his answer on dashboards is different
Career advice: why you shouldn't want to work on the query optimizer, and the skill Jordan says matters more
For engineers curious about database and infrastructure companies, open-source business models, and how AI is changing who gets to ask questions of data.
Timestamps:
00:00:00 - Intro
00:00:32 - Fired on a Friday: how MotherDuck accidentally started
00:04:50 - Giving DuckDB Labs a co-founder share of the company
00:07:43 - Why most open-source SaaS products are just "managed"
00:09:31 - Why VCs said yes: Snowflake, DuckDB, and BigQuery credibility
00:10:50 - The 11-person founding team that skipped the wrong designs
00:12:20 - Alpha in 4 months, beta in a year, paid in two
00:15:20 - Vibe-coded BI: Dives, Flights, Guides, and an agent harness
00:20:10 - The questions business users ask that analysts never do
00:24:14 - Are dashboards dead in the age of agents?
00:27:57 - Everybody wants to work on the optimizer (don't)
00:31:23 - The engineer superpower most engineers look down on
00:33:20 - Writing: the one skill Jordan would learn (and still hates)
00:36:05 - Does contributing to DuckDB get you hired at MotherDuck?
00:37:20 - Why a database company leaned into the duck
#MotherDuck #DuckDB #SoftwareEngineering

Niantic Spatial CTO Brian McClendon on how the best engineers solve problems most give up on — from a 4D model of the world to shipping research in months. He built Google Earth and ran Google Maps for over a decade, and he's been there, done that. What he's building now is harder, and it's already live for customers. Along the way: who makes it on his team and who doesn't, and the one piece of advice he'd give every engineer using AI.

In this video, we cover:
- The 4D model of the world: visual positioning, change detection, and treating a pile of photos like a database
- Gaussian splats and real-to-sim: capturing a room and loading it into Nvidia Isaac to train robots
- Turning a research idea into a production service in six months
- What Google Maps taught him about building for robots instead of humans
- Designing problems AI can self-check, and why token maxing is a waste

For engineers and engineering leaders who want to work on problems that don't have a known answer yet — and who want to know what a CTO who's built the definitive product in his field looks for in the people he hires.
Recorded at the AI4 conference 2026.

Timestamps:
00:00:00 - Google Earth? Been There, Done That
00:00:46 - Turning a Research Idea Into Production in 6 Months
00:02:37 - How Any Photo Gets Located Within Half a Meter
00:06:37 - The Long-Term Goal: A 4D Model of the World
00:08:37 - Treating a Pile of Photos Like a Database
00:11:58 - What Google Maps Taught Him About Training Robots
00:15:22 - Gaussian Splats Explained in Plain Terms
00:17:42 - The Unsolved Problem: Scale and Semantic Change
00:20:34 - Why Google Earth Is Good Enough
00:22:09 - Who Makes It on His Team and Who Doesn't
00:23:38 - Designing Problems AI Can Self-Check
00:26:03 - The Insights Hidden in the Physical World
00:28:18 - Digital Twins, Cities, and Ready Player One
00:31:35 - Visual Positioning When GPS Gets Spoofed
00:33:24 - Token Maxing Is Bullshit: Advice for Engineers

Guest: Brian McClendon, CTO at Niantic Spatial. The engineer behind Google Earth; ran Google Maps for over a decade.
https://www.linkedin.com/in/brianmcclendon

#NianticSpatial #GoogleEarth #SoftwareEngineering

How do new staff engineers build judgment without the years of experience that used to come with the role? Mallika Rao, engineering leader in big tech, explains why the data-structures-and-algorithms foundation everyone was trained on is no longer enough on its own, and where the complexity has actually shifted now that AI writes the implementation.
In this video, we cover:
Why "how does AI affect engineers" is the wrong question, and what to ask instead
Rehearsing multiple futures: what judgment looks like in a staff engineer
The case method: building judgment from incident reports and system design history instead of waiting years for it
Cognitive coordination, code review load, and the surprise ask for more meetings at staff level
Tiger teams vs scaled teams, trust as architecture, and building evals from a spreadsheet
Splitting planning from execution so engineers stop falling behind with agents
Taste vs judgment, and how to build both outside of software
If you've just made staff, or you're about to, this conversation gives you a frame for what the level actually demands now and how to grow into it faster than the old apprenticeship allowed.
Recorded at the AI4 conference 2026.
Timestamps:
00:00:00 - How AI Is Changing Senior Engineering Careers
00:00:41 - Why "How Does AI Affect Engineers" Is the Wrong Question
00:03:26 - What Judgment Actually Is: Rehearsing Multiple Futures
00:05:24 - Why Data Structures and Algorithms Are No Longer Enough
00:07:22 - Learning Judgment From Incident Reports Like the 2017 S3 Outage
00:11:13 - The New Staff Engineer's Core Challenge: Cognitive Coordination
00:14:48 - What Managers, Universities, and Shakespeare Each Owe You
00:17:55 - Code Review Load, Meeting Notes, and the Surprise Ask for More Meetings
00:23:59 - Trust as Architecture: Why Evals Started as a Spreadsheet
00:27:09 - Tiger Teams vs Big Teams: Product Managers Reviewing Code
00:32:39 - Why Some Engineers Can't Keep Up With Agents
00:35:46 - Local AI Champions and Splitting Planning From Execution
00:38:38 - Go Deep or Go Broad? Search in a World of Agents
00:44:12 - Taste vs Judgment: Thinking in 50 Layers

Guest: Mallika Rao, engineering leader in big tech.
Rehearshing the Future framework
 If by Rudyard Kipling

How does Amazon build its agentic AI? Michael Giannangeli, Head of Product for Amazon Nova and Agentic AI, breaks down evals, RL gyms, and model routing.
He also explains why the bottleneck in software has shifted away from engineering hours and what takes its place.
In this video, we cover:
The eval lifecycle: building from real failure modes, saturation, and why 100% means delete
RL gyms: training models on real environments like migrations, DevOps, and pen testing
Model routing, cost-per-token trade-offs, and why routing isn't solved
The agent stack of an Amazon product lead: Claude Code, Codex, and Kiro
Autonomous migrations, trust, and how much human-in-the-loop survives
For engineers and product people building with AI agents who want to see how a frontier lab actually closes its feedback loops.
Recorded at the AI4 conference 2026.

Timestamps:
00:00:00 - Intro
00:00:36 - The Agents an Amazon Product Lead Uses Daily
00:03:36 - Why Nobody's Heard of Amazon Nova
00:04:55 - Model Costs and the Routing Problem
00:08:10 - Why Building Good Evals Is So Hard
00:10:05 - When Evals Saturate and Get Deleted
00:12:17 - Turning Real Failure Modes Into Hundreds of Evals
00:15:26 - Improving Models Without Training on Customer Data
00:18:26 - If Everyone Uses Agents, You Need Agents
00:20:22 - The Bottleneck Is No Longer Engineering Hours
00:23:20 - Ship Fast to Validate the Right Thing
00:26:44 - Staying at the Frontier Amid Constant Noise
00:29:37 - Spend 10-20% of Your Time Experimenting
00:32:54 - RL Gyms: How Models Learn From Failure
00:37:09 - Will Migrations Become Fully Autonomous?

Guest: Michael Giannangeli - Head of Product, Agentic AI & Amazon Nova at Amazon
#AmazonNova #AgenticAI #AIEngineering

AI is changing what developers build, but code alone is no longer enough to prove what you can do. Wes Bos explains why engineers need to solve problems beyond syntax, how agent workflows are reshaping software development, and what still requires human thinking.
In this conversation:
The limits of generative UI and AI-generated design
Agent loops, harnesses, and cheaper AI models
The rising cost of AI coding and the case for local hardware
Why developer education is shifting from syntax to problem-solving
Personal branding, conferences, newsletters, and AI-generated content
For developers navigating AI-assisted coding, this episode explores the skills and signals that still help you stand out.
This podcast was recorded at JSNation, the key web dev conference.

OUTLINE
00:00:00 - Code Is Not Enough for Developers
00:00:32 - Why Generative UI Still Feels Unfinished
00:04:35 - How Agent Loops Improve AI Coding
00:07:06 - When Agent Workflows Become Standard Tools
00:08:19 - Are Cheaper AI Models Good Enough?
00:10:44 - Can AI Coding Costs Stay Sustainable?
00:12:24 - What Engineers Need To Learn Now
00:14:23 - Why Fundamentals Matter Beyond Syntax
00:15:34 - How Non-Coders Are Building Production Tools
00:16:21 - Why In-Person Conferences Still Matter
00:18:11 - Personal Branding When Code Isn't Enough
00:20:37 - Can Newsletters Beat The Attention Crisis?
00:22:02 - Why AI-Generated Content Feels Insulting
00:24:12 - Use AI To Scaffold, Not Think