alphalist.CTO Podcast - For CTOs and Technical Leaders
alphalist.CTO Podcast - For CTOs and Technical Leaders

alphalist.CTO Podcast - For CTOs and Technical Leaders

Tobias Schlottke - alphalist CTO Podcast


Podcast

This podcast features interviews of CTOs and other technical leadership figures and topics range from technology (AI, blockchain, cyber, DevOps, Web Architecture, etc.) to management (e.g. scaling, structuring teams, mentoring, technical recruiting, product etc.). Guests from leading tech companies share their best practices and knowledge. The goal is to support other CTOs on their journey through tech and engineering, inspire and allow a sneak-peek into other successful companies to understand how they think and act. Get awesome insights into the world‘s top tech companies, personalities with this podcast brought to you by Tobias Schlottke.

Alle Folgen

  • #146 AI Found What Nine Years of Security Research Missed with Charles Guillemet // CTO @ Ledger

    Vor 2 Tagen54:24

    Charles Guillemet has spent nine years building Ledger's security organization from scratch — first as the founder of The Donjon, Ledger's in-house offensive security research team, then as CTO overseeing security for a company safeguarding roughly 20% of the world's crypto (per Tobi's intro framing). The conversation centers on one uncomfortable observation: with the latest generation of frontier AI models, Ledger's researchers started finding product vulnerabilities that fifteen dedicated experts hadn't found in nine years of trying. Charles explains why this matters security has always relied on an economic asymmetry between what it costs to attack a system and what an attacker stands to gain, and AI is collapsing that asymmetry by driving the cost of finding a vulnerability toward zero. From there, Tobi and Charles dig into what actually holds up: security-by-design, treating security as a key-management problem, zero trust, and for teams rebuilding their SDLC around AI — Charles's recommendation of small, AI-native pods spending most of their time on "harness engineering" rather than writing code. They also cover why he believes the CISO function should stay organizationally independent, even though it reports to him at Ledger today.

  • #145 "Harness Writing Is Not Hard": Build to Learn, Not to Run with David Soria Parra // Member of Technical Staff @ Anthropic

    03.09.20261:17:11

    Sponsored by Blocks: Save at least 20% on your AWS costs with AI-powered optimization and enterprise discounts. Get your free Cloud Check at https://blocks.cloud/alphalist?utm_source=alphalist&utm_medium=podcast&utm_campaign=blocks-podcast-2026 David Soria Parra co-created the Model Context Protocol (MCP), the standard that now underpins most AI agent integrations, and, before that, spent years as a core contributor to Mercurial and on Meta's internal source control team. He got into programming at 13, writing a PHP guestbook for a gaming website with friends, and hasn't really stopped building since. This conversation goes straight to the thing every CTO is quietly building right now: their own agent harness. David makes a surprisingly blunt case that harness writing itself isn't the hard part: "give it a bunch of tools, a bunch of execution steps, be a little smarter about context selection, and go," and that most companies would be better off configuring a strong existing harness than building their own from scratch. He and Tobi also dig into why the "MCP vs. CLI" debate is largely manufactured, how Meta and Anthropic both run on almost no prescribed process, and how David's own workflow has quietly shifted from local Claude Code sessions to Slack threads over the past six months. CTOs will walk away with a clear-eyed, unhyped view of harness-building from the person who literally created the interoperability standard. Everyone argues about when building your own is worth it, what to check for in a vendor contract, and where to actually put your attention instead of endlessly optimizing your setup. What's covered: - David's path from a PHP guestbook at 13 to Mercurial core contributor to Meta's source control team - Biggest lessons from Meta, and how Anthropic runs on even less internal process - His personal setup: a handful of skills, a few MCP connectors, and why he's a "vanilla" tool user - Why his day-to-day workflow moved from Claude Code sessions into Slack threads with Claude - The real MCP-vs-CLI debate — and why it was never actually a debate - Should every CTO or engineer build their own agent harness? - What's still defensible in software engineering as agents get stronger

  • #144 Writing Code Is No Longer the Job: Dana Lawson on Trusting AI Agents Like Self-Driving Cars // CTO @ Netlify

    13.08.202659:46

    Sponsored by Blocks: Save at least 20% on your AWS costs with AI-powered optimization and enterprise discounts. Get your free Cloud Check at https://blocks.cloud/alphalist?utm_source=alphalist&utm_medium=podcast&utm_campaign=blocks-podcast-2026 Dana Lawson's path into tech started with backup tapes, not a keyboard-in-the-womb origin story. She joined the US Army in the late '90s, automated her way out of manual password resets, and went on to become VP of Product Engineering at GitHub before taking the CTO seat at Netlify. She joins Tobi to make the case that "writing code is no longer the job", an argument from her own New Stack article that lit up Hacker News, and one she doesn't back away from here. The conversation explores why trust in AI agents may eventually become automatic, the same way our trust in cars we can't repair ourselves already has. Dana explains why Netlify is designing for "agent experience" alongside developer experience, and why the engineer's role is shifting from writing every line of code to defining architecture, guardrails, reliability, and safe user experiences. CTOs will walk away with a sharper way to think about where human judgment still matters versus where it's already been commoditized, including the tension between speed and control, whether developers risk becoming the bottleneck, and why the real constraint may be moving from "can we build it?" to "does anyone actually want it?" What's covered: - Dana's path from the US Army to VP of Engineering at GitHub to CTO of Netlify - Why she argues "writing code is no longer the job" and the Hacker News backlash - The self-driving car analogy for trusting AI agents - What "agent experience" means and why Netlify designed for it - Craftsmanship, control, and the shift from writing code to defining guardrails - Whether developers risk becoming the bottleneck in the agentic era - Why the constraint is moving from "can we build it" to "does anyone want it"

  • #143 The Company Brain: How Kombo Runs on a Git Repo and a Cursor Agent — with Aike Hillbrands, Co-Founder & CTO @ Kombo

    30.07.202657:15

    Sponsored by Blocks: Save at least 20% on your AWS costs with AI-powered optimization and enterprise discounts. Get your free Cloud Check at https://blocks.cloud/alphalist?utm_source=alphalist&utm_medium=podcast&utm_campaign=blocks-podcast-2026 Aike Hillbrands co-founded and killed two companies before Kombo, now a Y Combinator-backed HR integration platform with $10M+ ARR and a $25M Series A. Along the way, his team built something almost by accident: a company-wide AI brain made of a GitHub repo, a Cursor agent, and a Slack channel, built in two hours, that replaced how the whole company gets answers. In this episode, Aike explains why files and grep beat MCP tools and vector search for agent reliability, walks through Simon Willison's "lethal trifecta" of AI security risks and how a public Slack channel acts as a guardrail against it, and makes the case for why AI won't commoditize enterprise HR integrations anytime soon, despite that being Kombo's own bet. Topics covered: - How Kombo went from Notion AI to a Git-based company brain - Why files and grep beat MCP tools and vector search for agent reliability - The architecture: per-customer summary files, cross-linked support tickets, BigQuery CLI, Slack integration - Simon Willison's "lethal trifecta" and practical mitigations - Why a public Slack channel works as a security guardrail - The buy-vs-build question for internal AI tooling - Why enterprise HR API integrations resist commoditization by AI

  • #142 Why LLMs Need Their Own Programming Language: From Assembly to AI with Vaibhav Gupta // Co-founder @ BAML

    16.07.20261:04:54

    Sponsored by Blocks: Save at least 20% on your AWS costs with AI-powered optimization and enterprise discounts. Get your free Cloud Check at blocks.cloud/alphalist → https://blocks.cloud/alphalist?utm_source=alphalist&utm_medium=podcast&utm_campaign=blocks-podcast-2026 Vaibhav Gupta built computer vision for the original Microsoft HoloLens, optimized AR at Google, and wrote high-performance assembly at D.E. Shaw, then left it all to start from scratch. After a YC pivot away from a Slack competitor he was told not to build, he landed on something foundational: BAML, a programming language for a world where humans increasingly don't read code. His thesis: every software leap came from a new compute paradigm getting its own language assembly, C, Java, JavaScript and LLMs are the next primitive. They're probabilistic and non-deterministic, which breaks our deterministic tooling. In this episode, Vaibhav explains why "shipping at agent speed" is really a problem of trust and control, why 90% of engineering is plumbing AI will delete, why "English as a programming language" can't work, and why the world has a mathematically infinite appetite for software. Topics covered: - Why LLMs are a new compute primitive and why that justifies a new language - BAML: an embedded, type-safe language for structured LLM outputs across any language - Shipping at agent speed as a problem of trust, locking, and granular control - Why traditional CI/CD breaks in an agent loop - The "data trench" one type system across code, backend, and data - Why 90% of engineering is plumbing, and what changes when AI removes it - Where SaaS pricing and product models are heading

  • #141 AI Pat Works Here Now: Why Agents Must Follow Human Rules with Pat Casey // CTO @ ServiceNow

    02.07.20261:06:23

    Pat Casey was the first person besides founder Fred Luddy to write code at ServiceNow back in 2005, when it was called Glide and lived above a friend's restaurant. Twenty years later, he's CTO of a company where 85% of the Fortune 500 are customers, and until recently ran all of engineering: 10,000 people, 7,000 of them writing code. Almost nobody survives the journey from first engineer to public-company CTO. Pat did. Tobi and Pat dig into how ServiceNow actually works under the hood: a metadata processing engine running 90,000 single-tenant databases and over 25 billion queries an hour, why they bought a 15-person German database company and turned it into RaptorDB, and why tearing apart a 20-year-old monolith is harder than every senior engineer thinks. Then the conversation turns to AI. Pat bought 7,000 Windsurf licenses and measured a real, but unglamorous, 15% productivity bump, with a small subset of engineers going 5–6x while most barely changed. His thesis: AI coding is like playing five chessboards at once, and it's reshuffling the deck on who the top engineers will be. On agents, ServiceNow's answer is disarmingly simple: create a user called "AI Pat," assign it cases, and make it follow the exact same rules as humans because you should not trust an LLM more than you trust a human being. Topics covered: - From Atari 400 and floppy-disk jockey at Aldus to first engineer at ServiceNow - Scaling engineering from a stuffed fish on a monitor to 10,000 people — and the productivity trough at ~100 engineers - Single-tenant architecture: 90,000 databases, 25B+ queries/hour, and the monolith-to-Kubernetes migration - Why ServiceNow bought Swarm64 and built RaptorDB on a Postgres fork - 7,000 Windsurf licenses, Claude Code, and the real numbers on AI coding productivity - "AI Pat": the anthropomorphic model for enterprise agents outcomes, not toolkits - Whether AI kills seat-based SaaS, and why incumbents may have the inside track - Pat's advice to CTOs: this is not a time for excessive caution