# ChrisBoyd.me - Full Content Export > This file contains the full text of the 10 most recent articles for LLM context injection. > Generated: 2026-08-22T20:07:49.693Z Total articles in this export: 10 ================================================================================ ARTICLE: Fable 5 Prompt Guide ================================================================================ URL: https://chrisboyd.me/blog/fable-5-prompt-guide/ Published: 2026-07-18 Tags: Fable 5, LLM prompting, Claude API, Anthropic, AI engineering, model migration Now that Fable 5 is finally available to the public, the first thing worth saying is the least intuitive: most of the prompt you already have is working against you. If you are migrating from Opus 4.8 or an earlier model, your prompts are probably tuned in the wrong direction. Th --- Now that Fable 5 is finally available to the public and [here to stay](https://x.com/claudeai/status/2078302415804379218), the first thing worth saying is the least intuitive: most of the prompt you already have is working against you. If you are migrating from Opus 4.8 or an earlier model, your prompts are probably tuned in the wrong direction. They enumerate steps. They spell out procedure. They wrap the model in guardrails that made sense when the model needed hand-holding to stay on task. Fable 5 does not need most of that, and worse - it is measurably better without it. The prescriptive scaffolding that rescued output quality on older models now suppresses it. The through-line for this entire guide: **with Fable 5, you say less, not more.** State the goal. State the constraints. State the boundaries. Then stop enumerating the steps and let it work. This post covers the API surface that changed, the prompt patterns that actually move the needle, and a before/after you can lift into your own code today. ## The API surface changed. Fail closed on the differences. Before any prompting philosophy, get the parameters right, because several of the knobs you reach for by reflex now return a 400. - **Model ID is `claude-fable-5`.** 1M token context, 128K max output. - **Thinking is always on.** There is no thinking parameter to set. Omit it. An explicit `{"type": "disabled"}` returns a 400, and `budget_tokens` is gone - also a 400. You do not budget thinking anymore; the model decides. - **Depth is controlled by `output_config.effort`:** `low`, `medium`, `high`, `xhigh`, `max`. - **`temperature`, `top_p`, `top_k` are removed.** They 400. You steer with prompting now, not sampling knobs. - **Assistant prefill is not supported.** If you were prefilling to force a JSON shape or a leading token, use structured outputs via `output_config.format` instead. - **The raw chain of thought is never returned.** `display: "summarized"` gives you a readable summary; the default omits it and you get empty thinking text. Here is the shape of a correct request: ```python resp = client.messages.create( model="claude-fable-5", max_tokens=128000, output_config={ "effort": "medium", # sweep this; do not pin to max "display": "summarized", # readable thinking summary, or omit for none # "format": {...} # structured outputs - replaces prefill }, # NO thinking param - always on # NO temperature / top_p / top_k - all 400 fallbacks=[{"model": "claude-opus-4-8"}], # reroute refusals; see below system=SYSTEM, messages=messages, ) ``` The migration reflex is to slap `effort: "max"` on everything and move on. Resist it. The docs are explicit that lower effort still often beats older models running at their ceiling, and higher effort is where turns stretch from seconds into many minutes. **Sweep effort against your own eval before you pin it.** Most production traffic does not need `max`, and the ones that do will tell you in the eval numbers, not in your gut. ## Handle `refusal` before you read content Fable 5 runs safety classifiers on offensive cybersecurity techniques, biology and life sciences content, and - worth flagging for prompt authors - extraction of its own summarized thinking. When one fires, the API returns `stop_reason: "refusal"`. Benign work in those domains can trip it too, so this is not a rare edge case you can defer. The failure mode that bites people: they parse `content` first and crash or emit garbage because they never checked why the turn stopped. **Check `stop_reason` before you read content.** The fix for keeping pipelines alive is the `fallbacks` parameter, which reroutes a declined request to Opus 4.8 server-side. ```python if resp.stop_reason == "refusal": # do NOT read resp.content - route to fallback / log / surface to user handle_refused(resp) else: text = resp.content[0].text ``` On consumer surfaces the fallback ships built in. On the API it is opt-in - a declined request just stops unless you passed `fallbacks`. Set it and forget it beats discovering it in an incident. ## Turns are long. This is a systems problem, not a prompt problem. A single hard request can run many minutes at higher effort, and autonomous runs can extend for hours. This is one of the largest shifts teams hit, and it lands in your infrastructure, not your prompt. Synchronous request/response blocking for minutes will time out at the load balancer, the client, or both. Before you migrate, revisit three things: **client timeouts** (raise them, and stop assuming a fast p95), **streaming** (stream so the connection stays warm and the user sees motion), and **progress UX** (design for a task that is genuinely still working at minute six, not one that has hung). For anything long-horizon, restructure the harness to poll asynchronously or fire on a webhook rather than holding a blocking call open. If your architecture assumes a model reply is a fast function call, that assumption is now a bug. ## The prompt patterns that actually move the needle Everything above is table stakes. This is where output quality is won or lost. Each pattern below comes with the reason it works, because "do this" without the mechanism is how you get cargo-cult prompts that stop working the moment the task shifts. ### 1. Make it verify progress against real tool results, not assumed ones On long runs, models can report a step as done based on what they *intended* to happen rather than what the tool actually returned. Fable 5's own testing found that instructing it to ground progress claims in real tool output nearly eliminated false status reports. The mechanism: a status claim asserted from intention is a guess; a status claim checked against a returned exit code or a re-read file is a verification. You are forcing the second. Put this in the system prompt: ``` Before reporting any step as complete, confirm it against the actual tool result - the command's exit code, the file's contents on re-read, the test runner's output. Do not report success from expected behavior. If you cannot verify a step, say so and say why. ``` This is the single highest-leverage line for anyone running Fable 5 as an agent. False "done" reports are what turn a long autonomous run into a long autonomous run you cannot trust. ### 2. Let it delegate to sub-agents - don't suppress delegation Fable 5 is significantly more dependable at dispatching and sustaining parallel sub-agents, and at managing ongoing communication with long-running ones. Older prompts often contain the opposite instruction - "do this yourself," "do not spawn additional agents" - written to stop weaker models from fanning out and losing the thread. On Fable 5 that instruction leaves capability on the table. If your harness exposes a sub-agent or task-dispatch tool, tell it delegation is available and let it decide the fan-out, asynchronously: ``` You can dispatch parallel sub-agents for independent subtasks. Delegate work that can run concurrently, keep track of what each one is doing, and reconcile their results before you report back. You do not need to do every step in a single thread. ``` The mechanism: delegation is a planning decision, and Fable 5 is now good enough at planning that constraining the plan hurts more than it protects. Remove the old suppression and give it the tool. ### 3. Give it a place to write things down Long runs blow past what fits comfortably in working context. A scratchpad - a file, a memory tool, a notes buffer it can append to and re-read - lets the model externalize state instead of trying to hold the entire task in context and drifting as it fills up. The mechanism is straightforward: durable notes it can re-read are more reliable than context it has to keep resident, and re-reading its own notes is a form of self-verification. ``` You have a working file at ./NOTES.md. Use it to record decisions, open questions, and what you have verified. Re-read it before major steps. Treat it as your source of truth over your own recollection. ``` ### 4. State the boundaries - what NOT to do Because Fable 5 follows instructions tightly and stays in scope, boundaries are cheap and effective. If there are files it must not touch, systems it must not call, or classes of change it must not make, say so directly. This is not the same as enumerating steps - you are not telling it *how* to work, you are telling it where the walls are and then letting it move freely inside them. ``` Constraints: - Do not modify anything under /infra or /deploy. - Do not change public API signatures. - Do not add new third-party dependencies without flagging first. Within those limits, use your judgment on approach. ``` The mechanism: a well-drawn boundary replaces a hundred lines of procedural "do this, then this" and gives the model room to find a better path than the one you would have scripted. ### 5. Give the reason, not just the request State *why* you want something and Fable 5 makes better calls at every fork the instruction did not anticipate. "Return JSON" tells it the format. "Return JSON because it feeds a strict downstream parser that rejects trailing prose" tells it the format *and* that a chatty preamble will break the pipeline - so it suppresses the preamble you never explicitly forbade. The mechanism: the reason lets the model generalize your intent to cases you did not enumerate, which is exactly what you want from a model that is now good at navigating ambiguity. ## Before / after: de-prescribing a prompt Here is a real migration. The "before" is a system prompt written for an older model - heavy on procedure, defensive, step-by-step. The "after" is the same job de-prescribed for Fable 5. **Before (tuned for an older model):** ``` You are a code migration assistant. Follow these steps exactly and in order. Do not skip any step. 1. Open each file in the src/ directory one at a time. 2. For each file, find all uses of the old logging API. 3. Replace each one with the new logging API, one call at a time. 4. Do not attempt more than one file at once. 5. Do not use any other tools or agents. 6. After each file, print the file name and the number of changes. 7. When done, print "MIGRATION COMPLETE". Be careful and go slowly. ``` **After (de-prescribed for Fable 5):** ``` Migrate the codebase from the old logging API to the new one. The goal is that no source file imports or calls the deprecated logger, and the test suite still passes. Why: we are removing the old logging dependency next sprint, so any remaining call site becomes a build break. Constraints: - Do not change log message contents or levels. - Do not touch anything outside src/. Verify each file against the test runner before you consider it done, and confirm the deprecated import is actually gone by re-reading the file. You may work files in parallel. Keep a running list of what you have changed and what still fails, and report that list at the end. ``` What changed and why: the step list is gone because enumerating steps caps the model at your plan. The single-file, no-parallelism, no-tools clamps are gone because they suppress exactly the delegation and concurrency Fable 5 is good at. In their place: the goal, the reason (which lets it handle call sites the steps never mentioned), the boundaries, and grounded verification. Shorter prompt, better result. That is the whole migration in miniature. ## Lines worth quoting - With Fable 5 you say less, not more: state the goal and the constraints, then stop enumerating the steps. - Prompts tuned for older models are usually too prescriptive, and the prescription now costs us output quality. - Don't pin effort to max by reflex - lower effort often beats last generation's ceiling, and we should sweep it against our own eval. - Check `stop_reason: "refusal"` before you read content, and wire the Opus 4.8 fallback so a declined request never breaks the pipeline. - Fable 5 turns run for minutes to hours - that's a timeout, streaming, and progress-UX decision, not a prompt tweak. - Tell it to verify progress against real tool results, not assumed ones - Anthropic's own testing found that nearly eliminated false "done" reports. --- *This post draws on Anthropic's official Fable 5 prompting documentation. For authoritative, current parameters and behavior, treat [platform.claude.com](https://platform.claude.com) as the source of truth.* ================================================================================ ARTICLE: The Week Before the Code ================================================================================ URL: https://chrisboyd.me/blog/the-week-before-the-code/ Published: 2026-06-30 Tags: engineering, AI, agentic coding, planning, PRD, workflow Everyone talks about how fast agentic coding is. Nobody talks about the week of thinking that makes it possible. A practitioner's case for treating the PRD as the highest-leverage hour you'll spend on any project. --- There's a line buried in my [Summer 2026 post](/blog/how-i-code-summer-2026-edition) that I glossed over too quickly: > *On a recent project, I spent an entire week doing nothing but brainstorming and writing PRDs with Claude - before the repo was even initialized.* People keep asking about the 10 PRs and the drive from Jacksonville. Nobody asks about the week before that. That's the part that actually matters. --- ## The automation makes your mistakes faster Agentic coding doesn't make bad decisions good. It executes them at speed. If you start from a vague idea and point agents at it, you get a technically functional mess built at superhuman pace - complete with confident, well-commented code that does exactly the wrong thing. The planning discipline exists specifically to prevent that. Not to slow you down. To make sure the machine is pointed at the right target before you let it run. ## What a PRD actually does in an agentic workflow A PRD in this context isn't a product management artifact. It's a contract between you and the agent. It answers three questions: 1. **What is this thing supposed to do?** Not vaguely. Specifically. Edge cases, constraints, acceptance criteria. 2. **What does it explicitly not do?** Scope control is where agents need the most guardrails. An agent without a clear boundary will helpfully expand scope until you have a feature you didn't ask for. 3. **How will we know when it's done?** The acceptance criteria become the checklist the agent works against. If you can't write them, you're not ready to build. When those questions are answered well, agents perform remarkably. When they're not, you spend the next three days untangling a beautiful mess. ## The letter-grade trick Once you have a draft PRD, ask your model to grade it. Literally: *"Give this PRD a letter grade, with reasoning."* What happens next is useful. The model infers a rubric, assigns a score, and explains the gap. If the grade is a B, ask what would make it an A. Then ask it to make those changes. This isn't a party trick. It's one of the most efficient editing loops I've found. A few iterations of grade → gap → revision will get a mediocre PRD to a tight one faster than any other method I've tried. And the quality gap between a B PRD and an A PRD - in terms of what the agents actually build - is enormous. I use this beyond PRDs now. Contracts. Architecture insights. Home repair estimates. Anywhere you want a fast, honest audit of your own thinking, it works. ## Why a week? A week sounds slow. It isn't. A week of PRD work before a single line of code is written means: - Every feature is scoped, not assumed - Every edge case has been thought through at the planning layer, not discovered at 2am in a broken diff - The agents have a clear job to do on every issue they pick up - You can parallelize confidently because the work isn't tangled The projects where I've skipped or rushed this step have one thing in common: I paid for it later. Not in a dramatic way. In the slow, grinding way where every sprint has a little more untangling than the last one, until the project starts to feel heavy. One week of planning is cheap. Rebuilding something you built wrong is not. ## The `docs/planning` folder Practically, here's the setup: Create a `docs/planning` folder in your repo. Every feature lives here as a markdown PRD before it becomes a GitHub Issue. Work through each one in a Claude Code Plan Mode session - describe what you want, let Claude draft, then iterate together until you have something you'd actually grade an A. When the PRDs are ready, convert them to GitHub Issues using the GitHub CLI. Tell Claude to structure them as independent, non-blocking, agent-sized chunks. That's the last planning decision you make before the automation takes over. From there, the hard thinking is done. The machine does the rest. --- ## The operators who win There's a temptation to look at agentic coding and optimize for the part that feels impressive: the automation, the parallel agents, the PRs that merge while you're on the road. Those are downstream of the planning. The operators who are going to pull ahead aren't the ones running the most agents - they're the ones who've figured out how to think clearly before they run anything. The automation is a multiplier. Multipliers need something worth multiplying. ================================================================================ ARTICLE: How I Code: Summer 2026 Edition ================================================================================ URL: https://chrisboyd.me/blog/how-i-code-summer-2026-edition/ Published: 2026-06-22 Tags: engineering, AI, agentic coding, Claude Code, Codex, workflow Six hours of driving, ten merged PRs, zero humans in the loop. A snapshot of how I actually build software in mid-2026: a monorepo from day one, letter-graded PRDs, hourly agent loops across three dusty Macs, a Design Review gate that keeps ten agents from shipping a ten-personality UI, Neon branches as the safety net, and why I split planning, building, and review across different AI providers. --- This weekend I drove from Jacksonville, FL to Charlotte, NC. Before I started the journey I stopped by the excellent [Southern Grounds](https://www.southerngrounds.com/) for breakfast. While sipping coffee, I worked in a Claude Code session discussing planning items for the day. The items included two major updates: (1) a refactor of the way scheduled events work in an agentic personal project I'm working on, and (2) creating and implementing an MCP server for blogs that lets an agent gain context on posts I've published here. Claude wrote no code, only PRDs. I wrote no code nor PRDs, and only served as editor and guide, which made sipping coffee while doing this work all the more possible. I got on the road, and during the 6-hour drive, had an excellent conversation with my friend and fellow developer [Chuck Imperato](https://mach5atx.com/bio/) about where we are with agentic development, AI, and the whole software development industry. By the time I arrived in Charlotte, 10 PRs had been opened, reviewed, vetted for design consistency, cross-checked for code quality, and merged. No human wrote the implementation code for those PRs. *One note before we go further: this is how I build my own personal projects, on my own machines and my own accounts. It isn't my employer's workflow, policy, or practice, and nothing here touches any company's code, data, or systems.* ## What? This isn't possible. It is. The launch of Claude Code last year ushered in a new era in development. You're no longer the coder - you're the operator. You manage processes around writing the code, but your chosen agentic development partner handles the execution. If you're still coding like it's 2025, or even worse - like it's 2024 - my friend, I have so many great things to show you. But first, you need to strap in, abandon your ego, and accept that your job has changed. You have to zoom out a level. If you're used to being an engineer, you just became a manager. If you're used to being a manager, you just became an architect. If you're used to being an architect, you just became a director. Letting your ego tie you to the way you have written code for most of your career is a surefire way to find yourself obsolete. Now is not the time to be stubborn. Now is the time to be nimble. Nor is it a time to give up, venture off into the woods, and live life as a hermit. To quote [Simon Willison](https://simonwillison.net/2025/Jul/3/table-saws/): > Quitting programming as a career right now because of LLMs would be like quitting carpentry as a career thanks to the invention of the table saw. You are in like Inning 1 of a 1000-inning game, so don't be discouraged. We're just getting warmed up. That pace is exactly why I called this the *Summer 2026 Edition*: how I work today looks nothing like it did in Summer 2025, and I'd bet Summer 2027 makes this version look quaint. Treat it as a snapshot of a fast-moving target, not a permanent playbook. ### You can do this today. Another thing I want to underscore: This is very doable, very affordable, and you can do this right now. ## Step 1: Init ### Monorepo, always. Every project starts as a monorepo. I don't care if it's a weekend toy or a platform play - it goes in a monorepo on day one. The reason is simple: agents work best when the whole world is in one place. One repo for your entire project means one clone, one set of conventions, one CLAUDE.md, and an agent that can reason across your frontend, backend, and infra without you stitching context together from five different repositories. The more you lean on agentic coding, the more a project-based monorepo stops being a preference and becomes a requirement. I've created a [core monorepo you can clone and use to keep things simple](https://github.com/chb704/autorepo) for the purposes of this post, but feel free to shape the structure however you like. ### Infra from day one. Everything I build runs on AWS, so I use CDK to define the infrastructure - in code, in the repo, from the very first commit. Prefer Terraform? Use Terraform. The tool doesn't matter; the rule does: nothing deploys by hand, ever. If it isn't a stack the agent can read, change, and deploy, it doesn't exist. Manual clicks in a console are invisible to your agents - and anything invisible to your agents is a liability waiting to bite you. Then `git init`, push it up to GitHub, and take a break. The foundation is done. ## Step 2: Plan This is the step everything else rests on. Skip it, or phone it in, and your agents will cheerfully build you the wrong thing at superhuman speed. Time spent planning is time you don't spend untangling a mess later - and it's the single highest-leverage hour you'll spend on a project. ### The `/docs/planning` folder The docs/planning folder exists for you to put all of your features, ideas, thoughts, questions, concerns in one place. You will use this folder to brainstorm with Claude Code. Fire up a Claude Code session, and tell Claude you want to use Plan Mode to work on a feature. Describe the feature, everything you want it to accomplish, the constraints, architecture requirements, etc. Tell Claude you want to output a PRD for the feature to a Markdown doc in `docs/planning`. When you're done giving Claude the inputs, let it produce an output: a Markdown-formatted PRD. Plan Mode is extremely valuable in that it lets you think through your decisions, challenges your assumptions, and covers missing pieces that you never thought of in really effective ways. ### Letter grades for PRDs One of my favorite AI tricks is to ask it for a letter grade: "Give this PRD a letter grade, with reasoning." This forces the LLM to infer a scoring rubric, assign a score, and then explain the score, with very little typing involved. Once you have your grade, if it's anything less than an A, ask what we could change about the PRD to make it an A. Then ask Claude to change the PRD in those ways to move it up to an A. You can use this for anything, not just for planning - contracts, life decisions, neighborhoods, where to go for dinner. It works remarkably, and predictably, well. ## Step 3: Implement ### From PRDs to GitHub Issues Once you have a set of PRDs that feels something close to complete, you are ready to move those PRDs over to GitHub Issues. GitHub issues is a clean, simple, beautiful, and FREE way to manage your tasks. Forget JIRA integrations or Linear connections. If your project is a software development project and the only people involved in it are engineers, GitHub Issues is enough. If not, YMMV, but for the purposes of this blog post and our demonstration, GitHub Issues is it. If the PRD is your requirements doc, the GH issue is your implementation plan. Tell Claude to use the GitHub CLI (which you've already installed and authenticated using `gh auth`) to create GitHub Issues for each of the PRDs you've created in `docs/planning`. Tell Claude to structure the issues in ways that are independent, non-blocking, and can allow for parallel development as much as possible. Be sure to tell Claude to make the issues "agent-sized." ### What "agent-sized" means Agent-sized means something that can be implemented within roughly 30 minutes, leaving another 30 minutes for PR reviews and feedback, iterations, and resolution. Depending on your project size, what is "agent-sized" to you might look different: bigger, smaller, more complicated, or less. Experiment to find the best result for your situation. But for the most part, on hourly loops, I've found that agent-sized means 30 minutes or less of straight coding. ### The labels that let Codex find work You'll put this in your AGENTS.md and CLAUDE.md files, but it merits calling out directly: You want your automation-ready issues to carry some labels. I use `lane:cdx-any` and `ready`. This lets your automation script know what to look for and what to ignore. Issues that aren't meant for automation don't have `lane:cdx-any` and are safely ignored. Issues that you're still noodling on don't have the `ready` label and are safely ignored. But every hour, when that Codex automation runs, a GitHub issue with the right labels will get picked up, worked on, and processed. It works when you're awake. It works when you're asleep. In other words: It's magic! The name `autorepo` was inspired by Andrej Karpathy's [autoresearch](https://github.com/karpathy/autoresearch). ## Step 4: Iterate ### Three dusty Macs become a coding cluster Once you get the hang of your Codex automation/GH Issue automated workflow, the first thing you're going to want to do is replicate it on other machines. I have good news: All you need is a Mac. It doesn't have to be a Mac Mini, or a brand new M5 Mac. Just a Mac that uses an M1 or newer CPU. Every dusty Mac you might have sitting in a closet somewhere just became a virtual dev. The CPU doesn't have to be that powerful because most of the processing happens at your LLM provider's point of inference. ### Lanes: parallel tracks of work Each machine in your workflow needs a unique identifier. I went with `CDX-MACHINE` for my naming convention, so the old 2020 M1 Mac Mini sitting in my closet became `CDX-MINI`. The old MacBook Pro that I just retired as my main workhorse became `CDX-MBP`. It doesn't matter what your naming convention is as long as each machine has a unique identifier it can use to claim an issue. ### Claiming an issue without a race Your automation runner script does a few things in order: 1. Identifies the machine the script is running on. 2. Asserts connectivity to github.com. 3. Pulls any open GitHub Issues that have the required labels. 4. Picks an eligible issue and claims it by applying its lane label. 5. Waits one minute, then re-reads the issue to confirm it still owns the claim. That wait-and-re-check step is the cheap insurance against two machines grabbing the same issue at the same moment. If a machine looks back after its minute and finds another lane got there first, it backs off and goes looking for different work. It is not a distributed lock and I won't pretend it is - it's a pragmatic, best-effort claim that has been more than good enough in practice. (More on the edge case in "When it breaks.") ### Opening the PR Once a machine owns an issue, the rest is what you'd hope. It reads the issue and its acceptance criteria, implements the change on a worktree, runs the tests, and opens a PR wired back to the issue and ready for review. From here the change enters the part of the system that actually keeps quality high: Design Review, automated code review, and my own eyes on the PR. Which is exactly where we're headed next. ## Design Review: the quality gate that actually works This is the part I'm most proud of, and the part I don't see many other people doing yet. Every PR that touches the frontend has to pass a Design Review before it can move forward. Not a linter. Not a snapshot test. An actual opinionated review of whether the change looks and feels right - run automatically, in CI, on every single frontend PR. ### A custom Opus prompt plus a Design Vision doc The mechanism is simple. I wrote a [`DESIGN.md`](https://github.com/chb704/autorepo/blob/main/docs/DESIGN.md) that lives in the repo and describes how the product is supposed to look and feel: typography, spacing, color usage, interaction patterns, the tone of the UI, what "good" means for this project specifically. Then a CI workflow fires on any PR that touches frontend files. It hands the diff, plus the Design Vision doc, to a custom Claude Opus prompt and asks one question: does this change honor the vision, or does it drift? Opus reviews the change against the doc and either passes it or blocks it with specific, actionable feedback - the same feedback the agent then picks up and addresses on its next loop. The Design Vision doc is the whole trick. Without it, you're asking an LLM for generic taste. With it, you're asking whether this specific change is consistent with a documented standard you actually care about. That's the difference between "looks fine I guess" and a real gate. ### Why only frontend changes go through it The planning loop - PRDs, issues, lanes, hourly automation - is substrate-agnostic. It doesn't care whether you're shipping an API or a button. But quality gates are where frontend earns its own treatment, because frontend is where AI slop is most visible and most corrosive. Backend drift you can mostly catch with tests. Frontend drift - inconsistent spacing, a one-off color, a component that reinvents a pattern you already have - sails right past tests, because the code is "correct," it just looks wrong. Those are exactly the changes that accumulate into a product that feels like it was assembled by ten different people who never spoke to each other. Which, in a sense, it was. The Design Review is how I keep ten agents from producing a ten-personality UI. It's the single most effective thing I've added. This is your filter against AI slop. ## The async colleague The first time it happened I actually laughed. I'd left a comment on a PR - something like "this works, but pull the magic number into a constant and add a test for the empty case" - closed my laptop, and went to lunch. An hour later I came back and the comment was resolved, the constant was extracted, the test was there, and the agent had already moved on to a new issue. I hadn't done anything. I'd just... mentioned it. ### How PR comments become next-cycle work Here's the loop that makes it work: when a Codex automation runs, before it goes looking for a new issue, it checks for PR feedback on any open PRs in its lane. If it finds comments - from me, or from the automated Claude Code review - it addresses them first, pushes the updates, and only then looks for a new issue to pick up. So PR comments aren't something I have to babysit. They're just the next cycle's work. I drop feedback whenever I happen to look - between meetings, waiting on coffee, on my phone using the Github app - and it gets handled on the next hourly tick without me holding the thread open in my head. ### Codex as a remote collaborator who never sleeps The mental model that finally clicked: Codex is a remote colleague in a very different timezone who picks up my comments the moment I stop typing. I don't wait on them. They don't wait on me. I leave async feedback, they act on it async, and the work moves forward whether I'm at the keyboard or asleep. Three machines running this means I effectively have three of those colleagues. None of them get tired, none of them get bored of the boring tickets, and none of them take it personally when I send a change back for the third time. ### Why Codex Fair question, given all my talk of swapping providers: why is Codex the one running the lanes? Because the automation lane is the highest-volume, most token-hungry, always-on seat in the whole operation - and that's exactly where Codex earns its keep. Three machines firing every hour, grinding through implementation work around the clock, burns an absurd number of tokens. In my experience OpenAI is simply more affordable and more generous with token usage on coding workloads, and when you're running nonstop that stops being an academic question. It's the difference between "this is sustainable" and a monthly bill that makes you quietly turn the whole thing off. It's also just a better workhorse for unattended work. Codex's automations are more predictable run-to-run: it claims the job, does the thing, and opens the PR without babysitting. When nobody's watching, predictable beats clever - and that reliability is worth as much to me as the price. There's a quality angle to this too. GPT-5.5 at xhigh has held a remarkably consistent code-quality bar since the day it shipped - I get roughly the same caliber of work at 2pm on a Tuesday as I do at 2am on a Sunday. Claude Code, as much as I love it, has been streakier for me: the quality can swing depending on the hour and the day. For a model writing code unattended, around the clock, that consistency is the whole ballgame. I'd rather run a workhorse that's reliably an A- than one that's an A+ on a good day and a C when the servers are slammed. So Codex draws the implementation lane, and Claude is where I lean for planning, design, and review. That split isn't an accident, and I'll get to why a little further down. ### A new rhythm for code review This rewires how review feels. It stops being a blocking, synchronous chore where someone sits waiting on you, and becomes a stream you dip into on your own schedule. I review PRs throughout the day as I can, approving or commenting alongside the automated Claude Code review that runs on every PR. My comments and the bot's comments sit side by side, and the agent treats both as work to do. The result is a review cadence that fits around a life instead of one that demands you park in a chair and clear a queue. I review when I want to. The work moves when I don't. ## End of day: a code review with Claude The day doesn't end when the last PR merges. It ends with a conversation. Every evening I open a fresh Claude Code session and say some version of: "Claude, summarize all changes made today, give each major change a letter grade with reasoning, and give me your thoughts on the direction we took today." What comes back is part standup, part retro, part sanity check. A clear summary of everything that shipped, a graded read on the quality of each significant change, and an honest opinion on whether the day's direction made sense or whether I'm quietly painting myself into a corner. Chatting with Claude about your code at the end of the day - the way you would with a trusted colleague - provides a level of insight and calm that's genuinely hard to overstate. It's the moment the operator zooms back in, just briefly, to confirm the machine is still pointed in the right direction. Then I close the laptop, and the agents keep going while I'm relaxing on the couch. ## When it breaks It is not all magic and merged PRs. If I let you believe nothing ever goes wrong, I'd be lying to you - and you'd hate me the first time you tried this and it blew up. ### Failure modes I've actually hit The real ones, in roughly the order they've bitten me: - **Runaway loops.** An agent gets stuck and keeps trying the same broken approach, burning tokens and producing an ever-uglier diff. The hourly cadence is itself a circuit breaker here - a bad run is bounded by the clock - but you will see it. - **Hallucinated APIs.** The agent confidently calls a method that doesn't exist, or a version of a library's API from two majors ago. Tests catch most of this. Not all of it. - **Breaking refactors.** A change that's locally correct and globally wrong - it does exactly what the issue asked and quietly breaks three things the issue didn't mention. - **Dependency landmines.** An agent helpfully bumps or adds a dependency, and now you've got a transitive surprise you didn't sign up for. None of these are dealbreakers. All of them are reasons you need strong CI guardrails, not vibes. ### Neon as the safety net I cannot recommend [Neon](https://neon.tech) enough. Neon is what saves you when an agent goes sideways. The killer feature is instant database branching: every agent gets its own prod-data clone to test against, spun up in seconds, with zero performance impact on the real database. The agent can run migrations, mangle data, do whatever it needs - on a throwaway branch that never touches production. When it opens a PR, the change has already been exercised against realistic data. And when it inevitably gets something wrong, the blast radius is a branch that gets deleted as soon as it's not needed anymore, not a prod incident I have to explain. One caveat I'll name because it matters: those clones inherit production data, which means they inherit production PII. If you do this, mask or scope the sensitive columns on the agent-facing branches. Don't hand ten automated agents an unredacted copy of your users' data and call it a safety net. And the same boundary applies to the whole setup: this is built for personal projects on infrastructure I own. Don't point any of it at an employer's code or production data unless your company has explicitly approved the tools, the data flow, and the runner isolation. ### Guardrails I rely on (branch protection, label trust, runner isolation) The whole system is only as safe as the rails around it. Mine: - **Branch protection.** `main` requires passing status checks and a review before anything merges. The agents can open PRs all day; they cannot merge to main on their own authority. This single setting is the difference between "automated development" and "automated disaster." Turn it on before you turn on anything else. - **Label trust.** Automation only touches issues carrying `lane:cdx-any` and `ready`. So the real question is: who can apply those labels? On a private repo with just me, that's a non-issue. The moment the repo opens up, that label becomes a code-execution trigger - anyone who can apply it can get your CI to run their code. Treat the label as a trust boundary, not a convenience. - **Runner isolation.** I run self-hosted GitHub runners in AWS, and self-hosted runners executing PR code have well-documented escape paths into the account that hosts them. Mine are ephemeral - a fresh environment per job, torn down after - running in an isolated account with tightly scoped IAM and pulling from a known-good image. If you copy nothing else from this post, do not point a long-lived self-hosted runner with broad AWS permissions at code an agent wrote. That's how you get popped. And one honest caveat on the lane mechanics: the claim/wait/re-check dance from earlier is best-effort, not provably race-free. It's rare, but two machines can still double-claim the same issue inside the same minute. It hasn't caused me real pain, but I'm not going to pretend it's airtight. ## Cross-provider review: why I split brains Here's an opinion I hold strongly: don't let one model do everything. It genuinely doesn't matter whether you use Claude Code or Codex for any given job - swap them, do the exact opposite of what I do, use one for both. That part's your call. But I've landed on a deliberate split, and it isn't arbitrary: one provider plans, a different provider implements, and a different provider again reviews. The reasoning is simple, and a little endearingly familiar. A model reviewing its own work carries the same blind spots it had when it wrote the thing. Hand the same code to a different provider and it picks up on things the original author sailed right past - the same way a second set of human eyes catches what you've gone face-blind to. Cross-provider review isn't about one model being smarter than another. It's about not grading your own homework. So I split brains on purpose. Plan with one, build with another, review with a third. The disagreements between them are where the best catches come from. ## What I'd tell a skeptic Here's the honest part. We are still not in a place where you can type "build an Uber clone, make no mistakes" and get back something that works and is actually great. Left to their own devices, these tools still make horrible architectural decisions. In the summer of 2026, the agent is a brilliant builder and a terrible architect. That is exactly why the planning matters as much as it does. On a recent project, I spent an entire week doing nothing but brainstorming and writing PRDs with Claude - before the repo was even initialized. Not a single line of code. Just thinking, out loud and on paper, until the shape of the thing was right. The automation only looks like magic because all the hard thinking happened first. And yes, I can hear the objection: this is one person with three Macs and a greenfield repo - it'd never survive a real team or a million-line legacy codebase. Fair. The exact mechanics are tuned for a solo operator moving fast. But the principles scale further than the setup does: plan before you build, gate quality in CI, never let a model grade its own work, keep a human as the architect. Those hold whether you're one person or a hundred - the blast radius just gets bigger and the guardrails get stricter. The teams that figure out how to industrialize this are going to run circles around the ones still debating whether it's real. But you already knew that. Because you've embraced your new job. You're not the coder anymore - you've zoomed out. You're the architect. The operator. The director. ================================================================================ ARTICLE: The 24-Hour Sprint ================================================================================ URL: https://chrisboyd.me/blog/the-24-hour-sprint/ Published: 2026-06-15 Tags: engineering, AI, agentic coding, SDLC, software delivery TL;DR: Agentic coding is compressing the dev cycle into 24 hours. Here's how it looks from the inside. --- **TL;DR: Agentic coding is compressing the dev cycle into 24 hours. Here's how it looks from the inside.** --- I've been running engineering orgs long enough to remember when "continuous delivery" was the radical idea. Ship daily instead of quarterly. Automate the build. Trust the pipeline. It felt fast at the time. Now I'm watching the entire sprint cycle compress into 24 hours, and honestly, the teams pulling this off look nothing like the ones I managed five years ago. I'm one of them. I'm running 24/7 automation loops on my own projects right now - agents that work through the night, open pull requests, and have them queued for my review by morning. It's not a demo environment. It's how I'm actually shipping. The first time I sat down with a fresh batch of agent-generated PRs over coffee, the shift felt less like a productivity upgrade and more like a change in what my job actually is. ## The shift nobody's CI/CD pipeline prepared you for Here's the dirty secret about our industry's automation story so far: CI/CD only ever touched about 30% of the actual effort in software delivery. Testing, building, deploying - yes, we automated that. But everything upstream - gathering requirements, designing solutions, writing the code itself - stayed manual. Humans in meetings. Humans in Jira. Humans staring at IDEs. Agentic coding is going after the other 70%. [McKinsey's recent piece on rewiring software delivery for the agentic era](https://www.mckinsey.com/capabilities/technology/our-insights/rewiring-software-delivery-for-the-agentic-era) describes a shift toward a daily sprint model - humans and agents operating in a continuous 24-hour cycle that compresses what used to be two-week sprints. The productivity gains are real, but they come with a caveat worth taking seriously: this only works in organizations that already have architectural discipline, standardized workflows, and clear product vision. It's not what happens when you hand Copilot to a team with a legacy monolith and no documentation. But the directionality is real, and the teams achieving it are operating in a fundamentally different rhythm. ## What the 24-hour cycle actually looks like The model that's emerging is this: humans review, prioritize, and steer during the day. Agents execute overnight. During working hours, engineers are reading pull requests generated by agents, validating architectural decisions, refining requirements, and setting the next batch of work in motion. When the team goes home, agents pick up the queue - writing code, running tests, generating documentation, flagging blockers for morning review. It's not a 2-week sprint anymore. It's a daily cycle. Ship, review, steer, repeat. This sounds elegant on a slide. In practice, it only works if the agents have enough context to make reasonable decisions autonomously. Which brings me to the part most people skip over. ## Knowledge graphs as institutional memory The biggest unlock isn't the AI model itself - it's the context layer around it. Agents can't ask the senior engineer in Slack why that service is architected the way it is. They can't absorb tribal knowledge from a whiteboard session. They need machine-readable artifacts: architecture decision records, dependency maps, API contracts, coding standards - all structured, all current, all queryable. The organizations making this work are building knowledge graphs as their institutional memory. Not wikis that go stale. Not Confluence pages nobody updates. Actual graph-structured representations of how their systems work, what decisions were made and why, and what constraints apply. McKinsey describes these as an AI memory layer across the SDLC - connecting customer feedback, architecture decisions, design documents, tickets, GitHub activity, and incident reports into a semantically linked system that agents can actually reason over. Questions that once required weeks of SME interviews can be answered in minutes. Every decision becomes traceable. This becomes the agent's context window - the difference between an AI that generates plausible code and one that generates *correct* code for your specific system. If you don't have this, you don't have agentic coding. You have an expensive autocomplete that creates tech debt faster than your team can review it. ## The real prerequisite: architectural discipline Let me be blunt about something. This doesn't work if your codebase is a mess. Agentic pipelines require standardized workflows, clean interfaces, well-documented contracts, and modular architectures where agents can operate on bounded contexts without cascading side effects. McKinsey is explicit about this: the path from requirements to code must follow a standard structure so agents can reliably interpret inputs and produce predictable outputs. Requirements, standards, architectural specs, and user stories living across disconnected documents and tools isn't a minor inconvenience - it's where friction accumulates and value plateaus. The agentic model removes that friction by structuring artifacts for machine-to-machine handoffs. When it works, the pipeline runs end to end in hours, with humans intervening only at defined review gates. The teams seeing the biggest gains already had this discipline. The AI amplified their existing rigor. It didn't create it. If your system is a tangle of implicit dependencies, undocumented conventions, and "just ask Dave" institutional knowledge, the first step isn't adopting agentic tooling. It's doing the architectural work that makes agentic tooling possible. ## The role shift that's already happening Team structures are changing. McKinsey describes larger teams of 8-12 FTEs giving way to smaller pods of highly skilled professionals supervising agent-driven execution - compressed timelines, lower costs, or increased capacity depending on how the freed capacity gets redeployed. This isn't "engineers replaced by AI." It's engineers operating at a higher level of abstraction. Less time writing implementation code. More time on system design, constraint definition, quality review, and strategic decisions about what to build and why. The skillset that matters is shifting: architectural thinking, clear specification writing, the ability to review AI-generated code critically, and the judgment to know when the agent got it wrong. Production debugging doesn't go away. But the ratio of thinking to typing changes dramatically. ## Where this lands Some teams could flip to the 24-hour sprint tomorrow. Not as a moonshot - as a practical decision. If your architecture is clean, your context layer is machine-readable, and you have engineers who can steer rather than just produce, the tooling is ready. The gap is organizational will, not technical capability. But that combination is rarer than the hype suggests. Most engineering leaders need to be honest about a few questions: 1. Do you have a clear product vision your team can use to assess agent-generated requirements for quality and alignment? 2. Is your technology environment standard and consistent enough for solutions to scale and components to be reused? 3. Does the path from requirements to code follow a standard structure agents can reliably interpret? 4. Are your core stakeholders engaged across the full value stream - or are you creating misalignment and rework at every handoff? If the answer to most of those is no, the productivity gains everyone's talking about aren't available to you yet. The good news is that the work to get there - cleaner architecture, better documentation, standardized workflows - makes your team better regardless of whether an agent ever touches the code. Start there. ================================================================================ ARTICLE: There Are Three Kinds of "Similar" in Food. Most Recipes Only Know One. ================================================================================ URL: https://chrisboyd.me/blog/there-are-three-kinds-of-similar-in-food-most-recipes-only-know-one/ Published: 2026-05-28 Tags: food, AI, research, cooking Researchers built a map of ingredients that answers three different versions of "what's similar" - and the results are weirder and more useful than any recipe site has ever managed. --- When a recipe site tells you "if you like basil, try parsley," it's not wrong. But it's answering a much smaller question than it thinks it is. Basil and parsley are similar the way coworkers are similar - they show up in the same places, they run in the same circles, they're comfortable on the same plate. That's useful. It's also only one definition of similar. A group of researchers recently built something more interesting: a map of ingredients that can answer three different versions of that question, depending on what you actually want to know. ## The Three Maps The paper is called [*Epicure*](https://arxiv.org/abs/2605.22391). The researchers trained three separate ingredient models on 4 million recipes, each one tuned to emphasize a different signal: - **Cooc** - "What do people cook this with?" Pure recipe-context. Garlic lives next to olive oil, onion, and chicken because that's where it actually shows up on the plate. - **Chem** - "What does this taste like, molecularly?" Garlic ends up near asafoetida and leek - ingredients you might never combine in practice, but that share the same sulfur-heavy chemical signature. - **Core** - A hybrid. Recipe context plus chemistry, blended together. Same training process, same model architecture. Just a different definition of "near." The result is that you can ask the system the same question - *what's similar to garlic?* - and get genuinely different, genuinely useful answers depending on which lens you look through. ## Why That's Actually Useful Think about the last time you needed to substitute an ingredient. If you're out of soy sauce, the recipe-context model helps: sesame oil, oyster sauce, and miso are in that neighborhood. They'll hold the dish together because chefs have always used them together. But if you're trying to understand *why* a dish tastes the way it does - or if you want to recreate a flavor profile with completely different ingredients - the chemistry model is the more interesting tool. Miso maps to savory, protein-rich, fermented things. That's a different list than what you'd find in a Japanese cookbook index. Neither answer is wrong. They're answering different questions. ## The Flavor Compass The part of the paper I find genuinely surprising is the geography that emerges without anyone teaching it. Run the models and plot the results, and you get visible clusters - East Asian pantry, South Asian spice blends, Mexican and Latin American staples, Mediterranean savory ingredients - appearing on their own. Nobody labeled them. The models found them by learning which ingredients travel together. The researchers call these "culinary modes." There are roughly 150 to 200 of them, depending on which model you use. Some are intuitive. Some are strange in a way that makes you want to cook something immediately. ## The Direction Trick The most playful part of the paper is something called direction arithmetic. You start with an ingredient and point it toward a cuisine. Then you dial a number - θ, from 0 to 60 degrees - that controls how far you travel. At 0: you're still near the original ingredient. At 60: you've arrived in the target cuisine's pantry. Anywhere in between: you're in hybrid territory. Rice pointed toward South Asia retrieves curry leaf, dal, fenugreek, Kashmiri chili as θ increases. Corn pointed toward Latin America surfaces tomatillo, queso fresco, salsa, corn tortilla. It's less a recommendation engine and more a flavor compass - the kind of tool that could help a cook understand what makes a cuisine coherent from the inside. ## What It Can't Do (Yet) The recipe data skews heavily English and Chinese. Smaller culinary traditions - West African, Central Asian, indigenous American - have thinner coverage, which means the map gets less reliable in those regions. The chemical data only covers about a third of the full ingredient list. And the researchers haven't released the trained models yet, so you can't go use this today. But the framing matters independent of the implementation. Food isn't one-dimensional. "Similar" isn't one thing. The tools we build for cooks - recipe search, substitution suggestions, pairing recommendations - mostly pretend otherwise. This paper doesn't. ================================================================================ ARTICLE: What a Papal Encyclical Just Added to Your AI Governance Checklist ================================================================================ URL: https://chrisboyd.me/blog/magnifica-humanitas-ai-governance/ Published: 2026-05-26 Tags: AI, AI Governance, Enterprise AI, Ethics, Leadership Pope Leo XIV's first encyclical, Magnifica Humanitas, isn't just theology - it's a portable moral framework that will land in EU AI Act commentary, customer RFPs, and bank ethics committees within a quarter. Here's how its four questions map onto the AI governance work enterprise teams are already doing. --- When *Magnifica Humanitas* dropped yesterday, I read it the way I imagine most Catholics read a new encyclical - as a member of the Church first, then as someone who has to ship AI systems on Monday. Those two readings landed differently. The theological one was expected. The operational one surprised me. Pope Leo XIV released the document on May 25, 2026 - the 135th anniversary of *Rerum Novarum*, Leo XIII's 1891 encyclical on labor and capital during the industrial revolution. That date wasn't administrative coincidence. Leo XIV is making the same kind of intervention for the AI era that Leo XIII made for the factory era: not a technical blueprint, but a moral vocabulary for navigating a transformation that is already happening whether or not the Church has words for it. I'm going to give you the operational read. But I want to be honest that I'm not writing this as a neutral analyst. I received this document as a Catholic. That context matters for why I think the vocabulary in it is worth taking seriously - not because the theology compels you, but because 1.4 billion people are now oriented around it. ## This is a compliance artifact Most AI ethics frameworks address outcomes: bias, harm, displacement, autonomous weapons. *Magnifica Humanitas* goes one level deeper. The encyclical's core claim is that the bigger risk isn't what AI does to outputs - it's what AI tempts users to believe about themselves. When "efficiency becomes the ultimate measure of value, human beings are tempted to see themselves as a project to be optimized rather than as persons called to relationship and communion" (MH 112). That framing is harder to put in a JIRA ticket. But it's also harder to argue with - which is exactly why it will show up in board-level conversations before your quarterly review template does. Within a quarter, expect this language in RFPs from Catholic-affiliated hospitals, in EU AI Act commentary, in bank ethics committee minutes. The institutions that move first on shared moral vocabulary set the terms of the conversation. The ones that don't will be retrofitting their answers. ## Why framework-shaped beats policy-shaped NIST gives you controls. The EU AI Act gives you obligations. *Magnifica Humanitas* gives you a vocabulary that survives translation across regulatory regimes. The encyclical explicitly avoids "technical policy blueprints" - and that's a feature. Portable moral frameworks outlast specific regulatory cycles. This one has institutional backing that no standards body can match. ## The four questions (MH 237–240) The operational core of the encyclical is four questions for evaluating AI-assisted technology. Here they are, with engineering translations: **Truth (MH 237):** *Does it help me remain faithful to the truth, despite the most appealing content?* Retrieval grounding, citation surfacing, hallucination eval suites, refusal calibration. The clause "despite the most appealing content" is the real teeth - it's a direct indictment of engagement-optimized AI. If your system surfaces the most compelling answer rather than the most accurate one, you have a Truth problem in Leo's vocabulary. **Education (MH 238):** *Does it help educate me and allow me to educate others?* Explainability surfaces, chain-of-thought logging, decision audit trails. The test I find most useful: if your AI product would be worse with a "show your reasoning" toggle, that's a signal worth sitting with. **Relationships (MH 239):** *Does it help me cultivate genuine closeness and cherish places where physical presence remains crucial?* Human-in-the-loop gates, escalation paths, documented decisions about what *not* to automate. There are workflows - in healthcare, banking, HR - where automation is the wrong answer even when it's the cheaper one. The encyclical gives you a principled frame for defending that choice to a CFO. **Justice (MH 240):** *Does it help me participate in the promotion of justice and peace?* Disparate-impact testing, demographic eval slices, red-team exercises for power-concentration use cases. The encyclical's language around "domination, exclusion, and death" will land in EU AI Act commentary within a year. Better to have the fairness audit cadence documented now. ## The governance table Most enterprise AI teams are already doing three of these four things. What's new is having a shared moral vocabulary to defend the work in front of a non-technical audience. | Encyclical question | Engineering control | Evidence to capture | Owner | |---|---|---|---| | Truth (MH 237) | Retrieval grounding, hallucination eval suite, refusal calibration | Factuality benchmark scores; % generations with verifiable citations; refusal rate on out-of-scope prompts | ML / Eval | | Education (MH 238) | Explainability surface, chain-of-thought logging, decision audit trail | Audit log retention policy; user comprehension research; explain endpoint coverage | Product + Eng | | Relationships (MH 239) | HITL gates on high-stakes actions, escalation to human, opt-out to non-AI path | Documented escalation thresholds; SLA for human handoff; map of intentionally non-automated workflows | Ops + Risk | | Justice (MH 240) | Disparate-impact testing, demographic eval slices, refusal taxonomy | Fairness eval cadence; documented use-case exclusions; third-party bias audit | Trust & Safety + Legal | ## The harder question The table is operationalizable. The anthropology underneath it is harder to test for. MH 112 and 231 raise a question that doesn't fit in a row: does this product treat the user as someone to be served, or as a process to be perfected? It's the difference between an AI that makes a banker better at their job and an AI that replaces the banker with a measurement of the banker. I don't have a clean eval metric for that. But it's the question that will surface in board conversations first - and the teams that have thought it through will have better answers than the teams that haven't. ## What to do this week Three actions, scaled to where you sit: 1. **If you run an AI product:** Pre-draft the four-questions mapping for your top three features. You will be asked for this. Better to have a version ready than to write it under deadline. 2. **If you sit on a governance committee:** Get the encyclical's vocabulary into your review template before someone external - a regulator, a customer, an auditor - puts it there for you. 3. **If you write RFP responses:** Expect "human dignity," "openness and communion," and "domination, exclusion, and death" in customer questionnaires within a quarter. Have answers that are more than boilerplate. --- The encyclical isn't going to change what good AI teams build. It's going to change what they have to say about what they build - and that's a real shift in the conversation. The vocabulary just got a very large institutional endorsement. Worth being fluent before the next architecture review. ================================================================================ ARTICLE: The Model Isn't the Moat ================================================================================ URL: https://chrisboyd.me/blog/the-model-isnt-the-moat/ Published: 2026-05-18 Tags: AI, Agentic AI, Enterprise AI, AI//FORWARD, Engineering Leadership Notes from AI//FORWARD and a leadership-development talk: why the companies winning with agentic AI aren't winning on model selection, and what they're building around it instead. ---

