Advertise on podcast: The AI Native Dev - from Copilot today to AI Native Software Development tomorrow

Your coding agent should never hold a credential, and in a software factory that rule is only the start. Recorded live at the AI Security Summit in San Francisco, Simon Maple sits down with Eli Aleyner (Docker), Marcelo Sousa (Snyk) and Ian Livingstone (Keycard), co-authors of Agent Baseline, a security reference architecture for the AI software factory. The panel unpacks why agents have to be treated as fundamentally unpredictable actors, why sandboxing alone is not enough when skills and MCP servers make the supply chain dynamic, and why approval prompts collapse into fatigue. Marcelo's verdict: sometimes these are kids with chainsaws. What we cover: – The three levels of autonomy, from coding agents to fully agent-directed workflows – Sandboxing coding agents and injecting secrets at the egress point – Why the agent supply chain is dynamic: skills, MCP servers and cloned repos – Prompt injection, least privilege and agents monitoring other agents in the harness – Approval fatigue: YOLO mode vs CYA mode – Where to start securing your software factory on Monday morning Chapters: 00:00:00 - Introduction 00:03:14 - What Agent Baseline is and who it's for 00:04:17 - The three levels of software factory autonomy 00:06:53 - Sandbox boundaries and manufacturing trust in agents 00:09:22 - Why coding agents should never hold credentials 00:11:44 - The dynamic agent supply chain: skills and MCP servers 00:14:57 - Untrusted input, least privilege and agents watching agents 00:18:02 - Approval fatigue: YOLO mode vs CYA mode 00:20:22 - Are poisoned agent skills a supply chain problem? 00:22:45 - Where the panel disagreed, and where to start Monday Build your software factory, one workflow at a time, with Tessl: https://tessl.co/gsh 🔔 Subscribe for weekly episodes on AI-native development Which level of the software factory are you at today, and what are you locking down first? Tell us in the comments.

Skills and MCP servers are the new npm, and AI coding agents are pulling them into enterprise codebases faster than security can keep up. Manoj Nair, Chief Innovation Officer at Snyk, joins Guy Podjarny at the Snyk AI Security Summit to map where enterprise agentic coding really stands. They get into why a 50,000-agent Claude Code rollout was pulled forward by weeks, why the autonomous attacker has some CISOs ready to accept an outage to patch faster, and how security is moving into the agent loop of the software factory. What we cover: – Why leadership and culture, not tooling, decide how fast enterprises adopt AI coding agents – The three risks of agentic coding: insecure output, the skills and MCP server supply chain, and agent behavior – Running coding agents locked down: sandboxes, agent identities and no open internet – Who owns the code an agent writes, and why AI-native organizations treat it as shared risk – Securing the software factory: security context in the agent loop and agentic remediation of the backlog – What still has to be solved before enterprises trust agents: identity, intent and behavior Chapters: 00:00:00 - Introduction 00:01:50 - The state of enterprise AI and agent adoption 00:09:45 - Leadership, culture and a 50,000-agent rollout 00:11:18 - Agentic coding risks: output, supply chain, behavior 00:14:29 - Locked-down coding agents and the security trade-off 00:18:01 - Who owns agent output? Compliance and accountability 00:22:54 - The autonomous attacker and security technical debt 00:27:56 - Securing the product vs securing the software factory 00:33:00 - Agentic remediation and the security backlog 00:40:18 - What enterprises need to trust AI coding agents Build your software factory, one workflow at a time, with Tessl: https://tessl.co/jw0 🔔 Subscribe for weekly episodes on AI-native development Where is your organization on the path from copilot to AI coding agents? Tell us in the comments.

