Chang Min Park

Who Picks the Next Step: Loops vs Graphs

Tue, 08 Sep 2026 10:30:00 +0000

Prerequisites

Read these first if prompts, agent loops, orchestration graphs, harnesses, or agentic design patterns are new.

Building effective agents (Anthropic) — when a predefined workflow beats a free-form tool loop, and the reverse
The Art of Loop Engineering (LangChain) — an agent as model + tools until a stop condition; stacked loops around that core
LangGraph (LangChain) — cyclical graphs as an agent runtime; nodes, edges, and LLM-chosen branches
Agentic design patterns, part 1 (Andrew Ng) — reflection, tool use, planning, multi-agent as capabilities, not a framework vote
Introducing Loops (Linear) — scheduled or event-triggered agent runs; the product name that collided with “graph” on X

The wrong question

I do not need a DAG (directed acyclic graph) to fix a Kotlin null in Cursor. The session is already a loop: read, edit, run the test, repeat until the test or I say stop. Nobody draws LangGraph for that.

In July 2026 two announcements landed in the same week. DeepLearning.AI released a course with “graph” in the title. Linear released a product called Loops. On X, people treated that coincidence as a fork you had to pick: build agents as loops, or build them as graphs.

That is the wrong question. The useful one is simpler: who picks the next step, and when? A loop answers that at inference time — the model chooses the next tool while it runs. A graph answers it at authoring time — you already named the legal hops in code. Everything else in this post is that distinction, plus the layers people keep stacking next to it as if they were rival products.

Two words, four jobs

The July argument mashed four jobs under two nouns:

Phrase people used	Actual job	Example
Knowledge graph	Data: entities and edges you store	Neo4j course on building a product-issue graph from CSVs and reviews
Orchestration graph	Control flow: which node runs next	LangGraph, a state machine, a CI DAG
Agent loop	Control flow: model picks the next tool	Claude Code, Cursor, a ReAct `while`
Linear Loop	Product: cron or trigger plus an agent	Recurring triage, doc updates

A knowledge graph answers what is related. An orchestration graph answers who runs next. Mix those and a course about storing related facts sounds like a vote for LangGraph. Linear’s Loops is closer to cron plus an agent than to either.

Andrew Ng did not write the “graduate from loops to graphs” ladder people attributed to him. He published design patterns — reflection, tool use, planning, multi-agent — and iteration beats one-shot. Those fit inside a loop or a graph. The course that started the noise, Agentic Knowledge Graph Construction, is Kollegger / Neo4j filling a knowledge graph. Ng hosts the platform.

So forget the fork. Keep the question: who picks the next step, and when?

Loop vs graph

A coding-agent session is one model, tools, a budget, a stop. Each turn the model chooses a tool. The next step does not exist until it emits it.

# The model chooses the next action. Edges are not in your repo.
while not done and steps < budget:
    action = model.decide(state)   # billed every iteration
    state = env.step(action)
    done = harness.should_stop(state)

Use a loop when you cannot draw the workflow without running it: debugging, open-ended research, “make this Compose preview compile.” A graph cannot discover a step you did not author.

An orchestration graph is the other end. You wrote the legal next steps when you drew the nodes. The model still works inside a node — often as its own loop — and it may still pick among declared successors. It does not invent a hop that is not on the map.

# You chose the next node. The model does the work inside one.
g.add_edge("triage", "android")
g.add_conditional_edges("critic", {"pass": "human", "fail": "android"})

That buys inspectability and a real checkpoint — a human step before a store-facing side effect. You pay in coordination cost and bugs in the graph itself.

flowchart LR
  M[Model] -->|picks tool| T[Tool]
  T -->|observe| M

Figure 1. A loop: the model owns the next hop. There is no edge list in the repo.

flowchart LR
  A[Triage] --> B[Android specialist]
  B --> C[Critic]
  C -->|fail| B
  C -->|pass| H[Human gate]

Figure 2. A graph: the edge list owns the next hop. The Android node may still run a loop inside.

A loop is already a graph with one node and an edge back to itself. The interesting difference is when routing is decided, not whether you can draw a circle.

Layers, not a ladder

Vendor decks also stack prompt, loop, graph, and harness as if you pick one. They answer different questions. They stack under the same “who picks next?” problem; they are not four products.

Term	Question it answers	What you write	What it cannot do
Prompt	What should this model call do?	System / user text, few-shots	Call a tool, retry, veto “done”
Loop	Who picks the next tool?	`while` + model + tools	Declare illegal hops; enforce a stop
Graph	Which named step may run next?	Nodes, edges, joins, human gates	Discover a step you did not draw
Harness	What may execute, and when is it actually done?	Tool allowlists, hooks, observe, budgets	Invent product intent (that is the spec / prompt)

The prompt is an input to a turn. The loop is who picks the next tool. The graph is which named step may start. The harness is the machine that runs a loop or a graph — hooks, permissions, max steps — and can refuse both. A loop without a harness stops when the model writes an essay. A graph without a harness still has no honest “done” on a node. The harness is not a fourth topology.

flowchart LR
  H[Harness] --> G[Graph]
  H --> L[Loop]
  G --> L
  L --> P[Prompt]

Figure 3. Layers, not a ladder. The harness can run a graph or a loop. A graph still bottoms out in a loop. Every turn still has a prompt.

You do not need all four on every task. Almost every useful agent has a prompt and a harness. Then you choose a control-flow shape: usually a loop; a graph only when the path is real.

Take the Kotlin null. The prompt names the file. The loop reads, edits, and runs the test. The harness refuses “done” until the test exits 0. Drawing a graph here is leftover ceremony.

For example, in a mail-style Android client, a crash that must be grouped, attributed to a module, checked against a release flag, and only then allowed to file a public bug is a path: triage → specialist → critic → human. Different duties, different stop rules, a human before anything leaves the building. That is graph-shaped even if you implement it with three scripts and a queue. Each node still has a prompt and a loop. The harness is what blocks the public-bug file until the human step runs.

If a chat failed, name the layer. Wrong wording is a prompt bug. The model wandering into the wrong module is a loop with a thin harness. A missing human approval step is a graph you never drew. A long “done” write-up over a failing test is a missing harness, not a reason to buy LangGraph.

So when do I draw edges?

Situation	Prefer	Why
One module, one verifier, same retry	Loop	Topology is overhead
Research → write → skeptic → ship or return	Graph	Different duties and stop rules
Parallel audit, then a veto	Graph	Fan-in is a real join
Human approval before a store/side effect	Graph + gate	The checkpoint is an edge

A personal Cursor session on one Gradle module stays a loop. Recurring Linear triage is a triggered loop with a review step — closer to cron plus an agent than to a knowledge graph or to LangGraph.