I spent Thursday at AI//FORWARD, and one thesis from the conference has stayed with me since I left the room.

The companies that win the agentic AI era will not be the ones with the best model.

They'll be the ones that built the best harness around it.

That's not a contrarian take for its own sake. It's the operational reality that practitioners are arriving at as they move agentic AI from experiment to infrastructure. The model is increasingly commoditized. Frontier advantage is measured in months, not years, with open source closing fast. The durable value, the thing that's actually hard to copy, is the layer you build around the model: tools, prompts, evals, guardrails, memory, observability, routing, policy enforcement, workflow logic.

That's your IP. Not the model subscription.

The governance problem nobody wants to talk about

Most of the agentic AI conversation is still about capability. The conversation at AI//FORWARD was about control, and the gap between where most organizations are and where they need to be.

Every agent running in production should have a registered use case, a risk tier, a named business owner, a defined review date, and a kill switch. That's not bureaucracy. That's operational hygiene for a system that can act on your behalf, at scale, with real consequences. The teams that skip this step aren't moving faster, they're deferring cleanup to a future incident.

And this is where the leadership problem starts to look like an architecture problem. If jobs are bundles of tasks, then every agentic workflow is also a talent decision. Which tasks are delegated to software? Which tasks stay with people? Which tasks become inspection points, judgment calls, or coaching moments?

