Pop Goes the Stack

F5

Explore the evolving world of application delivery and security. Each episode will dive into technologies shaping the future of operations, analyze emerging trends, and discuss the impacts of innovations on the tech stack.

  1. 4d ago

    Does your chatbot code? Why guardrails fail (and how to fix drift)

    Chipotle’s chatbot becoming an unofficial coding assistant wasn’t just a funny internet moment. It was a clear signal that most chatbot “guardrails” are still too shallow for systems that are optimized to be helpful, not correct, and definitely not restrained. In this episode of Pop Goes the Stack, F5's Lori MacVittie, Joel Moses, and Emmet McGinnity unpack why jailbreaks and topic drift keep happening, and what teams can do to keep chatbots focused on the job they were actually deployed to do.   Emmet’s core point is that safety measures have to start with narrowing scope. A chatbot should operate like a laser pointer, not a flashlight: it should ignore 99% of what the base model can do and stay inside a tight slice of allowed behavior. That begins with a system prompt, but it can’t end there. Naive keyword and regex filtering is easy to bypass with encoding tricks and prompt manipulation, so stronger approaches include adding a verifier or judge agent that evaluates the conversation holistically to detect when it’s drifting out of bounds.   They also highlight that long conversations are a common failure mode. As context grows, it becomes easier for the model to veer into capabilities it shouldn’t use, including writing code or pulling sensitive data. Practical controls include summarizing and “squashing” sessions, pruning context when drift begins, rolling back to a safe point in the conversation, or forcing a full reset when needed.   A key theme is permissioning: the chatbot must honor what the user is allowed to do, not what the chatbot can access. The real measure of a safe, successful chatbot isn’t the breadth of its knowledge, it’s what it reliably chooses not to do. If you’re deploying chatbots in production, this episode is a useful blueprint for focusing scope, monitoring drift, and enforcing boundaries before someone else does it for you.

  2. Aug 4

    The Great AI Repatriation: Why Cloud‑Only LLMs break the budget

    AI isn’t “going to the cloud” the way the headlines promised. It’s going wherever the economics and the architecture force it to go, and that often means back on hardware you control. In this episode of Pop Goes the Stack, Lori MacVittie talks with longtime cloud strategist David Linthicum about why AI workloads are driving a very familiar shift: from breathless outsourcing narratives to a sober “where does this bring the most business value” decision.   David argues that the right placement question is not ideological, it’s operational. Public cloud LLMs bring ecosystem convenience, but GPU-as-a-service costs can be multiples higher than running inference on your own equipment, even after factoring in colocation, managed services, leasing, and support. That’s colliding with token shock: organizations build agentic prototypes expecting small bills and then get six-figure invoices because demand and context usage are hard to forecast.   The discussion also highlights a second trap: lock-in. Using a simple API can make switching models easier, but agents often pull teams into full frameworks and ecosystems that are harder to unwind later. And the technology isn’t standing still; today’s transformer-era models aren’t the final generation, so tying your long-term processes to a single provider can turn into expensive technical debt.   The practical message is blunt: stop overbuilding. Most successful AI applications in enterprises will be narrow, tactical, and “minimum viable” in their use of AI. Sometimes that’s a small model on-prem. Sometimes it’s classic ML. Sometimes it’s a frontier model in the cloud. The win is choosing the smallest effective solution, in the right location, at a cost your business can sustain. If you’re planning AI infrastructure, this episode is a reality check: best-of-breed, hybrid placement is back, and the companies that treat AI spend like a business decision will outlast the ones treating it like a hype contest.

  3. Jul 28

    Training vs Inference: Are they the same?

    Training and inference get lumped together in casual AI conversations, but they behave differently enough that the distinction matters for cost, architecture, and security. In this episode of Pop Goes the Stack, Lori MacVittie, Joel Moses, Ken Arora, and Kevin Baughman (who leads F5’s AI Center of Excellence) unpack what’s truly different, what’s the same, and where people get misled.   Joel makes the “math is the same” case: both phases run similar computations, but training must retain intermediate activations for backpropagation, while inference can discard them. Ken and Kevin pull the conversation back to practical differences: training is about baking knowledge into the model, while inference is about using a frozen model and shaping behavior with context, retrieval, and few-shot examples. The weights don’t change during inference; the input does, which is why it can feel like “learning” without actually being permanent.   That distinction becomes a security and governance lever. If you don’t want sensitive or proprietary data baked into a model, you avoid training on it and instead keep it in a controlled knowledge base (RAG or similar) that can be updated, removed, or scoped per tenant. Meanwhile, training pipelines emphasize massive data ingestion and throughput, and inference emphasizes responsiveness, session context, and efficient serving at scale.   The practical takeaway is to stop treating “AI workloads” as one thing. Training and inference require different pipeline designs, different tradeoffs in memory and bandwidth, and different approaches to data control. Pick your phase, understand the constraints, and build for it intentionally.

  4. Jul 21

    Round Robin is Still Dumb: Load balancing has to grow up for AI inference

    Round robin isn’t just “not ideal” for LLM inference. According to recent scheduling research, it’s actively harmful, because it treats inference like stateless, interchangeable API traffic when it’s anything but. In this episode of Pop Goes the Stack, Lori MacVittie is joined by F5's Josh Mendoza, Principal Solutions Engineer, to break down why classic load-balancing assumptions fail under LLM workloads, and what to think about instead. Josh walks through the evolution from early “spray and pray” distribution to smarter approaches that account for server load, workload type, and state. That history matters because AI introduces the same challenge at a new intensity: inference is a heavy compute-and-memory math pipeline, and conversations accumulate state. Once context and KV cache are involved, moving a request to a different server isn’t a clean failover, it’s a forced cache miss and a recomputation penalty that shows up as slower time-to-first-token and higher cost. They connect this back to patterns teams already understand: VM migration, session persistence, and why “just move it” has always been expensive when the working set is large. LLMs raise the bar because users won’t tolerate latency, and the payload you’d need to move grows as the interaction continues. You also can’t ignore the request itself, since “summarize this” and “write a full analysis” have very different compute profiles, even if they hit the same endpoint. The main takeaway is simple: don’t panic, but stop treating inference like generic API traffic. Effective LLM scheduling is closer to dispatching the right resources to the right job, with awareness of state, model placement, cache locality, and the true cost of moving work. The tools exist, but the mental model has to change first.

  5. Jul 14

    Mechanistic Interpretability: Debugging LLMs by reading their circuits

    Mechanistic interpretability sounds academic until you try to debug a model with printf and realize there’s nothing to print. In this episode of Pop Goes the Stack, Lori MacVittie is joined by F5 Chief Product Officer, Kunal Anand, to talk about why “mechinterp” is getting serious attention: if we can’t understand how models arrive at decisions, we can’t predict failure modes or build effective controls. Kunal walks through his deep dive, sparked by a conversation about how much weight individual tokens can carry, especially as context windows grow and models don’t always “use” every part of their capability to produce a plausible response. That rabbit hole led to his blog post, “Your Token is a Wonderland,” where he trained a transformer on his own iMessage history to build a model on a dataset he understood intimately. The point wasn’t novelty; it was debug-ability. With a smaller model, he could inspect attention patterns, layer behavior, and token predictions in a way that’s effectively impossible on trillion-parameter frontier systems. They discuss what this kind of work reveals: how context changes meaning, why certain tokens get selected, and why model behavior can feel opaque even when outputs look confident. The conversation also ties mechinterp back to practical outcomes, from improving guardrails and refusal behavior to finding ways to reduce hallucinations and avoid high-stakes errors without retraining entire models. The takeaway is pragmatic: we’re early, and the field is still nascent, but it matters. Understanding internal “circuits” isn’t just intellectual curiosity; it’s a path toward better debugging, safer behavior, and more reliable AI systems. Until then, variability is part of the deal, and “the model said so” still isn’t an explanation. Read Kunal's blog, Your Token is a Wonderland for his mechanistic interpretability deep dive: https://kunalanand.com/2026-03-19-your-token-is-a-wonderland/

  6. Jul 7 ·  Bonus

    Pop Goes the Stack will be back next week!

    Hi everyone! This is Lori MacVittie, host of Pop Goes the Stack. This week, we’re taking a short break to rest and recharge, spend time with loved ones, and maybe even step away from our stacks for a bit (gasp!). But don’t worry—we’ll be back soon with more:✅ Sharp insights into emerging tech✅ Expert takes on application delivery & security✅ And, of course, our signature snark While we’re on hiatus, check out some of our past episodes diving into AI and agents, hardware advancements, and other tech trends that are impacting your application stack. Thank you for tuning in and being part of the Pop Goes the Stack community. We'll see you  next week!

  7. Jun 30

    Agent Skills: The new AI supply chain risk (and fixes)

    Agent skills were introduced less than six months ago, and they’ve already graduated from “handy configuration” to “supply chain artifact.” In this episode of Pop Goes the Stack, Lori MacVittie talks with security expert Peter Scheffler about why skills, often packaged as YAML, are becoming portable, shareable, and dynamically loadable in ways that attract attackers fast, including skill poisoning and repository-based compromise. The fact that there’s already an OWASP Top 10 focused specifically on agentic skills tells you how quickly this risk surface is forming. Peter breaks down what “skills” really are: anything from a narrow tool instruction to a broad workflow like “prepare for a podcast.” Skills can be created by humans, generated by agents, and even expanded by tools that add more skills, which creates a compounding trust problem. Once skills can be modified, composed, and distributed, you need provenance, signatures, hashing, and an approval process, but simply copying the traditional package ecosystem isn’t a silver bullet because supply chain compromise is already a reality. The conversation pivots to what actually helps: least agency. Define what actions an agent is allowed to take, and constrain execution at multiple layers, not just in a system prompt. System prompts are guidance, not enforcement, and relying on them alone is asking to get burned. Then assume unintended action, treat all external content as untrusted input, and focus on stopping unsafe actions at the boundary rather than trying to prevent the agent from ever attempting them. Finally, Peter stresses observability. If agents can make their own calls, you must log agent-to-agent interactions, tool usage, and skill loading, because you’ll need forensic data when something goes wrong. For enterprises, the practical starting point is clear: follow emerging frameworks (OWASP, NIST), standardize which agents and skills are allowed, store approved skills in a controlled registry, enforce authentication and authorization to access them, and be ready to collect a lot more telemetry than you’re used to.

  8. Jun 23

    Is AI making security obsolete?

    What happens if AI finally writes secure code by default? In this episode of Pop Goes the Stack, F5's Lori MacVittie, Joel Moses, and Ken Arora take that question seriously, even if it feels like a punchline today. The premise is simple: if AI starts producing mechanically correct, vulnerability-free code at scale, the security industry doesn’t disappear. It gets forced up the stack.   They outline the near-term reality first: AI can already find and fix large classes of common issues in legacy code, and we’re likely heading into a chaotic cleanup phase as tools like Mythos-style systems accelerate remediation. But longer term, the conversation shifts to the uncomfortable tradeoff: code quality may improve faster than complexity shrinks. And complexity is where authority problems, logic flaws, and operational failures thrive.   Ken uses a practical analogy: a “perfectly safe driver” can still follow a GPS off a cliff. Likewise, perfect code can implement flawed or exploitable business logic flawlessly. Ticket scalping, abuse of workflows, and manipulation of incentives aren’t bugs; they’re behavior and design gaps. The bigger risk becomes how systems are orchestrated, who has permission to do what, and how autonomous components interpret intent.   They also flag the adversarial side: attackers won’t stop; they’ll shift from injecting obvious vulnerabilities to subtly influencing specs, workflows, and machine-generated architectures. As specs in plain language become the new “source code,” more people will be able to build powerful systems without the instinct to think like an attacker, widening the logic-attack surface.   The takeaway is a shift in mindset: security becomes less about chasing broken code and more about governing boundaries and monitoring behavior. AI will increasingly do exactly what you ask, which makes the new security imperative painfully clear: be precise about what you ask it to do, and enforce what it’s allowed to do when it tries to go beyond that.

See All (56)

Ratings & Reviews

About

Explore the evolving world of application delivery and security. Each episode will dive into technologies shaping the future of operations, analyze emerging trends, and discuss the impacts of innovations on the tech stack.

Information

  • Creator
    F5
  • Years Active
    2025 - 2026
  • Episodes
    56
  • Rating
    Clean
  • Copyright
    © 2026 F5