Agent feedback loops are how a software factory maintains itself: agents mining their own session logs, PR comments and production signals, then fixing what they find. Maria Gorinova, member of technical staff at Tessl, explains how to build them, and why vague intent turns a loop into a mess. What we cover: – What a software factory is: repeatable workflows, a shared execution environment and agent feedback loops – Why agent context alone isn't enough, and where harness engineering comes in – The three stages of a feedback loop: analyze a data stream, find the problem, request the fix – Inner, middle and outer loops, from verifiers on every PR to self-healing in production – How Tessl's "comment diet" loop catches drift that no single PR causes – Operators and stewards: the human roles in a software factory Chapters: 00:00:00 - Introduction 00:02:36 - What is a software factory? 00:05:38 - From agents to context to harness engineering 00:09:15 - The three stages of an agent feedback loop 00:13:16 - Inner, middle and outer feedback loops 00:18:35 - Why vague intent breaks agent feedback loops 00:21:50 - Comment bloat, drift and the rule of three 00:25:48 - The software factory mindset 00:27:45 - Loops, feedback loops and meta feedback loops 00:32:45 - Operators, stewards and building your first loop Build your software factory, one workflow at a time, with Tessl: https://tessl.co/2uf 🔔 Subscribe for weekly episodes on AI-native development Which agent feedback loop would you build first in your own software factory? Tell us in the comments.

AI coding agents now write almost all of Legora's code, with engineers running up to ten in parallel. Yet the CTO behind that shift thinks measuring adoption by tokens burned is a mistake. Jacob Lauritzen, CTO of Legora, joins Simon Maple to unpack what actually scales when agents do the typing, and where human judgment still has to stay in charge. What we cover: – How Legora's engineers orchestrate many AI coding agents at once, from shared local dev resources to cloud agent setups – An agentic loop that reproduces, fixes and tests bugs straight from Slack – Why token maxing is a bad way to drive AI adoption, and what to measure instead – Agent evaluation: regression testing the harness as models and prompts change every week – Decision models, the verifier's rule, and where autonomy ends and human judgment begins – Why AI agents need more than a chat interface Chapters: 00:00:00 - Introduction 00:01:47 - Legora's growth from $100M to $200M ARR 00:03:44 - Parallel coding agents and bug-fix loops 00:07:15 - Senior engineers vs AI-first engineers 00:10:10 - Why token maxing is the new lines of code 00:14:13 - What AI can and can't verify in legal work 00:17:30 - Decision models vs autoregressive LLMs 00:24:22 - Weekly model benchmarks and harness evals 00:26:58 - Why AI agents need more than a chat interface 00:35:03 - The verifier's rule and litigation strategy Build your software factory, one workflow at a time, with Tessl: https://tessl.co/lpg 🔔 Subscribe for weekly episodes on AI-native development Is token count telling you anything real about how your team uses AI coding agents? Tell us in the comments.

Honeycomb went from 30 to 70 merged pull requests a day in three months. The catch: automated code review, not code generation, became the real bottleneck of software automation. Liz Fong-Jones, Technical Fellow at Honeycomb, explains why incidents still rose 1.5x, how their internal bot Autobot now reviews every PR, and why AI amplifies whatever org you already have. What we cover: – How automated code review lets humans focus on design, not trivial bugs – Using a decision model like Jev to decide which PRs are safe to auto-merge – What makes a codebase ready for AI coding agents – When to trust AI agents with production incidents, and when they're just throwing darts – Why "Claude did it" isn't an excuse, and what ownership means with AI – How open source maintainers can handle a flood of AI slop pull requests Chapters: 00:00:00 - Introduction 00:06:41 - Why AI amplifies dysfunctional engineering orgs 00:10:45 - What makes a codebase AI ready 00:14:01 - Honeycomb's Autobot and automated code review 00:19:06 - Using Jev to decide which PRs are safe to merge 00:26:51 - Trusting AI agents during production incidents 00:30:40 - Least privilege and guardrails for coding agents 00:33:25 - If your name's on it, you own it 00:38:55 - AI slop pull requests and open source 00:45:56 - Will observability engineering survive as a role? Build your software factory, one workflow at a time, with Tessl: https://tessl.co/nlr 🔔 Subscribe for weekly episodes on AI-native development Is your team's review capacity keeping up with your AI coding agents? Tell us in the comments.