The harness has a human side

The companies that build the best harness around AI will also be the companies that rebuild the first rung of career development. AI is absorbing a lot of the low-risk work people used to learn from: summarization, formatting, basic research, routing, first-pass analysis, status updates. None of that work was glamorous, but it gave junior people reps. It taught context, communication, value creation, and what good looked like.

If you automate those reps away without replacing them, you do not just get efficiency. You get a thinner apprenticeship system. The first rung still exists, but it is higher, narrower, and more demanding. That should change how leaders think about AI adoption. The question is not only "how much work can this agent do?" It is "what capability are we still building in the people around it?"

A real enterprise AI harness therefore includes more than tools and guardrails. It includes simulations, manager review, feedback loops, progressive challenge, and enough productive friction for people to develop judgment instead of outsourcing it before they understand the work.

More autonomy is not the goal

This one cuts against the dominant narrative, so I'll say it plainly: the right target is minimum viable autonomy for the use case. More autonomy means lower consistency, weaker process adherence, higher monitoring burden, and cost curves that can quickly outrun the value the agent was built to deliver. Multi-turn agentic workflows can cost 10x to 100x a single LLM call. Poorly designed agents can outspend the humans they were meant to replace.

The enterprise-safe pattern for multi-agent systems isn't autonomous peer-to-peer swarms. It's narrow sub-agents with scoped permissions, defined responsibilities, and logged handoffs. That architecture maps directly to security, audit, and compliance, which means it's the pattern that actually survives contact with the rest of your organization.