Do not buy a graph framework to feel current. Buy it when you can name the nodes, the illegal transitions, and the join you will debug at 2 a.m. Until then the interesting engineering is still the loop: tools, budgets, and a stop that is not the model’s essay. Same default Ng and Anthropic point at — start with iteration inside a loop; add named nodes when a branch, a join, or a human gate is a real requirement.

References

Agentic Design Patterns Part 2: Reflection (Andrew Ng) — self-critique in one worker vs a separate critic agent
Agentic Knowledge Graph Construction (DeepLearning.AI) — Kollegger / Neo4j; entities and relationships, not LangGraph
Graphs vs. Loops: the orchestration debate (explainx) — July 2026 collision of the knowledge-graph course and Linear Loops
Graph Engineering: when an agent loop should be a graph (Sangam Pandey) — inference-time vs authoring-time routing
Andrew Ng, loops and graphs as production architecture (TrueFoundry) — graph nodes still contain loops; do not confuse with knowledge graphs
2025 was agents; 2026 is harnesses — runtime around the model: tools, context, stop conditions
Harness, graph, and loop engineering (Sarthak) — stacked layers; loops and graphs are two ways to run, not replacements for a harness

The Rule the Other Agent Never Saw

Wed, 02 Sep 2026 14:20:00 +0000

Prerequisites

Read these first if .mdc project rules, CLAUDE.md vs AGENTS.md, hooks, or skills are new.

Cursor docs — Rules — .cursor/rules/*.mdc with frontmatter; a plain .md in that folder is ignored
Claude Code — Memory — reads CLAUDE.md, not AGENTS.md; @AGENTS.md import and /import as a one-time copy
Cursor — Third-party hooks — Claude .claude/settings.json hooks load in Cursor only after an opt-in
Claude Code — Skills — .claude/skills/*/SKILL.md, not Cursor's skill tree
Claude Code — MCP — listing a server is not enabling it; deny lives in settings

Why the same checkout disagrees

A company blesses Cursor and Claude Code, or it blesses one and people still use the other — different teams, different laptops. That is normal. The failure is treating “the repo has rules” as if every agent reads the same files.

Each product is its own loader. Which sentences enter the window depends on which binary someone launched. Two people on the same ticket can follow two policies without knowing it.

The case that made this concrete for me was a security / skill-creation rule: do not add a second skill (or a second always-on rule) for a job the repo already owns. Cursor honored it. Claude Code cheerfully wrote .claude/skills/review/SKILL.md next to the existing .cursor/skills/review/ playbook — same job, second copy, now two sources of truth. The model did not rebel. The “no duplicates” sentence lived only in a .mdc with alwaysApply: true. Claude Code never saw that file.

flowchart LR
  repo[Git tree]
  repo --> cur[Cursor]
  repo --> cla[Claude Code]
  cur --> mdc[".mdc / AGENTS.md"]
  cur --> chooks[hooks.json]
  cla --> cmd[CLAUDE.md]
  cla --> crules[".claude/rules/*.md"]
  cla --> sethooks[settings.json hooks]

Figure 1. One checkout, two loaders. Overlap is accidental unless you designed it.

`.mdc` is not `.md`

Cursor project rules must be .mdc (frontmatter for globs / alwaysApply). A plain no-duplicate-skills.md in .cursor/rules/ is ignored. Claude’s .claude/rules/ is the opposite: .md, recursive. Copy without renaming and nothing loads.