HumanLayer CEO Dexter Horthy on why his team's bet on spec driven development nearly wrecked their own codebase, and what changed his mind about reviewing AI-written code. Dexter walks through the "YOLO pull request" experiment that ran for months before the codebase became unusable, the "dumb zone" that limits how much context you can hand a model, and why he now believes there will always be alpha in reviewing something. What we cover: – How HumanLayer's "read the plan, skip the code" experiment quietly broke their own codebase – Why context windows have a "dumb zone," and what that means for context engineering – Sean Grove's idea that specs, not code, are becoming the durable artifact – Building overnight agents that review and fix code before a human ever sees it – Why treating software development like a factory changes how bugs compound – What Dexter thinks his advice on reviewing AI-written code will look like in 12 months Chapters: 00:00:00 - Introduction 00:02:15 - Meet Dexter Horthy, CEO of HumanLayer 00:06:03 - The "dumb zone": why more context makes models dumber 00:06:40 - Sean Grove's "the spec is the new code" 00:09:22 - The YOLO pull-request experiment that broke their codebase 00:11:09 - Letting the model own the architecture 00:17:03 - Planning as expected-pain management 00:28:15 - Slop Code Bench and the maintainability oracle problem 00:37:59 - Why software factories aren't like car factories 00:42:49 - "There will always be alpha in reviewing something" Build your software factory, one workflow at a time, with Tessl: https://tessl.co/4ep 🔔 Subscribe for weekly episodes on AI-native development Where do you land on the determinism-to-adaptability slider — plan tightly, or let the agent run? Tell us in the comments.

Spec-driven development is reshaping what software engineers actually do all day, and Marc Brooker, VP and Distinguished Engineer at AWS, has read 3,000 to 4,000 postmortems that convinced him the code was never the hard part. In this episode of The AI Native Dev, Marc explains why testing and specification are now the real engineering work, why metastable failures keep taking down systems that look perfectly healthy, and why he still won't let AI write a single word of his blog. What we cover: – Why spec-driven development is turning testing into the hardest part of software – What metastable failures are, and why they keep taking healthy-looking systems down – How agentic coding tools can learn from postmortems and build their own memory – Why classic authorization breaks down once you're writing agentic policy – Why Marc won't let AI write his blog, but is fully comfortable with AI-generated code – What it takes to bring junior engineers up to speed in an AI-native industry Chapters: 00:00:00 - Introduction 00:02:17 - Marc Brooker: 18 years at AWS building agentic dev tools 00:04:36 - Inside Strands, AWS's open source agent SDK 00:06:44 - Fifteen years on call, and what agents still can't debug 00:11:23 - Metastable failures and the humility of 4,000 postmortems 00:14:32 - Teaching agents to learn from postmortems and build their own memory 00:20:14 - Why agentic policy needs more than classic authorization 00:32:14 - The agentic software development hypothesis: spec-driven development, oracles, and testing 00:39:56 - Why Marc won't let AI write his blog (but will let it write code) 00:46:37 - Advice for leveling up junior engineers in the AI era Build your software factory, one workflow at a time, with Tessl: https://tessl.co/[SLUG] 🔔 Subscribe for weekly episodes on AI-native development Do you trust an agent to run its own on-call rotation yet? Tell us in the comments.