The better operating model is task-level decomposition. Stop asking whether AI can replace a job and start asking which tasks it can do, assist, accelerate, or reshape. Then assign responsibility deliberately: what the AI drafts, what a human inspects, what a human decides, and where the workflow should slow down because context is non-negotiable.

AI fluency is not expertise

There is a dangerous mirage of competence around AI. A weak plan can look polished. A shallow analysis can arrive with bullet points, citations, and executive tone. A junior employee can produce something that looks senior before they have the business acumen to know whether it is right.

That is not an argument against AI fluency. It is an argument for treating fluency as the floor, not the ceiling. The scarce asset is still knowing what matters, asking better questions, interpreting weak signals, making tradeoffs, and connecting work to outcomes. AI leverage without that layer is just faster output.

This is also why digital teammates need managers, not just users. Leaders have to learn how to delegate to both people and machines: where to accelerate, where to inspect, where to force reflection, and where accountability can never be handed off.

Vendor lock in has moved

It used to be: which model are you locked into? That's the wrong question now. The new lock in is at the harness layer, agent runtimes, workflow builders, managed memory, tool ecosystems, eval stacks, enterprise control planes. Vendors know the model is a commodity and they're building sticky infrastructure around it.

The strategic response is simple to articulate and hard to execute: keep model optionality, make your prompts, tools, skills, and workflows portable, and treat your harness assets as strategic IP. Don't let a vendor own your operational layer. And do not let the vendor's polish become a substitute for your own expertise. Portability matters for systems, but it also matters for judgment.

