What if network engineers are starting on third base in the AI era? While others are learning how complex systems communicate, how to troubleshoot failures, and how to validate results, network engineers have spent years doing exactly that. In this episode of The Art of Network Engineering, Andy sits down with Remington Loose from St. Jude Children's Research Hospital to explore why those hard-earned skills give network engineers an unexpected advantage in AI. From AI agents and automation to systems thinking and large language models, they discuss how existing networking expertise translates into this new world. But starting on third base doesn't mean you've scored. You still have to learn the tools, experiment, and understand where AI can help, and where human judgment remains essential. CHAPTERS 00:00 Intro 1:03 St Jude Research and AI Trust 5:19 Three AI Topics Outlined 12:32 Agents vs Python Scripts 18:23 Feeding Data to Models 20:34 Agentic Tools and Harnesses 21:57 Context and Memory 29:07 Memory Limits and Sessions 32:14 Systems Thinking for Troubleshooting 37:12 Troubleshooting Skills and MTU 40:34 Guardrails and Skills 49:32 Spending Limits and Hooks 53:10 When AI Ignores Hooks 55:07 Stay the Driver of Why 57:09 Learning by Doing 58:49 Outro and Systems Thinking

What does new technology have to prove before you trust it with your network? Scott Robohn joins Andy Lapteff for a conversation about earning trust, from Ethernet interoperability and vendor bake-offs to network automation and AI. Recorded at Networking Field Day 41, they explore how explicit testing, clear permissions, error handling, and human judgment help engineers decide when a system is ready for more responsibility. Scott revisits a four-vendor evaluation at Bell Atlantic and describes lessons from Lumen’s approach to automating workflows. Andy shares a less comfortable example: software he built with AI that helped him get work done while failures went unnoticed. The conversation also explores AI adoption pressure, the value of critical thinking, and why a read-only troubleshooting workflow can be a useful first step toward building confidence in a new tool. Listen for a practical discussion of how trust develops in network technology, and what AI still needs to earn. For everything AONE: https://artofnetworkengineering.com/ 00:00 Introduction 01:19 Building trust in new systems 02:42 Ethernet interoperability and vendor bake-offs 08:57 Adoption pressure versus production responsibility 15:08 Social media, trust, and agent permissions 20:30 AI as a thought partner 21:34 Critical thinking and reviewing AI output 25:35 Bringing the trust conversation back to networking 28:06 Testing automation workflows and handling exceptions 29:22 Andy's software and silent failures 31:28 Permissions, read-only access, and deliberate testing 33:05 AI-assisted troubleshooting and log analysis 35:41 Wrap-up and community resources CHAPTERS 00:00 Introduction 1:19 Building trust in new systems 2:42 Ethernet interoperability and vendor bake-offs 8:57 Adoption pressure versus production responsibility 15:08 Social media, trust, and agent permissions 20:30 AI as a thought partner 21:34 Critical thinking and reviewing AI output 25:35 Bringing the trust conversation back to networking 28:06 Testing automation workflows and handling exceptions 29:22 Andy's software and silent failures 31:28 Permissions, read-only access, and deliberate testing 33:05 AI-assisted troubleshooting and log analysis 35:41 Wrap-up and community resources

AI can write code, troubleshoot systems, build applications, analyze telemetry, and increasingly take actions on our behalf. So what happens to humans? In this episode of The Art of Network Engineering, Andy sits down with Ryan Booth to explore what becomes more valuable as AI gets better at doing the work humans do. The conversation starts with systems thinking. Everyone from technology leaders to engineers is talking about the need for systems thinkers, but what does that mean? Are network engineers better positioned for it than they realize? Ryan explains why working with increasingly capable AI systems pushed him away from thinking like an individual engineer and toward thinking more like a manager, architect, and orchestrator. Instead of specifying every task, the job increasingly becomes defining outcomes, understanding dependencies, evaluating results, and deciding how much autonomy to give the system. Andy and Ryan discuss human-in-the-loop automation, AI agents, building trust through progressively greater responsibility, the limits of today's systems, and why replacing people may be the wrong way to think about AI. They also get into the fear surrounding AI, the enormous economic incentives driving its development, parallels with previous technology revolutions, and what engineers should do right now to prepare. The takeaway isn't to outrun AI. It's to learn how to use it, understand the systems around it, and become more valuable at the level where judgment, integration, leadership, and context matter. Topics include: • Systems thinking for network engineers • AI agents and autonomous systems • Human-in-the-loop automation • How to build trust in AI systems • AI-assisted network troubleshooting • The changing role of engineers • Learning AI through personal projects • Automation, orchestration, and architecture • AI risk, hype, and uncertainty • What technical professionals should learn next Ryan Booth: https://abstractryan.ai For everything AONE: https://artofnetworkengineering.com/ 00:00 Intro and Ryan Booth 00:36 Intent-Based Networking and Apstra 03:00 Discovering AI Through Art 05:00 The Magic of AI 19:27 Systems Thinking in Networking 23:17 Are Engineers Already Systems Thinkers 28:09 It's Not The Network Mindset 32:08 Orchestration and Building Automations 32:32 Hiring and Integration Skills 41:36 Is AI Thinking or Mimicking 46:06 AI Lying and Manipulation 48:06 Trust in AI Systems 57:18 Internet Boom Parallels 1:01:29 Embracing New Technologies 1:08:09 Ryan's Portfolio abstractryan.ai 1:09:10 Ryan's Personal Art

Everyone says network engineers need to automate. Learn Python. Learn Ansible. Build a source of truth. Learn Git. Test your changes. Stop doing everything manually. There’s just one problem: When? At AutoCon 5 in Munich, Andy Lapteff sits down with Dutch network automation consultants Bart Dorlandt and Bart Smeding for a conversation that starts with Python and eventually lands somewhere much more interesting: time. Automation can turn three hours of work into three minutes. But getting there requires engineers to invest time they often don’t have, or don’t feel permitted to protect. Andy knows that firsthand. At one point in his career, his manager gave him an entire day every week to learn automation. Instead, Andy kept using that day to catch up on operational work. Why? That question opens a much bigger conversation about engineering culture, burnout, professional identity, European and American attitudes toward work, change freezes, technical debt, and the endless tension between keeping today’s network running and building a better way to operate it tomorrow. This isn’t another lecture telling network engineers to “learn Python.” It’s a conversation about why that advice is so much easier to give than to follow, and what has to change if we want network automation to become common. Bart Dorlandt: https://www.linkedin.com/in/bartdorlandt/ Bart Smeding: https://www.linkedin.com/in/bartsmeding/ For everything AONE: https://artofnetworkengineering.com/ 00:00 Intro 00:31 Two Barts, one Munich hotel 03:37 The easy button nobody gets 06:36 Wi-Fi is solved; the LAN is not 08:00 Eight months for the CLI, never eight for Python 12:07 Five maintenance windows a week 24:02 Read-only first 28:31 Everything breaks; you own the failure handling 30:16 The CLI is an API; you are the human regex 32:43 Change freezes and the feeling of safety 37:24 Source of truth, or Excel 39:35 Maybe we are too Dutch 42:10 Two priorities, pick one 43:58 The Tuesday confession 46:30 Unlimited PTO: we can, but we can't 48:00 Does Europe automate more? 50:19 The first script that worked 51:52 Where to find the Barts