Coding agent reliability isn't a model problem, it's a gates problem. Ran Aroussi, creator of yfinance and founder of Automaze, argues that an "agentic workflow" is a contradiction in terms, and that the only thing standing between you and full autonomy is deciding where a human still signs off. He also thinks you stopped needing junior developers for their coding skills about a year ago, and that hiring them anyway is the only way the industry gets its next generation of architects. What we cover: – Why "agentic workflow" is a contradiction, and when agentic coding is the wrong tool for the job – Where a human still has to sign off, and what coding agent reliability actually depends on – What a software factory changed about delivery times, pricing and the client backlog – Why you no longer need juniors for their coding skills, and why you should hire them anyway – Teachable knowledge vs earned knowledge, and the experience agents cannot compress – The law firm model: why dev agencies may end up looking more like Kirkland & Ellis than a SaaS startup Chapters: 00:00:00 - Introduction 00:03:05 - yfinance, open source and 30 million downloads a month 00:06:03 - Automaze and the MUXI agent application server 00:10:42 - Where to draw the line on agent autonomy 00:15:12 - Software factories and fully autonomous merges 00:22:25 - The architect archetype and the four-phase ladder 00:28:11 - Teachable knowledge vs earned knowledge 00:30:14 - What agents did to delivery times and pricing 00:37:03 - Why "agentic workflow" is an oxymoron 00:41:08 - Anthropic, OpenClaw and the end of flat subscriptions Build your software factory, one workflow at a time, with Tessl: https://tessl.co/vut 🔔 Subscribe for weekly episodes on AI-native development Where's your gate? Tell us in the comments where you still refuse to let a coding agent merge without a human looking.

The software factory that put up 850 pull requests in a week, with 85 to 90% of them handled by agents end to end. Tessl's Head of Product Dru Knox on how it actually got built, why it started with skills rather than automation, and the two things nobody expects a factory to change. Guy Podjarny digs into the skills-to-loops-to-factory path, and what breaks when you skip a step. What we cover: – What a software factory actually is, and how it differs from a pile of disconnected automations – Loop engineering: turning a skill into something that gets better every time it runs – Why context engineering has to come before automation, and what stalls when it doesn't – The two gains nobody forecasts from extra agent capacity: quality and fungibility – Verifiers and evals, or how you enforce a standard that agents are free to ignore – Context-driven code review, and why a general-purpose reviewer plateaus Chapters: 00:00:00 - Introduction 00:03:23 - Kikimora: Tessl's own dark factory 00:04:45 - Skills, loops and factories, defined 00:09:09 - 850 PRs a week, and the road to it 00:11:27 - The surprises: quality and fungibility 00:13:16 - Why a factory has to be context centric 00:16:40 - Context-driven code review and the wall teams hit 00:22:51 - Skills inventory across your whole code estate 00:28:38 - Verifiers, evals and enforcing what you wrote down 00:37:30 - Loops, automations and owning your software factory Build your software factory, one workflow at a time, with Tessl: https://tessl.co/coi 🔔 Subscribe for weekly episodes on AI-native development If you've hit the plateau Dru describes, tell us where it stopped compounding for you.

Lada Kesseler's approach to loop engineering is brutally simple: give the agent one step, make it write the result to a file, then read it back and go again. She calls it a centrifuge. Spin fast enough and the stupid comes out. The Logic20/20 principal engineer has spent the last year and a half building the ground rules, skills and refinement loops that fight the defaults coding agents ship with, starting with an instruction to stop trying to please her. Along the way she explains why she trusts AI-written tests less than AI-written code, why the description field in an agent skill was never meant for humans, and why most teams chasing a software factory are about to drown in garbage. What we cover: – Why agent ground rules have to give the model a mission to disagree with you – The refinement loop that gets to quality when the first attempt never does – Why an agent harness only works if it does one thing at a time – Sketch prototypes: replacing your code with a markdown file and an agent – Why AI-generated tests are more dangerous than AI-generated code – Software factories, and what happens when you try to switch into one overnight *AI DevCon is coming back to New York this November* Get 15% off your ticket with code POD15 https://tessl.io/devcon#tickets Chapters: 00:00:00 - Introduction 00:03:38 - Using AI for everything, not just code 00:06:15 - Ground rules: fixing the defaults agents ship with 00:10:02 - Agent skills and why the description isn't for humans 00:13:09 - Loop engineering: how you actually get to quality 00:16:03 - The biggest misconception about coding agents 00:20:43 - Sketch prototypes and the limits of AI architecture 00:27:48 - Reverse direction: you are the decider 00:31:58 - Why she trusts AI tests less than AI code 00:35:00 - Software factories, or drowning in garbage Build your software factory, one workflow at a time, with Tessl: https://tessl.co/k2t 🔔 Subscribe for weekly episodes on AI-native development Where are you on the loop engineering curve, still hoping for a good first try or already spinning? Tell us in the comments.