A Cursor glob on **/{skills,rules}/** has no 1:1 in a root CLAUDE.md. Flatten it and you burn context on every ls; skip it and the CLI never sees the no-duplicate rule. Claude’s path-scoped .claude/rules/ is a cousin, not a clone.

AGENTS.md looks portable. Cursor reads it. Claude Code reads CLAUDE.md, not AGENTS.md. The bridges are @AGENTS.md in CLAUDE.md, or /import, which appends a copy. A copy forks the next time someone edits only one side.

The rest of the harness splits too

Surface	Cursor	Claude Code	How it bites
Rules	`.mdc` (+ `AGENTS.md`)	`CLAUDE.md`, `.claude/rules/*.md`	“Do not create a duplicate skill” lives only in Cursor
Skills	`.cursor/skills/`	`.claude/skills/*/SKILL.md`	Claude writes a second `review` skill because it never saw the no-duplicate rule
Hooks	`.cursor/hooks.json`	`hooks` in `.claude/settings.json`	A write-block on new `SKILL.md` files never runs in the other product (Cursor loads Claude hooks only if you opt in; `Bash` vs `Shell`)
MCP	`.cursor/mcp.json`	`.mcp.json` + enable/deny lists	Connected in the IDE, pending in the CLI
Org overlay	Team / User rules, `~/.cursor/`	`~/.claude/`, managed settings	Dashboard policy never hits the CLI

Ignore files, memories, subagents, and permissions.deny split the same way.

Markdown is advice. A PreToolUse deny is a gate the model cannot forge. If that gate lives only in .cursor/hooks.json, Claude Code will agree not to add a second skill and then write .claude/skills/review/SKILL.md anyway. Cursor Team Rules feel like company policy and never leave the IDE.

A missing file is easy: “Claude doesn’t pick up .mdc.” Both files present and disagreeing is worse. Cursor says one review skill, owned here. Claude’s .md still says “add a skill when the workflow is useful.” Each session looks consistent. The repo now has two playbooks. /import and a hand-copied .mdc are the same bug as the duplicate skill: a second copy you will not keep in sync.

Rule of thumb - if it must hold in both products, prove it in both: ask each agent to add a review skill that already exists. If only Cursor refuses, you have folklore in git.

Keep one prose file, thin adapters

Do not symlink everything. Do not generate forty adapters.

Put portable facts in AGENTS.md (one skill per job, where skills live, who owns them). Point Claude at it with @AGENTS.md. Keep Cursor globs in .mdc, Claude path rules under .claude/rules/, and hard stops in hooks both processes actually run — after the third-party-hook opt-in, with matcher names checked.

Do not put “do not create a duplicate skill” only in a .mdc, org security only in a Cursor dashboard, or treat /init / /import as a sync. Those are onboarding. Drift starts on the next edit.

Where a constraint lives inside one product is a placement problem. Making the tree readable is a map problem. If the CLI “forgets” a rule Cursor still injects, look at the loaders before the model.

References

AGENTS.md — the cross-tool instruction file Cursor reads natively; Claude Code still needs an import
Explore the .claude directory — which Claude files are project vs ~/.claude
Cursor — Skills — Cursor’s on-demand playbooks vs Claude’s SKILL.md tree
Where every AI coding tool looks for instructions — loader map across Cursor, Claude Code, and neighbors
Switching from Cursor to Claude Code? Your rules stop working — the .mdc → CLAUDE.md migration people underestimate

You Can't Delete Claude's Watermark With a Remover

Sat, 22 Aug 2026 19:35:00 +0000

Prerequisites

Read these first if SynthID-style text watermarks, EU AI Act transparency marking, or C2PA file credentials are new.

How Claude's text watermarking works (Anthropic) — word-choice watermark, not hidden characters; what a detection score can and cannot mean
How Claude marks AI-generated content — text watermark vs C2PA on files; applies across API and products
SynthID-Text (Nature, 2024) — the watermarking method family Anthropic builds on
EU AI Act overview — why providers are marking generated content for transparency

The wrong mental model of “delete”

Within days of Anthropic explaining Claude’s invisible text watermark, the web filled with “watermark removers.” Many of them strip zero-width Unicode, normalize fancy dashes, scrub metadata. That toolkit made sense when people suspected hidden characters. Claude’s mark is not that.

Anthropic’s public write-up is blunt: nothing is added to the text. The signal is a statistical pattern in which near-synonyms the model picks — a SynthID-Text-style scheme. You cannot sed away a bias in sampling. Anthropic frames the launch as EU AI Act transparency marking applied globally; other providers will use different keys. Until a public detector exists, “we removed Claude’s watermark” is faith-based.

The claim worth arguing: you cannot delete the mark; you can only replace the words. A positive detection means Claude was in the loop, not that a human was out of it. Removers, C2PA strippers, and authorship court all fail that distinction.

How the mark gets into the prose

Language models repeatedly choose the next token among candidates. Sometimes the choice is forced (Principia → Mathematica). Often it is soft: overcast vs grey. Watermarking reuses those soft choices. Sampling is nudged with a secret key and recent context so that, over a long enough passage, the sequence of soft picks is unlikely under a human or a different key.

flowchart LR
  ctx[Prior tokens] --> candidates[Soft candidates]
  key[Watermark key] --> pick[Biased sample]
  candidates --> pick
  pick --> next[Next word]
  next --> pattern[Long-run pattern]
  pattern --> detect[Detector with key]

Figure 1. The watermark is not a sticker on the paragraph. It is a bias in low-stakes word picks that becomes measurable only with the key and enough text.

Consequences that kill the remover fantasy:

Short snippets are weak. Few soft decisions → little signal.
Hard text is sparsely marked. Code that must compile and math that must be right leave fewer degrees of freedom.
Heavy Claude writing leaves more mark. A from-scratch draft is dense; a light proofread may not move the needle.

Removers do not delete — rewrites replace

Attack people propose	What it actually does
Strip zero-width / bidi / “AI dash” Unicode	Removes characters that were never the Claude watermark
Strip C2PA / EXIF from a PNG	Drops file provenance. Does not touch text watermark
Light edit, synonym sprinkle	May leave enough of the original soft-pick sequence to still score
Full paraphrase / retranslate with another model	Can destroy the Claude-key pattern — because you replaced the words
“Remover” SaaS before a public detector exists	Unverifiable marketing until you can re-run a real detector

Anthropic’s FAQ lands where the engineering does: light editing probably does not wipe the mark; a complete rewrite will — and at that point you are arguing whether the artifact is still “Claude’s text.” Evading a watermark the hard way is authorship transfer by exhaustion, not a delete button. The cottage industry selling one-click deletion is, for now, mostly Unicode hygiene and hope.

Do not conflate that with C2PA on supported files. Text watermark lives in word-choice statistics and survives copy-paste; C2PA is signed file metadata that often dies on export or screenshot and is easy to strip. If your threat model is a CMS paste, the sticky signal is the text mark — the one removers keep misunderstanding.

A positive hit is not authorship court

A Claude watermark detector (when the API ships) answers something like: how likely is it that Claude was involved in producing this passage? It does not prove a human did not write the first draft, distinguish “Claude authored this” from “Claude heavily edited this,” identify which user called the API, or detect GPT- or Gemini-only text.

That gap creates real failure modes. You paste a design doc into Claude for a clarity pass; the returned prose may carry detectable involvement even though the ideas were yours. You ask Claude Code for a PR description; the markdown may be marked while the diff is mostly yours. A hiring screen that treats “watermark present” as “cheated” is using a probability as a verdict. The dual error is also true: absence of a Claude watermark is not proof of human authorship.

I use Claude the same way many Android engineers do: draft PR text, reshape release notes, occasionally a first pass on a design doc. Watermarking does not change ownership under Anthropic’s terms. I still own the words I merge. Do not treat a future detector score as court — decide the policy you want (disclose assistance, ban certain uses, or judge the work product). Separate C2PA hygiene from text hygiene when you ship screenshots.

The headline fight has a precise answer: not by deletion, only by replacement. Everything else is metadata theater or an unverifiable SaaS claim. The harder product question is the one Anthropic already admits: a watermark says Claude was in the loop, not that a human was out of it.

References

AI ‘watermark removers’ flood the web (BleepingComputer) — why Unicode/C2PA strippers do not prove text-watermark removal
Claude will apply invisible watermarks (The Verge) — product scope and EU timing context
Watermarking AI-generated text with SynthID (DeepMind blog) — accessible overview of the method family (paper is in Prerequisites)
C2PA specification — signed content credentials for files (distinct from text sampling watermarks)

When GitHub Actions Is the Outage

Fri, 07 Aug 2026 10:00:00 +0000

Prerequisites

Read these first if GitHub Status, Actions runners, or required checks as a merge freeze are new.

GitHub Status — step zero when every repo’s Actions lies at once
Understanding GitHub Actions — workflows, jobs, and how a runner gets assigned work
About self-hosted runners — your VM is not a full escape from GitHub’s scheduler
About protected branches — required checks turn an Actions outage into a merge freeze
About status checks (GitHub) — what those required checks are supposed to protect

It was not your Gradle cache

On August 6, 2026, GitHub Status opened an Actions investigation at 15:22 UTC. Within an hour, workflow runs were failing to start or dying mid-flight, the Actions REST API was erroring, and some workflows saw unexpected rate limits. Capacity stayed constrained for hours. Hosted runners were hit hard; self-hosted runners still saw registration errors and rate limiting. Webhook delivery slowed. Pages, Copilot code review, and Copilot coding agent degraded alongside Actions. Enterprise Importer migrations were paused to help recovery.

By evening, GitHub’s updates named a concrete failure mode: runners were being assigned jobs that were no longer valid. Job success rates for runs that could start climbed from roughly 30–40% earlier in the incident toward 97–99% after mitigations. Webhook-triggered workflows stayed throttled while queues burned down. A cold Gradle cache does not look like that. A broken assignment / scheduling path does.

If your merge bar is a required Actions check—and for most Android PR gates it is (see GitHub Actions for Android PR gates)—then an Actions outage is not a vendor inconvenience. It is a shipping freeze with a status-page URL.

What actually broke (from the public timeline)

You do not need an internal postmortem to act. The public status updates are enough to shape an on-call mental model:

Symptom teams saw	What it usually means
Jobs sit `queued` for a long time, then time out	Assignment / capacity path is stuck
Runs fail at start or mid-job with infra errors	Runner got work it cannot finish cleanly
Actions API errors / odd rate limits	Control plane under load or shedding
Self-hosted runners “online” but idle	Scheduler / registration path, not your VM
Pages / Copilot agents / webhooks wobble	Shared dependency blast radius

Rule of thumb - if every repo’s Actions went weird in the same window, open githubstatus.com before you debug gradle.properties.

Self-hosted is the wrong comfort blanket here. Your machines still ask GitHub’s scheduling layer for work. When that layer assigns dead jobs or throttles registration, “we run our own runners” does not buy immunity. Hosted vs self-hosted still matters for SDK images and secrets—see GHEC vs GHES—but it is not a reliability silver bullet for Actions itself.

Why this hurts Android merge queues specifically

Android PR latency is already expensive: Gradle, emulators optional, module graphs, cache warm-up. Teams design merge contracts so humans wait on a bounded green check, not a forty-minute vanity matrix.

When Actions degrades:

Required checks stop meaning “safe to merge.” They mean “the fleet could not prove anything.” Merging on red because “Actions is down” is a policy decision—not a free pass.
Retry storms make it worse. Twenty engineers hammering Re-run all jobs on a throttled webhook path deepens the backlog. Prefer one coordinated retry after status shows recovery, not N independent panic clicks.
Agent / bot reviewers go quiet too. Copilot code review and coding agent sat in the same blast radius. If your process assumes a bot comment before human review, that assumption fails with the scheduler.
Release trains that only trust GitHub-hosted proof stall. Org CI next door (Jenkins, Screwdriver, Buildkite) exists partly for this reason—see Jenkins to Screwdriver—but day-to-day PR gates usually still live on Actions.

The practical failure mode on a large client monorepo is social as much as technical: Slack fills with screenshots of yellow dots, people ask whether to merge without checks, and someone almost ships a Manifest permission change because “CI has been broken all day.”

What to do while it is red

Keep a short playbook next to your workflow YAML—not a novel:

Confirm scope. One repo vs status page. If status is red for Actions, stop local archaeology.
Freeze non-urgent merges that require Actions proof. Document the exception path (who can waive, for what class of change).
Do not mass re-run. Re-run after GitHub reports queues draining and webhook throughput restoring—not every fifteen minutes.
Separate “human review done” from “machine proof done.” Review can continue offline; merge waits for proof unless policy explicitly allows a waive.
After recovery, re-run the critical path once on main/release branches you care about. Queued-before-recovery jobs may still be poisoned.

Optional resilience (months, not during the fire): a thin org CI shadow for release branches, or a documented manual assemble cone for emergencies. Dual-running every PR on two fleets is usually cost theater; dual-path for promotion is often rational.

What not to conclude

Do not rewrite your whole DevEx strategy from one bad Thursday. Do conclude:

Actions reliability is part of your merge SLA, not GitHub’s problem alone.
Status pages belong in the first five minutes of “CI is broken” triage.
Self-hosted runners optimize for environment control; they do not remove scheduler coupling.
Cascades matter: the same day can take down Pages deploys and AI review bots that your process silently depends on.

GitHub will publish a fuller RCA when it is ready. Until then, the actionable lesson is operational: when the green check is lying because the platform is lying, treat it like an incident—not like a flaky unit test.

References

Experiment Layers vs Overlapping on Mobile

Sat, 18 Jul 2026 12:00:00 +0000

Prerequisites

Read these first if A/B tests, exposure, or feature flags vs experiments are new.

Statsig — Layers — mutual exclusion domains
Embracing overlapping A/B tests — why isolation can hurt power
Holdouts — measuring cumulative impact with a held-back floor
Statsig — Feature flags — kill switch vs rollout vs experiment

This A/B ate that A/B

Two “winning” experiments ship the same week: a denser message list and a louder compose CTA. Metrics look great in isolation. Together, the inbox feels noisy and send drops. Neither dashboard was wrong; both were reading a population that quietly overlapped. Traffic topology is the thing nobody put in the readout.

This is not a rewrite of kill switch / rollout / experiment jobs. It is the failure mode when those jobs share a screen without a contract.

The wrong fight: “overlap is modern, layers are legacy”

Platforms that argue for overlapping assignment (e.g. Statsig’s public writing) are right about velocity and statistical power: isolating everything destroys both. The same docs still ship layers (mutual exclusion domains) and interaction detection — because some treatments are not independent parameters.

flowchart TB
  subgraph overlap ["Overlapping — combinations exist"]
    direction TB
    uO[User U]
    uO --> aO["Exp A: denser list"]
    uO --> bO["Exp B: louder CTA"]
    aO --> combo["U's inbox = denser + louder"]
    bO --> combo
  end

  subgraph layer ["Layer — mutual exclusion"]
    direction TB
    pop[Users in one layer]
    pop --> xor{"Hash once — A XOR B"}
    xor -->|"slot A"| aL["Exp A only<br/>never enters Exp B"]
    xor -->|"slot B"| bL["Exp B only<br/>never enters Exp A"]
  end

Figure 1. Overlap: the same user can sit in A and B at once (combination cells). Layer: traffic is partitioned so a user is in at most one experiment in that domain.

The interesting decision is not “which religion?” It is: can these two treatments rewrite the same pixel or the same write path at once?

Symptom	Likely topology mistake
Two “wins,” one ugly product	Overlap on colliding surfaces (list chrome + CTA + ranking)
Every test underpowered; teams fighting for users	Everything forced into layers
Cumulative product drift nobody can measure	No holdout floor — everyone is always in something
Ghost variants on old APKs	Overlapping remote config on clients that only understand half the matrix

Where layers still earn rent on mobile

Colliding surfaces. List density, ranking, and compose CTAs are not independent knobs. Exclusive layers (or hard gates) keep ownership honest when two teams ship into the same screen.

Binary skew. Old APKs linger. Overlapping configs on clients that only know half the variants produce “impossible” combinations in telemetry. Layers plus version targeting cut that class of ghost.

Holdout floors. A small global holdout (often a few percent in org folklore) never enters a set of experiments so you can measure cumulative drift vs “everyone in everything.” That answers a different question than any single A/B — and it is easy to forget when overlap is the default pitch.

Overlapping remains the right default when interactions are rare, metrics are robust, and you can detect collisions. Layers are the circuit breaker when the product is one shared UI.

Topology does not fix missing exposure

Neither overlapping nor layers save the science if you never fire “user saw treatment T.” Sticky assignment, offline defaults, and no config fetch on the critical path still rule — then choose topology. Without exposure, you will ship another pair of “wins” that only look good because the dashboards never saw the combination users actually got.

For example, in a mail-shaped client, the dense-list + loud-CTA week is not a stats pedantry problem. It is a product incident caused by assignment topology. Fix the exclusion (or gate the ship) before you A/B a third chrome change on top.

References

Interaction detection
Tang et al. — Overlapping Experiment Infrastructure (KDD 2010) — layers as mutually exclusive domains so more tests share traffic
Kohavi, Tang, Xu — Trustworthy Online Controlled Experiments — interactions, SRM, and why isolation is not free

Tickets Where an Agent Makes You Slower

Wed, 08 Jul 2026 12:00:00 +0000

Prerequisites

Read these first if measured slowdown vs perceived speedup, assistant vs agent, or when not to use AI are new.

METR: early-2025 AI and experienced open-source developer productivity — measured ~19% slowdown vs believing you were faster
5 things to avoid when working with AI coding tools — scope, review burden, and context bloat
Building effective agents (Anthropic) — prefer the simplest system that works; agents are not the default

Negative expected value is allowed

Not every ticket deserves an agent. That sentence sounds obvious until you watch a team agent-wash a one-line string fix, a confidential design review, or a research spike with no acceptance criteria — then spend longer reviewing the diff than typing the change would have taken.

Coding agents are leverage under the right distribution of tasks. Under the wrong one they are a tax: prompting, waiting, auditing, and undoing confident mistakes. The METR randomized study on experienced open-source developers (early 2025 tooling) found participants took about 19% longer with AI on familiar repos — while still believing they were faster. Perception is not a ship metric. Expected value is.

Assistant vs agency

It helps to separate two products that share a chat box:

Mode	What it is	Failure cost
Assistant	Completions, local refactors, explain-this-stack-trace	Usually contained; you stay in the loop
Agency	Multi-file goals, PR bots, “just fix CI overnight”	Diffs and comments you must still own

An assistant speeds mechanical work when you can verify line-by-line. Agency needs a clear goal, a navigable repo, and a verifier — or it externalizes judgment while leaving you accountable. I wrote about assistant-style Compose UI as a UI/IME pattern: streaming bubbles, keyboard insets, stable list keys. This one is about when you should refuse agency on a ticket. Different layer; same word. Do not confuse a helpful panel with an unsupervised worker.

flowchart LR
  ticket[Ticket] --> ev{Expected value?}
  ev -->|high| agent[Agent with checks]
  ev -->|low| hand[Do it yourself]
  ev -->|unclear| spike[Time-boxed spike only]
  agent --> verify[Tests / review]
  spike --> decide[Promote or stop]

Figure 1. Default is not “always agent.” Route by expected value, then verify.

Negative-EV ticket shapes

Unclear product intent. “Make it feel premium” has no falsifiable done. An agent will invent UI and you will argue with a mirror. Write acceptance first (planning with teeth) or keep the work human.

One-line / known-locus fixes. Typo in a string, wrong constant, obvious NPE with a stack frame pointing at one method. The prompting overhead exceeds the edit. Use the agent as autocomplete if you want — do not open a multi-tool investigation.

Confidential or political review. Security-sensitive diffs, personnel issues, unreleased metrics, legal holds. Pasting context into a cloud agent can be a policy violation; even when allowed, you need a human who can swear to what shipped. Agency here is not speed — it is risk transfer theater.

Novel research with no oracle. Greenfield spikes where you do not yet know what “correct” means. Agents optimize for plausible completeness. You need exploration notes, not a PR that pretends the design exists.

Tasks where you are the expert and the suite is thin. On mature code you know cold, review cost dominates. METR’s setting — experienced developers on their own large repos — is exactly where “AI will 10× me” is most likely to lie. Thin golden evals help configs (ship bar ≠ demo); they do not erase the review tax on every ticket.

Rule of thumb - if explaining the task to the agent takes longer than doing it, you already have your answer.

Don’t agent-wash everything

Agent-washing is the organizational failure mode: every Jira ticket gets an agent run because leadership bought seats, or because “AI-first” is a performance narrative. Symptoms:

PRs with huge unrelated refactors the human did not ask for
Review queues full of bot comments nobody owns (public wrongness)
Engineers who cannot find the one-shot test command because the map was never written (navigable monorepos)

Seat utilization is not productivity. Track outcomes you already care about: cycle time to green CI, revert rate, review latency. If those worsen while agent usage climbs, you are paying for theater.

When agency is positive EV

Use agents hard when the work is bounded, checkable, and boring at scale: mechanical API migrations across many call sites, test scaffolding with a compiler as verifier, summarizing a failing CI log into a hypothesis you then validate, drafting a first-pass patch inside a module whose commands are documented. Pair with tests and path bans. Keep humans on intent, architecture, and anything that must be true in production — not on typing every rename.

Wrap-up

Refuse agency on unclear, tiny, confidential, or oracle-free tickets. Keep assistants for mechanical help you can audit in seconds. Measure yourself against wall-clock and reverts, not against how busy the sidebar looks. The mature move is not “AI everywhere” — it is knowing when the expected value is negative and closing the chat.

References

Ars Technica summary of the METR study — review/prompt/wait overhead eating coding-time savings
The bot commented on your PR and nobody owns it (this site) — review-queue tax from agent-washed tickets
Making a monorepo navigable to agents (this site) — missing command maps that turn agency into wandering

On-Device Agents Without the Mini Fantasy

Sat, 27 Jun 2026 09:15:00 +0000

Prerequisites

Read these first if on-device LLMs, edge vs cloud inference, or agent harness loops are new.

On-Device Language Models: A Comprehensive Review — why edge-cloud hybrids dominate wish lists (latency, privacy, cost)
Claude Code hooks — stop conditions and verifiers; the loop shape does not change on-device
Strengthen guardrails (Anthropic) — approvals and least privilege still bound tool blast radius
Langfuse — Evaluation overview — golden tasks beat a single local demo
Ollama — run a small local model with an OpenAI-compatible API shape (ops literacy, not a 70B goal)

You do not need a rack to learn agents

Every few months the feed invents a new reason to buy hardware: a Mac Mini forever-on host, a 70B at home, an NPU story that implies your laptop is obsolete. For learning how agents fail — false “done,” fat tool menus, rubber-stamp approvals, demo-only evals — that shopping list is a distraction. On-device and edge are wiring literacy: latency budgets, what stays on the phone, what works offline. They are not a prerequisite for understanding harnesses.

What actually changes on the device

Move the weights next to the sensors and three product constraints get louder:

Constraint	Cloud-shaped habit	On-device / edge habit
Latency	Round trip + queue	Local tokens; UI can stay interactive
Privacy	Ship context upstream	Keep PII / mailbox-adjacent text local when you can
Offline	Spinner or error	Degraded path that still does something honest

A mail-style assistant that suggests a reply subject while the radio is dead only works if something local can run. That is a real product reason. It is not the same claim as “I cannot study agents until I own a 70B.”

  phone / laptop                 cloud (optional)
  ┌─────────────────────┐        ┌──────────────────┐
  │ small model / NPU   │        │ frontier model   │
  │ tools + policy      │───────▶│ heavy tasks      │
  │ approvals + logs    │◀───────│ when policy OK   │
  └─────────────────────┘        └──────────────────┘
         harness loop identical either side

Figure 1. Placement of weights changes; the loop (goal → act → observe → stop) does not.

What does not change

Whether the brain is Claude in the cloud or a 7–8B via Ollama on a laptop:

Stop conditions still need exit codes, not chat tone (CI as done)
Approvals still gate irreversible tools; local does not mean trusted (trust boundaries)
Evals still need golden tasks you can re-run after a model bump (not a demo)
Tool menus still punish kitchen-sink defaults

Weaker local models make bad judgment more obvious. That is useful for labs. It is a poor excuse to skip the harness and blame parameter count. The day you move a policy check onto the device — “never upload draft body without an explicit toggle” — you will care more about where the gate lives than about whether the next token came from Sonnet or a quantized 8B.

A sane learning order

Cloud API + a hand-rolled loop (fake tools, fake CI) until “done ≠ green” is muscle memory
Thin tools and skills; measure thrash when you deliberately add junk
Optional: same prompts against a small local model to feel latency and quality cliffs
On-device / edge as a product topic when you have a latency, privacy, or offline requirement — not as gear acquisition

Step 3 is where people overspend. A 7–8B on a laptop already teaches timeout budgets, context limits, and “the model agreed but the tool never ran.” A Mini hosting a 70B mostly teaches thermals and electricity bills. Only one of those lessons transfers to shipping an Android feature that must not upload draft text.

The order is the point, not the silicon. Hardware becomes worth buying at the moment a latency, privacy, or offline requirement forces the weights local — and by then the question you are answering is which gate moves onto the device, not which parameter count fits in RAM.

References

AgentFlux — privacy-preserving on-device agentic systems — local orchestration with selective cloud collaboration
Edge-first AI agents (Petronella) — offline / private patterns without treating hardware as the curriculum
Building effective agents (Anthropic) — start simple; add complexity when measurement demands it

Making a Monorepo Navigable to Agents

Fri, 12 Jun 2026 12:00:00 +0000

Prerequisites

Read these first if AGENTS.md, rules, skills, or context engineering (what the agent can “see” in a repo) are new.

Cursor docs — Rules and AGENTS.md — root and nested agent instructions; glob-scoped project rules
Effective context engineering for AI agents (Anthropic) — curate high-signal tokens; avoid stuffing the whole monorepo into every turn
AGENTS.md vs CLAUDE.md vs Cursor rules — portable repo docs vs always-on editor rules
Cursor — Skills — on-demand workflows (verify commands, “add a screen”) without a 10k-token root file

Agents fail on layout, not IQ

Watch an agent on a large Android tree long enough and a pattern shows up. It invents a :app:assemble flavor that does not exist. It “fixes” a crash by editing files under build/ or generated/. It runs the root unit-test task that the team abandoned two years ago because it takes forty minutes and flakes. Then it declares done. The model was not uniquely dumb that day — the repo was illegible to tools that only know what you wrote down.

Intelligence without a map wastes tokens. The job is to make the monorepo reachable: one-shot commands, explicit forbidden paths, module boundaries in prose short enough to load — not a 10k-token novel nobody maintains.

This pairs with how we think about CI for Android: if humans need a pinned JDK and a real pipeline command, agents need the same, discoverable in one hop.

What “navigable” means

An agent (or a new hire) should answer these without archaeology:

Question	Bad answer	Good answer in-repo
How do I unit-test module X?	“Gradle somewhere”	`./gradlew :feature-mail:testDebugUnitTest`
What is generated?	Silence	`build/`, `Generated`, Room/Schema folders — do not edit
Where does feature Y live?	Search the universe	Module map: feature → Gradle path → owners
What must never ship from chat?	Vibes	Secrets paths, Play keys, internal metric names

If those answers live only in Slack lore, every agent session relearns them wrong.

flowchart TB
  root[AGENTS.md — commands + bans]
  root --> feat[feature-mail/AGENTS.md]
  root --> shared[core-ui/AGENTS.md]
  root --> rules[".cursor/rules — glob-scoped"]
  feat --> cmd["./gradlew :feature-mail:testDebugUnitTest"]
  shared --> ban[Do not edit build/ or generated]
  rules --> compose[Compose rules on ui/**]

Figure 1. Thin root instructions; nested playbooks and glob rules for local truth — not one giant always-on essay.

One-shot commands beat narrative

Put the commands you actually run in CI near the top of AGENTS.md (or equivalent). Prefer copy-paste lines over paragraphs:

# Module unit tests (PR gate shape)
./gradlew :feature-mail:testDebugUnitTest

# Static analysis the team enforces
./gradlew :feature-mail:detekt

# Do not: ./gradlew test  (root suite — slow, not the PR gate)

Agents pattern-match on executable snippets. A sentence that says “run the appropriate module tests” invites improvisation. The same discipline belongs in skills and runbooks for recurring workflows: “add a Compose screen in :feature-X” should list files, packages, and the verify command — Medium Engineering’s Android skills writeup makes that case well for team playbooks.

Generated folders look editable

To a model, FooDto_Impl.kt is just another Kotlin file with a helpful name. Your rules must say do not edit generated sources and name the directories. Pair that with harness checks if you evaluate agents: a golden task that fails when build/ appears in the diff (eval as ship bar).

Also call out:

local.properties / signing material — read-only or out of bounds
Screenshot and goldens folders — update only via the approved test task
Vendored or generated GraphQL/Apollo sources — regenerate, do not hand-patch

AGENTS / rules without a 10k novel

Always-on context is a budget. A 10k-token root file that restates Clean Architecture will be half-ignored and half-overfitted. Split by job:

Root AGENTS.md — setup, global bans, canonical commands, link to module map
Nested AGENTS.md — per feature or package conventions that apply when working in that subtree
Glob-scoped rules (e.g. Cursor .mdc) — Compose, ViewModel, or test patterns that attach only when matching files are in play
On-demand skills — multi-step runbooks loaded when the task matches, not on every chat

The point of the split is that the model gets the right playbook at the right time instead of one always-on essay. Cursor’s docs for rules and AGENTS.md match that shape: portable repo instructions plus scoped overrides.

Rule of thumb - if a paragraph has not prevented a real wrong edit in the last quarter, cut it; agents do not need your manifesto.

Module boundaries on paper

Large mail-style clients are graphs of Gradle projects. Write a short module map: feature name, Gradle path, what it may depend on, what must not depend back. Agents routinely “help” by introducing a dependency cycle or reaching into another team’s internals because the graph was implicit. You do not need a full architecture book — a table and a “preferred public API packages” line save more thrash than another essay on MVVM.

Wrap-up

Make the monorepo legible the way you make CI honest: one-shot commands, named forbidden paths, thin always-on rules, deeper playbooks on demand. Agents are not lost because they lack a bigger model; they are lost because the map was never checked in. Fix the map first — then judge the model.

References

Making AI write Android code our way — AGENTS.md + skills on an Android codebase; move weight into scoped rules
Cursor rules vs AGENTS.md — portable commands/gates vs editor-scoped behavior

Docker and Kubernetes: How Backend Servers Actually Run

Fri, 05 Jun 2026 14:00:00 +0000

Prerequisites

Read these first if containers, Pods, Services, or the hostname the phone calls are new.

Docker overview — images as the repeatable process the phone never runs itself
Kubernetes overview — how a fleet of those images stays up
Pods — the running process(es) behind one replica
Service — stable name/IP the app actually calls
Deployments — replica count and rolling updates

The phone never runs Docker. It calls something that does.

A mail or chat Android client talks HTTPS to a hostname baked into the build (or fetched from config). That hostname is not “Kubernetes” and not “a Docker daemon.” It is a backend process — usually several of them — packaged as images and kept running across machines.

Docker is how that process becomes a repeatable image: same bits on a laptop, in CI, and in staging. Kubernetes is how a fleet of those images stays up: how many copies, how they roll, what name the app calls, what happens when a node dies. Build with one; run the production shape with the other.

For a mobile service, the useful question is not whale vs helm. It is which backend jobs the app depends on, and which of those jobs live in the cluster.

The mobile-facing backend is several jobs

The app’s critical path is mostly one kind of process. The cluster is not.

Kind	What it does for the mobile app	How it usually runs
API / BFF	HTTPS the app actually calls. BFF (Backend for Frontend) is an API shaped for one client — e.g. a mobile BFF that aggregates list/send/auth so the phone does not fan out to five services	Replicas behind a stable name; roll out gradually
Downstream services	Mailbox, identity, attachments — the BFF fans out here	Same cluster or another; the phone should not know
Worker	Send, index, push fan-out, thumbnails — work that must not sit on the tap	Scale on queue lag, not on HTTP QPS
Job / Cron	Backfill, cleanup, replay failed sends	Run to completion; not a forever replica
Agent	Node collector (metrics, logs, traces) — e.g. a Datadog agent talking to Datadog’s intake	One per node (or a sidecar); outbound, not a hostname the app calls

Docker’s job is the same for all of them: this image is the process. Kubernetes’s job differs by shape: a Deployment + Service for anything the phone hits; workers without a public hostname; Jobs that exit; agents as a DaemonSet so every machine is observed.

flowchart TB
  phone[Mobile app] -->|HTTPS| edge[Service / ingress]
  edge --> bff[Mobile BFF / API pods]
  bff --> ds[Downstream services]
  bff --> q[Queue]
  q --> w[Worker pods]

Figure 1. The app calls one name. Kubernetes keeps BFF replicas behind it; workers and downstream services do the rest of the product. Node agents (not shown) scrape those boxes — they are not on the request path.

For example, in a mail app, opening the inbox should be BFF → mailbox metadata → a payload the list can paint. Tapping send should return fast; SMTP and push fan-out belong on a worker. That split is why the request path should never wait is an ops shape as much as an API slogan. A fat mobile payload is cheaper on cellular when the BFF does the join in the cluster, not on the radio.

How Docker and Kubernetes show up in that path

Same image, three places. CI docker builds the BFF, tags it, pushes a registry. A developer runs the same image with Compose (BFF + Redis + stub auth) and points a debug APK at 10.0.2.2. Staging and prod pull the tag onto N pods. When “works in Compose” and “fails on device against staging” disagree, the image is often fine — ingress, secrets, and real dependencies are not in the laptop YAML.

The name the app already has. Kubernetes puts a Service (and usually ingress/TLS) in front of BFF pods so the APK does not chase pod IPs. Rolling a Deployment replaces pods gradually. For a minute, some phones hit the new tag and some hit the old one. Aggressive client retries turn that into a hang; the cluster looks “mostly green.”

Environments are different fleets. Namespaces or clusters are how staging vs prod exist. A dogfood build pointed at the wrong Service looks like an Android sync bug. The backend change was a base URL.

Workers are the rest of the product. They share the cluster and often the same repo as the BFF, with a different command. They must not sit on the hostname the phone uses. Scale them on queue depth. If send is slow, look at worker lag before rewriting the compose screen.

Agents watch the fleet. A node agent — Datadog, Fluent Bit, a Prometheus exporter — is another container, usually one per machine, shipping telemetry to an intake. Scaling the BFF to 20 replicas does not mean 20 collectors. If the agent cannot reach intake, dashboards go dark while the app still gets 200s. Useful, easy to over-index on; it is not the mobile API.

Rule of thumb - Docker answers “what binary is this backend process?” Kubernetes answers “how many, where, and under what name does the app call it?” For a mobile service, start with the BFF hostname, then workers, then collectors.

The APK is a client of that hostname. Docker and Kubernetes are how the servers behind it get built and kept alive — not a choice the phone makes, and not a rivalry between two logos.

References

Wrong Chunk, Confident Answer

Sat, 30 May 2026 11:00:00 +0000

Prerequisites

Read these first if RAG, chunking, embeddings, or knowledge bases are new.

Chunking strategies (Pinecone) — how you slice the corpus; wrong boundaries → wrong top-k
What is RAG? (AWS) — retrieve from an authoritative corpus, then generate
Lewis et al. — RAG for Knowledge-Intensive NLP Tasks (NeurIPS 2020) — original paper that named the pattern
Effective context engineering for AI agents (Anthropic) — retrieved (or repo) context competes for the same attention budget
Understanding RAG (AWS Prescriptive Guidance) — embeddings, vector store, retrieve → augment → generate

The wiki answered. It was last year’s policy.

A teammate asks the internal assistant how long retention is for deleted drafts. The bot cites three passages, names a doc title, and answers with a round number. Legal’s real page was updated last quarter. The chunks that ranked highest were an old FAQ and a neighboring section about sent mail. Nobody lied in the prompt. Retrieval ranked the wrong slice of a knowledge base, and generation did what generation does: sound finished.

That is the everyday failure mode for RAG — retrieval-augmented generation. The terms are inseparable in practice: a knowledge base is the corpus you maintain (wikis, runbooks, PDFs, ticket dumps); RAG is the pattern that searches that corpus at query time, stuffs passages into context, and lets the model write. Lewis et al. popularized the recipe in 2020; production teams rediscover that the generator is only as honest as the top-k you feed it.

Knowledge base first, then the pipeline

Call the asset what it is before you buy an embedding product.

Piece	Job
Knowledge base	Owned documents with freshness, permissions, and a clear “source of truth”
Index / chunks	How you slice and embed those docs for search
Retriever (+ optional rerank)	Which chunks enter the prompt
Generator	The LLM that answers conditioned on those chunks

flowchart LR
  q[Question] --> r[Retrieve from KB]
  r --> c[Top-k chunks]
  c --> g[Generate answer]
  g --> a[Reply + citations]

Figure 1. RAG is search-then-write over a knowledge base — not a smarter model that “remembers” your wiki.

If the KB is a graveyard of contradictory Confluence pages, RAG will amplify the loudest stale page. Ownership matters as much as embeddings: who retires superseded runbooks, who can publish, and whether the index lags the wiki by hours or by quarters. Chunking that splits a definition from its exception produces the confident wrongness that RAG failure taxonomies keep rediscovering: boundary errors, off-topic hits, and distractors that dominate the prompt while the answer-bearing span sits one chunk away.

For example, in a mail app help center, “deleted drafts” and “deleted messages” often live in adjacent articles. A fixed-size split can put the retention number in chunk A and the product caveat (“drafts vs sent”) in chunk B. The retriever returns A because the query shared more tokens with the FAQ title. The model cites A and invents confidence. Users experience a policy answer; you have a ranking bug.

Rule of thumb - debug the ranked passages before you blame the model. If the gold paragraph never entered the prompt, no prompt tweak fixes the product.

Two products people confuse

Docs / support Q&A needs a maintained knowledge base and a retrieval stack you can evaluate: Did the right passage appear? Can the user open the cite? Stale sync and bad ACLs are product bugs, not “LLM vibes.”

Coding agents already live inside a different knowledge base: the repository. For “which Gradle task gates PRs?” or “where is the Compose list adapter?”, the honest path is usually rg, a module map, and thin AGENTS / skills — the same discipline as context that must stay durable. Standing up a vector index of every .kt file because “we need RAG” often buys approximate neighbors when exact path search was the requirement. Similarity search shines on prose handbooks; it is a poor substitute for a checked-in verify command.

Need	Prefer
Policy / FAQ / handbook answers with citations	KB + RAG (and freshness SLO)
“Where is this symbol / module / verify command?”	Repo tools + navigable monorepo
Mixed: “how does our send pipeline work?” in prose runbooks	RAG over owned architecture docs — not raw `build/` trees
Agent must not invent APIs	Skills and rules in the harness, not a similarity search over Slack

Embeddings are great at “find something like this paragraph.” They are mediocre at “open the file the build actually uses.” Treat that as an architecture choice, not a fashion cycle.

What to measure when chat looks green

Demos fail the same way coding agents fail when chat says done and CI is red (harness verifiers): the UI is fluent while the gate is missing.

For a KB + RAG path, cheap checks beat vibes:

Retrieval hit — for a golden question set, is the answer-bearing chunk in top-k?
Freshness — does the index lag the wiki by hours or by quarters?
Citation honesty — does the cited doc actually support the sentence, or is it decorative?

Generation-only scores hide “right document, wrong page” failures that show up in long manuals and mail-style help centers: the retriever found the family of pages and still missed the paragraph that changed last release.

Wrap-up

A knowledge base is the corpus you own; RAG is retrieve-then-generate over it. They belong in one mental model because the popular bug is joint: wrong chunk in, confident answer out. Build RAG when answers must track a living document set with provenance. For coding agents, invest in a legible repo and harness context first — and only add retrieval when the question is genuinely “search the handbook,” not “find the module.”

References

Why the Chunking Problem Isn’t Solved — boundary splits and naive fixed-size chunks in production
A Systematic Taxonomy of Failure Modes in RAG — retrieval vs fusion vs generation failures
Classifying Errors in RAG Systems — missed retrieval, low relevance, partial evidence

Chang Min Park

Who Picks the Next Step: Loops vs Graphs

The wrong question

Two words, four jobs

Loop vs graph

Layers, not a ladder

So when do I draw edges?

References

The Rule the Other Agent Never Saw

Why the same checkout disagrees

.mdc is not .md

The rest of the harness splits too

Keep one prose file, thin adapters

References

You Can't Delete Claude's Watermark With a Remover

The wrong mental model of “delete”

How the mark gets into the prose

Removers do not delete — rewrites replace

A positive hit is not authorship court

References

When GitHub Actions Is the Outage

It was not your Gradle cache

What actually broke (from the public timeline)

Why this hurts Android merge queues specifically

What to do while it is red

What not to conclude

References

Experiment Layers vs Overlapping on Mobile

This A/B ate that A/B

The wrong fight: “overlap is modern, layers are legacy”

Where layers still earn rent on mobile

Topology does not fix missing exposure

References

Tickets Where an Agent Makes You Slower

Negative expected value is allowed

Assistant vs agency

Negative-EV ticket shapes

Don’t agent-wash everything

When agency is positive EV

Wrap-up

References

On-Device Agents Without the Mini Fantasy

You do not need a rack to learn agents

What actually changes on the device

What does not change

A sane learning order

References

Making a Monorepo Navigable to Agents

Agents fail on layout, not IQ

What “navigable” means

One-shot commands beat narrative

Generated folders look editable

AGENTS / rules without a 10k novel

Module boundaries on paper

Wrap-up

References

Docker and Kubernetes: How Backend Servers Actually Run

The phone never runs Docker. It calls something that does.

The mobile-facing backend is several jobs

How Docker and Kubernetes show up in that path

References

Wrong Chunk, Confident Answer

The wiki answered. It was last year’s policy.

Knowledge base first, then the pipeline

Two products people confuse

What to measure when chat looks green

Wrap-up

References

`.mdc` is not `.md`