Two things I'd add

Start capturing high-quality agent trace data now. The talk made this point about SLMs, smaller language models fine-tuned on your own agent logs, and it's correct. Today's operational data is tomorrow's fine-tuning asset. Teams that aren't logging structured traces are leaving that value on the table.

I would capture the human side of that trace too: what reviewers changed, where agents needed coaching, which judgment calls stayed with people, which tasks became reliable enough to delegate, and where the organization still needed better reps. That is not just compliance data. It is the map of how your expertise formation system is actually working.

Agentic AI is no longer a research problem. It's an operations problem. The infrastructure you build around the model, governance, harness, cost controls, portability, talent development, and human accountability is the work that compounds.

The talent formula is becoming AI leverage plus real expertise plus judgment plus business context plus communication. The companies that win will not simply automate junior work away. They will use AI to manufacture better reps, build stronger digital teammate workflows, and preserve the scarce human capabilities that make the harness worth trusting.

================================================================================ ARTICLE: How I Evaluate an AI Tool Before I Trust It in Production ================================================================================ URL: https://chrisboyd.me/blog/how-i-evaluate-an-ai-tool-before-i-trust-it-in-production/ Published: 2026-05-11 Tags: AI, Engineering, Machine Learning, Tools, Production Most AI tool evaluations stop at "does it work in the demo." Here's the framework I actually use before trusting something in a production system. --- The AI tooling market is producing new options faster than most teams can evaluate them. Every week there's a new framework, a new model wrapper, a new agent orchestration layer with a compelling demo and a reasonable price point. I've evaluated a lot of them. Most of the time, the demo works. That's not the interesting question. The interesting question is what happens six months in, at scale, when something goes wrong in a way nobody planned for. Here's the framework I use before I trust anything in a production system. --- **1. How does it fail?** This is the first question, not the last. Every system fails eventually. The question is whether it fails predictably, noisily, and safely — or quietly, inconsistently, and in ways that corrupt downstream data or erode user trust before anyone notices. I want to know: does the tool have documented failure modes? Does the vendor talk about them honestly, or do I have to find them in a GitHub issue thread from eight months ago? Can I reproduce the failure in a controlled test environment before it surprises me in production? A tool with honest, documented failure modes is worth more than a tool with impressive benchmark numbers and vague error handling. --- **2. Can I observe it?** Observability is non-negotiable. I need to know what the tool is doing, when it's doing it, how much it costs per call, what inputs it received, and what outputs it produced. If I can't log and inspect the full execution at the level of detail I need, the tool is not production-ready for my use case, regardless of what the marketing page says. This is especially critical for agentic systems. As I covered in [The Six-Layer AI Agent Stack](/blog/the-six-layer-ai-agent-stack), the execution loop and constraints layers are where things go wrong in ways that are hard to detect without full observability. If the tool abstracts that away from me, I don't want it in production. --- **3. What does it cost when something goes wrong — and at what scale?** I run cost projections at 1x load, 10x load, and a failure scenario where the system loops unexpectedly for 30 minutes. If the answer to that third scenario is "catastrophic," I need a hard cost ceiling and a kill switch before anything goes live. Pricing models that look reasonable in development become expensive at scale in ways that are easy to overlook when you're evaluating based on happy path usage. Map the worst case, not the average case. --- **4. What's the rollback path?** If I turn this off tomorrow, what breaks, how badly, and how fast can I recover? The tools I trust most are the ones where the rollback path is clean and the blast radius of removal is bounded. The tools I'm most cautious about are the ones where the answer to "what if we need to remove this?" is "well, it's pretty deeply integrated at this point." Evaluate the exit before you evaluate the features. --- **5. How does it behave on adversarial or unexpected input?** Run the tool against inputs it wasn't designed for. Inputs that are malformed, inputs that are adversarially structured, inputs that are reasonable but outside the documented use case. Does it fail gracefully? Does it produce confident-looking garbage? Does it do something unpredictable that cascades into downstream systems? Most demos use clean, structured, expected inputs. Production doesn't. Test accordingly. --- **6. Is the vendor transparent about limitations?** The vendors I trust most are the ones who lead with what their tool doesn't do well. Not as a disclaimer buried in the docs, but as a genuine part of how they talk about the product. That transparency tells me they've actually tested the edges and they'd rather I find the limitations in evaluation than in a 2 AM incident. Vendor confidence is not a signal. Vendor honesty about the hard cases is. --- **7. Can I build an evaluation harness around it?** Before I use any AI tool in production, I want to be able to write automated tests against its output. Not just "does it return a response" — does it return the right kind of response, within an acceptable range, consistently across a representative sample of inputs? If the tool's output is so variable or opaque that I can't write meaningful evals, I can't operate it safely at scale. Evaluation-friendliness is a product quality signal, not a nice-to-have. --- **The short version** Demo performance is the floor, not the ceiling. The ceiling is: does this hold up when the inputs are messy, the load is real, something unexpected happens, and I need to know exactly what it did and why? No AI vendor is going to answer that question for you honestly. You have to stress-test it yourself, with real failure scenarios, before the real failure scenarios find you. ================================================================================ ARTICLE: The Southeast Doesn't Need Permission to Build ================================================================================ URL: https://chrisboyd.me/blog/the-southeast-doesnt-need-permission-to-build/ Published: 2026-05-04 Tags: Leadership, Technology, Southeast, Engineering, Career The assumption that serious tech work only happens in San Francisco, New York, or Seattle is wrong — and increasingly expensive to believe. A practitioner's case for building in the Southeast by choice. --- I've had the conversation enough times that I can finish it before the other person does. "Oh, you're based in Charlotte?" Yes. "Have you thought about relocating?" I have thought about it. I've decided against it. "But don't you find it limiting?" No. Here's the version of the answer I usually don't have time to give. --- **The geography argument is a decade stale** The idea that you need to be in San Francisco to do serious work in technology was marginally true in 2012 and is mostly mythology in 2026. The infrastructure that made physical clustering essential — capital concentration, talent density, the serendipitous coffee shop meeting — has been replicated digitally to a degree that makes the coast premium a choice, not a requirement. Teams are distributed. Capital is mobile. Conferences are hybrid or recorded. The tier-one network that used to require a San Francisco zip code now requires a LinkedIn profile and the willingness to show up, in person or otherwise, when it matters. What hasn't changed: the assumption that geography is destiny. That assumption is doing a lot of work it can no longer justify, and it costs people real money and real quality of life to believe it. --- **The Southeast corridor is not a consolation prize** Charlotte. Greenville. Atlanta. Nashville. These cities are not aspirationally approaching relevance — they are already producing serious companies, serious capital events, and serious engineering talent. Anyone who tells you otherwise hasn't been paying attention to the last five years of deal flow. What the Southeast has that the coasts don't: cost of living that allows engineers to build equity instead of spending their entire salary on rent; a talent market that isn't in a permanent war with every funded startup in a three-mile radius; and a genuine proximity to industries — financial services, healthcare, manufacturing, logistics — that are in the middle of meaningful AI-driven transformation and are not going to relocate to SoMa. I'm not building here because I couldn't make it somewhere else. I'm building here because this is where the problems worth solving are concentrated, and where the operational credibility of having actually worked in those industries still means something. --- **The "flyover" framing is someone else's problem** There's a version of this post that spends a lot of time pushing back on coastal dismissiveness. I'm not particularly interested in writing that version. Whether people in San Francisco take the Southeast seriously is not a constraint on what gets built here. What I care about is the internal version of the problem: engineers and leaders in the Southeast who have absorbed the idea that where they're building is a limitation to apologize for, rather than a position to lean into. That's the one worth correcting. If you're building something real in Charlotte, Greenville, Atlanta, or Nashville, you don't need to frame it as "despite being in the Southeast." The Southeast is the frame. Build in it deliberately. --- **Proximity to the unsexy problems is an advantage** The most interesting AI applications right now are not in consumer social. They're in healthcare operations, financial compliance, industrial manufacturing, and supply chain logistics. These industries are headquartered, operated, and — critically — making purchasing decisions in cities like Charlotte, Atlanta, and Nashville. The practitioner who has spent years inside one of those industries, who understands the regulatory environment, the legacy infrastructure, and the operational reality of the problem — that person has a durable advantage over someone who has never been in the room where the decisions get made. Geography shapes context. Context shapes credibility. Credibility is what gets you the contract, the partnership, or the offer. I'm not in the Southeast because I didn't notice San Francisco. I'm here because this is where the context is. ================================================================================ ARTICLE: Your AI Agent Didn't Go Rogue. You Gave It the Keys. ================================================================================ URL: https://chrisboyd.me/blog/your-ai-agent-didnt-go-rogue-you-gave-it-the-keys/ Published: 2026-04-28 Tags: AI, Production AI, Security, Engineering Why the Cursor/Railway incident wasn't a vendor failure - it was an architecture gap. How to prevent AI agents from accessing permissions they shouldn't have, and why ownership matters. --- A widely-circulated post hit X this week showing an AI coding agent - Cursor backed by Claude Opus - delete a production database and all its backups in nine seconds flat. One Railway API call. Gone. The agent then produced a written confession that it had violated every safety instruction it was given. The internet did what the internet does: blame the vendors. Cursor should have stopped it. Railway should have gated it. Claude should have refused. I want to talk about the part nobody wants to hear: **the vendor didn't delete your data - an agent with keys you issued deleted your data.** ## System Prompts Are Advisory, Not Enforcement Here's the uncomfortable truth about every system prompt you've ever written for an AI agent: it's a suggestion. A strong suggestion, sure. But there is no runtime contract, no execution boundary, no hard stop. A model can acknowledge your safety instructions and then act against them in the same response. That's exactly what happened here - the agent cited the rules it was breaking *while it broke them*. If your only safety layer is a natural-language instruction to a probabilistic model, you don't have a safety layer. You have a hope. Hopes don't survive contact with production. Real safety lives in your architecture, not your prompts. The prompt can remind the model to be careful. The architecture is what makes "careful" the only option. ## Principle of Least Privilege - Actually Do It The Railway API token in this incident had blanket permissions. It could provision, modify, and destroy infrastructure including volumes and backups. That token was handed to an AI agent whose job was to write code. Ask yourself: why does a coding agent need the ability to delete a production database? **Principle of least privilege** isn't a new idea. We teach it in week one of any security course. But teams hand full-access tokens to AI agents every day because scoping tokens is friction and the agent "needs access to work." That's the same logic that got us `chmod 777` in the early days of Linux administration. **Agent capability scoping** means deciding - before you give an agent credentials - exactly which operations it may perform and building a token or proxy layer that enforces it. Read-only tokens for read tasks. Deploy tokens that can push but not destroy. No token that can delete production data should ever be in an agent's context, period. If the agent needs a destructive action, it can request it. A human can execute it. ## Human-in-the-Loop Isn't Optional for Destructive Operations I run AI agents in production workflows. They draft, they generate, they modify, they deploy. But any operation that is destructive or irreversible routes through a **human-in-the-loop gate**. Every time. This isn't about not trusting the model. It's about understanding the failure mode. When a coding agent hallucinates a wrong variable name, you get a bug. When it hallucinates a wrong API call with full permissions, you get a production outage. The cost distribution is asymmetric, so the control architecture has to be asymmetric too. A confirmation gate on destructive API operations - delete volume, drop database, remove backup - would have stopped this incident cold. Nine seconds is a long time when a human is in the loop. ## Your Backup Strategy Can't Live Next to Your Data The backups in this incident were Railway volume snapshots stored on the same volume as the production data. One delete call took both. That's not a backup strategy. That's a copy in the same room as the original. The **3-2-1 rule** exists because disasters are correlated. Three copies of your data. Two different media or storage types. One offsite. If an agent, an attacker, or a fat-fingered engineer can reach your backups through the same credential path that reaches your production data, they aren't backups. They're liabilities wearing a comforting label. ## Environment Isolation Is the Boring Work That Saves You Production, staging, development - these should be hard boundaries, not naming conventions. Different accounts, different credentials, different access policies. An agent operating in a development context should be physically unable to reach production resources. Not instructed not to. *Unable to.* The boring architectural work - separate accounts, scoped tokens, gated operations, offsite backups, environment isolation - is exactly the work that makes AI agents safe to run in production. It's not exciting. It doesn't demo well. It's the difference between a nine-second outage and a non-event. ## You Own Your Blast Radius Here's where I'll be direct: Cursor is an IDE. Railway is a hosting platform. Neither is an AI safety platform, and neither promised to be. Expecting the vendor to prevent your agent from using the permissions you granted, through the credentials you provided, on the infrastructure you configured is an ownership gap - and it's one I see across the industry right now. If you're building with AI agents in production, **you own your blast radius.** Not Cursor. Not Railway. Not Anthropic. You. The team that issued the token, chose the permission scope, designed the backup architecture, and decided whether a human had to approve a destructive action. The models will get better. The vendors will add guardrails. But if your production safety depends on either of those things happening first, you're already behind. Architect like your agent will do the worst thing it can do with the permissions it has. Then make sure it can't. ================================================================================ END OF CONTENT EXPORT ================================================================================