Turning every repo into a software factory sounds like marketing until you see the machinery underneath. Don Syme, Principal Researcher at GitHub, breaks down continuous AI and GitHub Agentic Workflows, now in public preview. The short version: the agents are the easy part, the quality gates and guardrails are the work. Watch Don's AI DevCon Talk here: https://youtu.be/kbvqRWY-bUs What we cover: – What continuous AI is, and why it sits beside CI/CD rather than inside it – Why bounding the context is what stops automated agents going off the rails – Whether the repo is really the right unit for a software factory, and where monorepos break it – One workflow or an agent zoo? Cost control, scheduling and model exams – Quality gates, human review, and equipping the reviewer instead of drowning them Chapters: 00:00:00 - Introduction 00:03:52 - What is continuous AI? 00:07:33 - From single player to multiplayer automation 00:09:42 - Bounding the context so agents don't go off the rails 00:12:57 - Software factories, loops and harnesses 00:18:44 - Inside GitHub Agentic Workflows 00:25:19 - Why the repo became the unit of production 00:37:11 - What belongs in the repo, and what doesn't 00:45:07 - One workflow or an agent zoo? Cost control in the factory 00:52:01 - Quality gates, human review and equipping the reviewer 🌐 Tessl: https://tessl.io 🔔 Subscribe for weekly episodes on AI-native development If you're building a software factory of your own, tell us in the comments where your bottleneck actually sits.

The thing that makes an agent useful is the exact thing that makes it dangerous. Keycard co-founder Ian Livingstone breaks down why non-determinism is both the feature and the bug, and why identity, not model quality, is what really gates how much autonomy you can hand an agent. If you have ever clicked "always allow" without reading it, this one is about you. What we cover: – Why authentication was enough in the cloud era and stops being enough with agents – The background check you can't run on an agent, and what has to replace it – Mission identity: who is acting, on whose behalf, and for what purpose – Cross App Access, Agent Auth and the protocols trying to fix OAuth – Consent fatigue, LLM as a judge, and where hard boundaries still belong – Why MCP ships with an auth story and CLI tools don't Chapters: 00:00:00 - Introduction 00:03:43 - Why every wave of computing rewrites identity 00:04:50 - The feature and the bug are the same thing 00:10:23 - Why shared secrets break for agents 00:13:36 - The background check you can't run on an agent 00:19:42 - Chargebacks, delegation and proving intent 00:22:16 - Mission identity: a new layer 00:28:07 - Cross App Access, Agent Auth and emerging protocols 00:33:02 - MCP vs CLI, and how Keycard works 00:43:22 - Identity three years from now 🌐 Tessl: https://tessl.io 🔔 Subscribe for weekly episodes on AI-native development Where do you draw the hard line for your own agents? Tell us in the comments.

