Learn AI in Bits

Dan W

AI explained in bits. Each episode takes one concept, like tokens, embeddings, hallucinations, or prompt injection, and explains it in about five minutes. No jargon, no filler. Just the idea, why it matters, and what to remember. If you're curious about AI or already building with it, you'll come away understanding how these systems work. One concept. Five minutes. That's the whole show.

  1. 2d ago

    038 - Why Are People Saying Opus 5.0 Sucks?

    Why are developers saying Claude Opus 5 sucks when Anthropic's benchmarks describe it as one of the strongest models available? This episode examines the gap between benchmark capability and developer experience, focusing on complaints about over-engineering, instruction following, excessive autonomy, observability, and reliability. REFERENCES Anthropic — Introducing Claude Opus 5 https://www.anthropic.com/news/claude-opus-5 Anthropic — Claude / Opus https://www.anthropic.com/claude/opus Anthropic — Newsroom https://www.anthropic.com/news GitHub — Claude Code Issue #87491: Opus 5 treats direct instructions as negotiations https://github.com/anthropics/claude-code/issues/87491 GitHub — Claude Code Issue #85395: Opus 5 regression in following instructions https://github.com/anthropics/claude-code/issues/85395 GitHub — Claude Code Issue #85633: Opus 5 fabricates requirements and acts without permission https://github.com/anthropics/claude-code/issues/85633 GitHub — Claude Code Issue #84933: Long Opus 5 agentic turns with limited visible assistant text https://github.com/anthropics/claude-code/issues/84933 Reddit — Claude has started over-engineering every task https://www.reddit.com/r/ClaudeAI/comments/1vod9ri/claude_has_started_overengineering_every_task/ ExplainX — Claude Opus 5 Over-Engineering: Reddit Reaction https://explainx.ai/blog/opus-5-over-engineering-reddit-reaction-august-2026 Voice narration is AI-generated.

  2. 2d ago

    037 - CLAUDE.md vs Skills vs MCP in Claude Code

    Claude Code gives developers five different places to put an instruction: a CLAUDE.md file, a Skill, an MCP connection, a Hook, or a permission setting. It is easy to shove everything into CLAUDE.md because it is the most familiar option, and just as easy to end up with a bloated file that Claude follows inconsistently. This episode builds a practical map for deciding which mechanism fits a given piece of information or behavior. The episode covers CLAUDE.md as the home for persistent, project-wide guidance, loaded at the user, project, and local scopes plus nested directories, with a .claude/rules folder for instructions scoped to specific file paths. It explains Skills as reusable procedures stored in a SKILL.md file, where the body only loads into context when the Skill is used or judged relevant, making them a better fit for longer workflows than CLAUDE.md. It walks through MCP, or Model Context Protocol, using a Jira ticket example (looking up and updating issue ENG-4521) to separate a project's ticket-handling instructions, a reusable ticket-preparation workflow, and the underlying connection to Jira itself into their three respective layers. Hooks are covered as automated actions that run at defined points in Claude Code's lifecycle, whether as shell commands, HTTP calls, or prompt-based checks, with a TypeScript formatter Hook as the example. Permissions are explained as the layer that is enforced by the client regardless of what Claude decides, unlike CLAUDE.md's guidance-only instructions, and the episode notes when a PreToolUse Hook is the right tool for a hard restriction. A worked example, a project called Shop, shows all five layers working together: a root CLAUDE.md with TypeScript and testing conventions, a path-scoped backend rule, a review-payment-code Skill, MCP connections to Jira and Postgres, a test-running Hook, and permissions blocking production credentials. The episode closes on why the separation is worth maintaining: CLAUDE.md content loads into every session's context whether it is needed or not, and Anthropic recommends keeping each file under roughly two hundred lines, since longer files consume more context and get followed less reliably. Useful for anyone setting up or maintaining a Claude Code project who wants instructions Claude follows, rather than one oversized file competing with itself. Sources & References How Claude remembers your project, Claude Code docs — https://code.claude.com/docs/en/memory Extend Claude with skills, Claude Code docs — https://code.claude.com/docs/en/skills Connect Claude Code to tools via MCP, Claude Code docs — https://code.claude.com/docs/en/mcp Hooks reference, Claude Code docs — https://code.claude.com/docs/en/hooks Claude Code settings, Claude Code docs — https://code.claude.com/docs/en/settings Voice narration is AI-generated.

  3. 3d ago

    036 - What Is a Vertical AI Agent?

    A general AI assistant can summarize a contract in seconds. Getting it to apply a law firm's own playbook, follow jurisdiction-specific rules, and work inside the systems where a case lives is a different problem, and closing that gap is what vertical AI agents are built for. This episode explains what a vertical agent is, how it differs from a general-purpose model like Gemini, Claude, or GPT, and why the specialization increasingly lives in the system wrapped around the model rather than in the model itself. The episode walks through Google's Gemini Enterprise for Legal, announced August 25, 2026, as a detailed example of that architecture: purpose-built skills for contract review, regulatory tracking, and legal research, secure integrations with tools lawyers already use including iManage, NetDocuments, and e-discovery platforms, and permission handling that carries over a firm's existing access controls instead of flattening them. It also covers Google's privacy claim that client data and playbooks are never used to train its foundation models. Three other companies illustrate the same pattern outside law. Ambience Healthcare builds its platform around reconciling medical records and generating specialty-accurate clinical documentation and coding. EvenUp positions itself as the leading AI platform for personal injury law firms, covering case work from intake through trial. Harvey describes its product as legal AI for law firms and corporate legal teams, spanning contract analysis, due diligence, compliance, and litigation. The episode explains why narrow, workflow-specific AI can create measurable business value, since automation pays off most when it's applied to an entire process rather than a single question, while noting that vertical AI products aren't automatically protected from competition, because foundation model providers are building their own industry-specific tools. Listeners will come away understanding that calling a system a vertical agent says nothing about whether its underlying model was trained specifically for that industry; the specialization usually comes from retrieval, instructions, tool connections, permissions, and evaluations layered around a general-purpose model. Useful for anyone trying to understand how AI agents are being deployed inside regulated, workflow-heavy industries like law, healthcare, and finance. Sources & References Introducing Gemini Enterprise for Legal, Google Cloud Blog — https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-for-legal Ambience Healthcare — https://www.ambiencehealthcare.com/ EvenUp Law — https://www.evenuplaw.com/ Harvey — https://www.harvey.ai/ Voice narration is AI-generated.

  4. 3d ago

    035 - Your CLAUDE.md File Is Probably Too Big

    Claude Code's CLAUDE.md file is supposed to make every coding session smarter, but load it up carelessly and it does the opposite: burying the instructions that matter under everything else you've dumped in over time. This episode is a practical walkthrough of how CLAUDE.md actually works and how to keep it from getting out of hand. The episode covers where these files live in Claude Code's memory hierarchy: a personal file in your home directory, a project file shared through source control, a gitignored CLAUDE.local.md for personal preferences, and an organization-wide managed policy file IT can push to every developer's machine, and how they combine. Nested CLAUDE.md files inside subdirectories like backend or backend/payments don't override their parent. Claude Code concatenates every discovered file into context, with broader instructions loaded first and more specific ones last, so contradictory rules across files can leave Claude with competing guidance instead of a clean override. It also draws a distinction most CLAUDE.md advice skips: auto memory, the separate system where Claude Code writes its own notes based on corrections and preferences you give it as you work, versus CLAUDE.md, which only holds what you deliberately write. Mixing the two is one reason files balloon. Other practical guidance covered includes Claude Code's own recommendation to keep each CLAUDE.md under roughly two hundred lines, the .claude/rules folder for instructions scoped to specific file paths, skills for procedures that only need to load when relevant, the @ import syntax and why it doesn't actually shrink context, and the /init and /context commands for generating and auditing memory files. The episode closes on a point worth remembering on its own: CLAUDE.md is guidance the model tries to follow, not an enforced boundary, and anything that has to be blocked regardless of what Claude decides belongs in a hook or a permission setting instead. Useful for anyone running Claude Code day to day who wants their CLAUDE.md file to actually get followed instead of ignored. Sources & References How Claude remembers your project, Claude Code docs — https://code.claude.com/docs/en/memory Voice narration is AI-generated.

  5. 5d ago

    033 - What Skills Should Software Engineers Learn Right Now?

    Software development is changing quickly, but the useful response is not to chase every new AI product. The better question is which capabilities will make a software engineer more valuable in an AI-assisted development environment. The episode focuses on eight areas. 1. AI coding tools. Modern coding agents such as Codex can inspect repositories, plan changes, edit files, run tests, debug problems, and prepare work for review. The important skill is moving beyond autocomplete: developers need to direct, supervise, review, and verify agent-generated work. OpenAI describes Codex as capable of taking engineering work from issues through tested, review-ready code. 2. AI architecture. Engineers do not need to train foundation models to work effectively with AI. They should understand LLMs, context, retrieval and RAG, embeddings, tool calling, agent loops, memory, skills, MCP, permissions, guardrails, and tracing. The goal is being able to explain where an AI application's information comes from, what actions the model can take, and what happens when the system fails. 3. Context engineering. An AI model can perform poorly when it receives the wrong information. Coding-agent context can include the repository, instructions, architecture documentation, requirements, tests, tools, skills, and previous decisions. Martin Fowler's 2026 work on context engineering describes the growing importance of deliberately shaping this environment. Good code structure, documentation, tests, and clear conventions can therefore help both humans and agents. 4. Computer science fundamentals. AI-generated code does not eliminate the need to understand algorithms, data structures, databases, networking, operating systems, concurrency, distributed systems, APIs, security, Git, and testing. The more implementation AI can produce, the more important it becomes to understand the consequences of the implementation. 5. Verification and debugging. When code generation becomes cheaper, the ability to determine whether software is correct becomes more valuable. Engineers need testing, code review, debugging, observability, performance analysis, security testing, and regression testing. AI-generated code can look polished while still making incorrect assumptions or introducing subtle problems. 6. Architecture and systems thinking. Engineers should understand APIs, databases, queues, caches, events, services, cloud infrastructure, identity, observability, data pipelines, and security boundaries. AI systems add components such as model gateways, retrieval systems, vector stores, agent harnesses, memory, tools, and orchestration. The valuable skill is turning a vague requirement into a reliable system and understanding its failure modes. 7. AI security. 8. Requirements and specification. REFERENCES OpenAI — Codex for Software Engineering Teams https://openai.com/business/solutions/engineering/ OpenAI — Codex https://openai.com/codex/ OpenAI — Unrolling the Codex Agent Loop https://openai.com/index/unrolling-the-codex-agent-loop/ OpenAI — Harness Engineering: Leveraging Codex in an Agent-First World https://openai.com/index/harness-engineering/ OpenAI — Running Codex Safely at OpenAI https://openai.com/index/running-codex-safely/ OpenAI — How Agents Are Transforming Work https://openai.com/index/how-agents-are-transforming-work/ Martin Fowler / Thoughtworks — Context Engineering for Coding Agents https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html Anthropic — Engineering and Coding Agent Research https://www.anthropic.com/engineering Authoring Agent Skills: A Software-Engineering Approach https://arxiv.org/abs/2607.25032 Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model https://arxiv.org/abs/2608.13867 Self-Evolving Coding Agents https://arxiv.org/abs/2608.03392 Voice narration is AI-generated.

  6. 5d ago

    032 - Can an AI Agent Trust Another AI Agent?

    As AI agents begin working with other agents, a new security question appears: if one agent delegates work to another, when should it trust the result? The episode separates three concepts that are often confused. Authentication asks, "Who are you?" Authorization asks, "What are you allowed to do?" Trust asks whether the receiving agent should rely on another agent for a particular task or result. The Agent2Agent, or A2A, protocol is one of the major efforts addressing agent-to-agent communication. A2A 1.0 provides a standardized way for independent agents to discover capabilities and collaborate without exposing their internal memory or tools. An Agent Card describes an agent's identity, endpoint, capabilities, skills, and authentication requirements. An Agent Card, however, is a description, not proof of trust. A2A uses established web security mechanisms including HTTPS, OAuth, API keys, OpenID Connect, and mutual TLS. These mechanisms can establish and verify identity and support authorization, while authorization policies can limit access based on identity, requested skills, actions, scopes, and data policies. The episode then makes an important distinction between trusting an agent and trusting its output. An agent can be authenticated and authorized to perform a task while still producing an incorrect conclusion. Important results may therefore need evidence, citations, independent verification, or other checks appropriate to the risk. Delegation creates another challenge. If Agent A asks Agent B to perform work, and Agent B asks Agent C to retrieve data, the permissions given to Agent A should not automatically give every downstream agent unlimited access. This is why least-privilege authorization and controls around delegated actions are important. Provenance is another part of trustworthy multi-agent systems. When several agents contribute to a final result, the system should be able to identify where important information came from, which agent produced it, and how it moved through the workflow. This becomes especially important when agents operate across organizational boundaries. The episode also notes that agent identity is still an emerging area. Current proposals and Internet-Drafts are exploring stronger, verifiable identities and provenance for agents and delegation chains. These are developing standards, not settled industry requirements. The practical approach is to evaluate trust according to the situation. Start with identity, verify authentication, check authorization, consider the sensitivity of the data and action, and verify important results. High-impact actions should receive stronger controls than low-risk information requests. The central idea is that an AI agent should not trust another agent simply because the two can communicate. Trust is built from identity, authentication, authorization, provenance, evidence, and an understanding of the consequences if the other agent is wrong. REFERENCES A2A Protocol — A2A 1.0 Specification https://a2a-protocol.org/latest/specification/ A2A Protocol — Security https://a2a-protocol.org/latest/topics/key-concepts/ Google — A2A Protocol https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ OpenAI — Introducing the Agents SDK https://openai.com/index/new-tools-for-building-agents/ OpenAI — The next evolution of the Agents SDK https://openai.com/index/the-next-evolution-of-the-agents-sdk/ IETF — Agent Identity and Authentication Internet-Draft https://datatracker.ietf.org/doc/draft-rosenberg-agent-auth/ Voice narration is AI-generated.

  7. 5d ago

    031 - How an AI Agent Remembers You

    How can an AI agent remember that you prefer short emails, know which project you're working on, or pick up a task you started yesterday? An agent can create this experience by storing useful information outside the model's immediate context and retrieving the right pieces when they become relevant. The episode explains several layers of memory. Working context contains the current conversation, instructions, tool results, and information needed for the task. Longer-term memory can include procedural information about how the agent should behave, semantic facts such as preferences or project details, and episodic information about previous events. These are useful mental models rather than a universal standard, since different systems implement memory differently. The episode then connects memory to retrieval-augmented generation, or RAG. RAG retrieves external information and places relevant material into the model's context. Memory can use the same general retrieval pattern to bring information from the past into a current task. Retrieval does not have to mean vector search: an agent can also use SQL, documents, APIs, files, or other sources. Context engineering is important because the model's active context is limited. Anthropic's current guidance emphasizes selecting useful information and using just-in-time retrieval rather than loading an entire knowledge base into every request. Memory also has to change over time. If a user once preferred morning meetings and later says afternoons work better, the system needs to update or supersede the older preference. A memory system therefore needs rules for what to keep, what to retrieve, how to handle conflicting information, and when information should be removed. There is also a privacy dimension. If an agent stores information about a person, users need controls over what is remembered, what can be retrieved, and what can be deleted. Memory is therefore part of the agent's data architecture and permissions model. The key idea is that an AI agent does not remember people the way a person does. It stores information outside the model's immediate context, retrieves useful pieces when needed, and places them into the context used for the next decision. Memory, retrieval, and context management work together to create the experience of an agent that knows you over time. REFERENCES Anthropic — Effective context engineering for AI agents https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Anthropic — Effective harnesses for long-running agents https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents OpenAI — Memory and new agent capabilities https://openai.com/index/memory-and-new-agent-capabilities/ OpenAI — New tools for building agents https://openai.com/index/new-tools-for-building-agents/ Voice narration is AI-generated.

About

AI explained in bits. Each episode takes one concept, like tokens, embeddings, hallucinations, or prompt injection, and explains it in about five minutes. No jargon, no filler. Just the idea, why it matters, and what to remember. If you're curious about AI or already building with it, you'll come away understanding how these systems work. One concept. Five minutes. That's the whole show.