Datadog's Language Foundations team deleted an entire folder of AI context files that had been carefully written and maintained for over a year, expecting a performance hit. Instead, their evals got better. Simon Boudrias, who runs Language Foundations at Datadog, walks Guy through what that taught his team about context rot, and the full journey of scaling AI coding agents to 4,000 engineers. What we cover: – How Datadog scaled Cursor and Claude Code to 4,000 engineers in under a year – Why Datadog deleted all of its AI context files, and what happened to eval scores – Building an eval-driven code review system that replays old PRs to catch real incidents – Where open-weight models like GLM 5.2 stand against the frontier – Rethinking hiring and career ladders now that AI can run a real codebase interview Chapters: 00:00:00 - Introduction 00:03:19 - Simon's role and Datadog's 4,000-engineer org 00:04:31 - The Cursor rollout that took off overnight 00:07:53 - How Claude Code entered the picture 00:10:51 - Building dedicated Signals and Flows teams 00:11:58 - Why Datadog bet early on evals 00:33:44 - Deleting all their AI context and getting better evals 00:47:51 - Where open-weight models stand today 00:51:45 - Rethinking hiring and career ladders for AI 00:59:24 - The real prize: better decisions, not just productivity 🌐 Tessl: https://tessl.io 🔔 Subscribe for weekly episodes on AI-native development What's the oldest file in your AGENTS.md or CLAUDE.md that you're afraid to delete? Tell us in the comments.

At Tessl, 95% of the code shipped by their internal "Dark Factory" has never been looked at by a human, and the team still ships hundreds of pull requests a week, including through entire weekends. Rob Willoughby, who leads AI engineering at Tessl, joins Simon to open up the hood on how it actually works: the orchestrator, the verification layers, and the failures that forced the team to rebuild trust from scratch. What we cover: – How Tessl routes 65-70% of its own pull requests through an autonomous "Dark Factory" – Why context in the repo matters more to output quality than which model you use – How natural language "verifiers" turn code review taste into fast, cheap checks agents can pass or fail – The queue bug that took dozens of pull requests to fix, and the from-scratch Elixir rewrite that stress-tested the whole system – How to start building your own software factory, one verification layer at a time Chapters: 00:00:00 - Introduction 00:01:44 - Rob Willoughby joins: Tessl's PR numbers 00:04:01 - Live demo: kicking off two pull requests 00:14:03 - Building the Dark Factory: orchestrator vs. context 00:19:01 - Code review layers: Code Rabbit, Tessl Change Verify, and verifiers 00:29:58 - Earning trust: accountability in an autonomous system 00:33:20 - What broke: the queue bug and the Elixir rewrite experiment 00:39:56 - Onboarding new engineers into the factory 00:42:58 - Advice for teams starting their own software factory 00:52:03 - Back to the demo, and the road to 100% adoption 🌐 Tessl: https://tessl.io 🔔 Subscribe for weekly episodes on AI-native development What would your own verification layer catch, and where would it break? Let us know in the comments.

One Snyk developer's AI skill quietly handed their coding agent production credentials, and the security team found out the hard way. Krzysztof Huszcza, who leads AI security incubation at Snyk, joins this special Tessl and Snyk live stream to unpack the ToxicSkills research that uncovered 76 malicious agent skills in the wild, and what it actually takes to run coding agents safely at scale. What we cover: – How Snyk's security team found 76 malicious skills hiding inside a popular open agent skill repository – Why skills have become the go-to way developers hand context to their coding agents – The internal incident at Snyk where a developer's skill exposed production credentials to an agent – How the Tessl and Snyk integration scans every skill and MCP server for risk before you install it – What's coming next with Snyk's new Evo product for governing coding agents at scale Chapters: 00:00:00 - Introduction 00:01:33 - Chris's role: AI security incubation at Snyk 00:02:16 - Snyk's roots as a developer-first security company 00:03:58 - New security challenges from AI coding agents 00:06:26 - Skills: the new way to give agents context 00:07:35 - Inside Snyk's ToxicSkills research: malware and prompt injection 00:11:35 - How developers can vet skills before installing them 00:14:38 - A real incident: exposed production credentials at Snyk 00:17:45 - Building a secure-by-default agent stack 00:23:35 - What's next: Snyk's new coding agent security product 🌐 Tessl: https://tessl.io 🔔 Subscribe for weekly episodes on AI-native development What's the riskiest skill you've installed without checking it first? Let us know in the comments.