DEV Community: Andrea Liliana Griffiths

An agent loop that stops itself

Andrea Liliana Griffiths — Wed, 24 Jun 2026 10:28:20 +0000

Can you trust what AI writes? And what does it cost to find out? Those are the two honest questions about AI coding, and everyone's loud about both. What I haven't heard much of is that they're the same question. You solve them with one design.

The bias case is the familiar one. A model is trained on a skewed slice of the world, the output inherits the skew, and you can't fully trust it. All true. None of it means you stop, though. It means you stop leaning on one model alone. Run a few, let them check each other, and the thing one model is blind to is usually something another one catches.

And that fix is exactly what makes cost the second question. Two models cost more than one. Three agents talking to each other cost more than three working alone, and a loop nobody is watching costs whatever it feels like. So you're solving two problems with one design: get enough disagreement to catch the errors, and stop that disagreement from running up a bill you never agreed to. Building the verification and capping it turn out to be the same job.

Three tools do this at different scales, including one I built myself.

opencode-fusion: a panel that argues, then a judge

opencode-fusion is Samir Patil's (@sampatil1010) local take on OpenRouter's Fusion (@OpenRouter): run one task across a panel of models at once, then resolve their disagreement instead of averaging it away. The default panel is Sonnet, GPT, and GLM, defined as a bash array you edit to add or drop models. They run in parallel through the OpenCode CLI, each output written to its own temp file. Failures get noted but don't abort the run.

Then a judge model reads all the outputs and writes a structured report: where the models agree, where they contradict each other and which side is likely right, what every model missed, and what looks risky. A synthesizer takes the original task, the judge's report, and the raw outputs, and produces the single answer you actually see.

You invoke the whole thing with one line:

bash run_fusion.sh "<TASK>"

The parallelism is the boring part. What you're actually buying is the disagreement. When two models land on the same answer and a third wanders off somewhere else, that gap tells you something a single confident response never would. The judge does the reading. You get one answer instead of three transcripts.

agmsg: agents that message each other

opencode-fusion is one-shot. Ask, the panel answers, done. Sometimes you want the models to go back and forth instead. That's agmsg, by @fujibee.

agmsg lets CLI agents message each other through a shared SQLite file. No daemon, no network, just bash and sqlite3, installed as an agent skill. It's cross-vendor, so Claude Code, Codex, Gemini CLI, and Copilot CLI can join the same team and pass messages. And the messages persist, which is what separates it from the alternatives. A built-in subagent is ephemeral and locked to its parent's vendor. MCP is one agent reaching for tools. agmsg is a different shape: independent agents, different models, talking to each other over a durable channel.

Install is a one-liner:

bash <(curl -fsSL https://raw.githubusercontent.com/fujibee/agmsg/main/setup.sh)

After a restart the agents get a command (/agmsg in Claude Code and Copilot CLI, $agmsg in Codex and Gemini CLI), pick a team and a name, and start talking.

One thing to know before you wire it into anything: agmsg is deliberately dumb. It moves messages and nothing more, so two over-polite agents will happily clarify at each other until your token bill looks like a phone number. Whatever ends that loop has to come from you.

What I built

I wired agmsg into a small bridge that watches the shared inbox and delivers messages between three agents automatically. No human relaying anything between them.

The bridge does one job. It polls the SQLite inbox every four seconds with a SELECT for unread rows, then hands each one to its target agent. No file watcher, nothing clever, just a loop and a query.

The three agents sit on one team, and none of them run the same way. One runs through a CLI with its model set in a local config file, one runs as a one-shot command, and one answers over an HTTP API. Each is pinned to a different model, and that model lives in the agent's own config, not in the bridge. The bridge doesn't know or care which model is on the other end of a message, and that's the point: I can swap any agent's model without touching the thing that moves the messages.

The reason for three different models was never that agents can talk to each other. It was that when one of them got something wrong, a model trained on different data was already sitting there to catch it.

That only holds as far as the models are actually independent. Two trained on mostly the same text share the same blind spots, and when they do they'll agree on a wrong answer as fast as a right one, so the disagreement I'm counting on never shows up. Spanning vendors (gpt-4.1, Sonnet 4.6, and one of my own) buys more independence than three versions of one model would, but it's a hedge, not a guarantee.

The bridge itself is small, a poll loop and the set of guards below. I'm cleaning it up to open-source it soon.

Keeping it from eating itself

agmsg won't stop two agents from clarifying at each other forever. A runaway loop here burns real money, fast, so the containment is all on the bridge. Four guards, each for a different way it goes wrong.

Two sliding-window counters, both over a 300-second window. One caps total dispatches at 12 per window. The other caps bot-to-bot hops at 6 per window, since that's the exchange that runs away: two agents answering each other with no human around to get bored and stop it. When either limit trips, the message is dropped and logged, never retried. A dropped message is cheaper than a loop.

Then a per-agent in-flight lock, so each agent handles one turn at a time and can't be stacked with new work while it's still thinking. And wall-clock kills per agent, set to how slow each one is allowed to be: 280 seconds, 150, and 120. A hung turn dies on the clock instead of holding the lock forever.

Not a token budget. The counters and the clocks bound the cost indirectly, and they're easier to reason about than a dollar figure I'd have to keep recalibrating.

/orchestrate: the same idea with a UI

If you don't want to build the plumbing yourself, the GitHub Copilot app does a version of this at a higher level. /orchestrate turns the main session into a coordinator: it spins up child sessions, gives each one its own branch and task, and lets them report back while the main session steers and summarizes. One session, one branch, one PR. Each runs in its own git worktree, so they aren't editing the same files out from under each other, and you pick the model per session.

Same idea as the bridge, just managed for you: several agents, different models, kept from stepping on each other. You give up the fine control you'd get from building it yourself, and in return you don't have to maintain any of it.

None of these tools pretend any single model is right. They assume it'll be wrong sometimes, build the check into the workflow, and keep the check cheap.

That's the whole move. "The model is biased" and "it's too expensive to run" get treated as reasons to wait. They're not. They're two sides of one design problem, and the fix reads the same from either side: run more than one model, let them disagree where they were going to disagree anyway, and put something in the path that reads the disagreement so you don't have to. The cap is what keeps it honest. Reading the disagreement should never cost more than the bug it catches.

A note before you go build this. Everything here is what I've used, shared as is. It's not vetted for your setup, and I can't vouch for the security of tools I didn't write. Read the code, test it somewhere safe, and decide for yourself. Useful to me isn't the same as safe for you. That part's on you to check.

Originally published on X.

Stop paying for the same tokens twice

Andrea Liliana Griffiths — Fri, 19 Jun 2026 14:04:04 +0000

I ran five reviewer agents over a 16K-token PR. The naive setup cost $1.32. Two architectural changes brought it to $0.49. Here's the bill, and what the experiment surprised me with along the way.

Five specialist agents reviewed the same pull request. Security, tests, perf, observability, API design. Each one re-read the full diff. Each one paid full price. The bill landed at $1.32 for a single PR pass on Claude Opus 4.6.

One PR. One review pass. Buck thirty-two.

If you're running multi-agent code review at any scale, you're bleeding money on the exact same tokens, over and over, paid in full each time.

I built a harness to measure the bleed and test the two obvious fixes. The numbers were sharper than I expected, and one of them inverted my assumptions about prompt caching.

What I built

A small Python harness with three modes and one shared 49K-character pull request diff. Five reviewer roles, each with a tight system prompt:

REVIEWER_ROLES = {
    "security":      "Auth, injection, secrets, access control...",
    "tests":         "Missing tests, skipped tests, weak assertions...",
    "perf":          "N+1 queries, sync I/O in request paths...",
    "observability": "Logging hygiene, error handling, missing metrics...",
    "api-design":    "Endpoint naming, status codes, idempotency...",
}

Three modes against the same diff:

Naive. Each reviewer makes its own call with the full diff in the user message. Role text comes first so the prefix differs per call. Nothing gets cached.
Cache. Each reviewer puts the diff in the system message, identical across all five calls. The first call writes to the provider's prompt cache. Calls two through five read from it at a 90% discount.
Librarian. A first pass digests the diff into a compact JSON summary. Reviewers run against the digest, not the raw diff. Inspired by Cho et al.'s arXiv paper Long Live the Librarian!, which uses a persistent search sub-agent to suppress redundant exploration tokens across agents.

I priced every call at Anthropic's API list rates: $15/M input, $1.50/M cache reads, $75/M output. Real measured token counts, list-price arithmetic on top.

The numbers

Large diff (49K characters, roughly 16K tokens per call), five reviewers, single fresh review pass:

Mode	Input	Cached	Output	Total
Naive	80,248	0	1,500	$1.316
Cache	80,268	63,968 (4/5 calls)	1,500	$0.453
Librarian	20,915	0	2,300	$0.486

Naive is comically wasteful. Cache and librarian both cut it by roughly two thirds.

Cache edges librarian by three cents. That's real, and it changes how I think about which lever to pull first.

When caching actually beats the librarian

Caching wins on a warm series. The first call writes to cache, the next four read from it. If you can guarantee five reviewers run back-to-back against the same shared prefix in the same warm session, prompt caching is the cleanest move you can make. Two-line system message refactor. 66% off the bill.

The problem: code review bots almost never run that way in production.

Each PR is a fresh session. PRs come in from different developers, different repos, different branches, at unpredictable intervals. There's no "warm series." There's a parade of cold starts.

When every call is cold, cache mode collapses back to naive mode. Same dollars per call. Same bleed.

The librarian pattern doesn't care whether the session is warm or cold. Each reviewer reads a tiny digest, not the raw diff. The savings are baked into the shape of the calls, not the runtime state of a cache somewhere in the provider's fleet.

Mode	Warm series (5 calls back-to-back)	Cold every call (operational reality)
Naive	$1.32	$1.32
Cache	$0.45	$1.32
Librarian	$0.49	$0.49

If your reviewers run in tight bursts inside a single session, cache. If they run independently across cold starts, use the librarian. Most real systems are the second kind.

What surprised me about caching

I built the harness with a fail-loud guardrail. If calls 2 through N in cache mode report zero cached tokens, the harness aborts and prints diagnostics. The cached prefix should hit, and if it doesn't, the experiment is invalid.

It tripped twice on the small-diff run.

Same code, same five-call sequence, same identical system message at 4,003 tokens. Both runs returned cached_tokens=0 for every single call. Cache mode and naive mode came in at the exact same $0.413, to four decimal places.

Then I ran the large diff at 16,000 tokens per call. Four out of five calls hit the cache cleanly. 15,992 cached tokens each.

So somewhere between 4K and 16K tokens of identical prefix, against claude-opus-4.6 through the Copilot proxy with an OpenAI-shape request, prompt caching activates. Below that threshold, it doesn't. The Anthropic docs say the minimum is roughly 1024 to 2048 tokens. Empirically, the activation curve is not flat.

If you're budgeting on a stated cache discount, model your hit rate as a band. Run the experiment on your actual payload sizes. Don't assume the marketing math holds for the call shapes you're actually making.

Try it yourself

The full harness lives at github.com/AndreaGriffiths11/librarian-demo. Three Python files, one diff scenario, one pricing module. Run it with:

export COPILOT_OAUTH_TOKEN=$(sqlite3 ~/.copilot/data.db \
  "SELECT access_token FROM github_accounts WHERE is_default=1;")

python demo.py all --verbose --diff scenario/sample_pr_large.diff

If you have the GitHub Copilot CLI installed, you already have an OAuth token sitting in ~/.copilot/data.db. Point the OpenAI SDK at https://api.githubcopilot.com with the Copilot-Integration-Id: copilot-cli header and you get the full model catalog (Anthropic, OpenAI, Google) on the chat-completions shape, with prompt_tokens_details.cached_tokens reporting. No PAT, no token exchange. About 30 lines of glue:

import sqlite3, pathlib
from openai import OpenAI

con = sqlite3.connect(
    f"file:{pathlib.Path.home()}/.copilot/data.db?mode=ro", uri=True
)
token = con.execute(
    "SELECT access_token FROM github_accounts WHERE is_default=1"
).fetchone()[0]

client = OpenAI(
    base_url="https://api.githubcopilot.com",
    api_key=token,
    default_headers={"Copilot-Integration-Id": "copilot-cli"},
)

One billing note: GitHub Copilot moves to usage-based billing on June 1, 2026. Under the new model, token consumption maps directly to GitHub AI Credits at Anthropic's published API rates, so the dollar figures in this article apply to Copilot users now too, not just people hitting the API directly. The architectural takeaway is the same either way. If you're on a paid Copilot plan, these savings are real dollars out of your monthly credit allotment.

What I'd actually ship

If I were rebuilding a review pipeline tomorrow with this data on the table:

Move all shared context into the system message. It's the cheapest refactor in software, and it costs you nothing when the cache doesn't activate.
Build the librarian pass once you cross three reviewers, or once your shared context is large enough that the activation threshold actually kicks in. The digest pays for itself across cold sessions.
Stop treating cache hit rate as a constant. Measure it on your payloads, in your environment, against the model you ship with. Write a fail-loud guardrail and let it scream when assumptions break.

Cho et al.'s paper measures GPU energy savings on SWE-Bench Verified, up to 25% on multi-agent runs. My harness measures wall-clock dollars on one PR review pass. Different proxy, same lesson: persistent shared context across agents is a free architectural lever sitting on the floor.

Paper: Cho, Choi, Heo, Choi. "Long Live the Librarian! A Persistent Search Sub-Agent for Energy-Efficient Multi-Agent Software Engineering Systems" (arXiv:2605.27787, May 2026).

All numbers measured against claude-opus-4.6 via the GitHub Copilot proxy on May 29, 2026. Full per-call breakdowns and the harness source live in the runs/findings.md of the repo.

I Gave My Newsletter a Voice (Literally)

Andrea Liliana Griffiths — Sat, 09 May 2026 10:48:10 +0000

I Gave My Newsletter a Voice (Literally)

My newsletter site has a chat widget now. You type a question, it searches through every issue I've ever written, and gives you an answer with sources.

That took an evening. Cool, but not interesting enough to write about.

What made me write this: I added a microphone button next to the text input. Click it, and you're in a real-time voice conversation with an AI agent that knows my content. You talk, it listens, it talks back. Not a recording. Not text-to-speech over a chat response. An actual voice conversation.

The stack behind it is LiveKit, and I want to walk through how it works because it's simpler than I expected.

What LiveKit Actually Does

LiveKit is real-time communication infrastructure. Think "Zoom but programmable." It handles all the WebRTC complexity — rooms, audio routing, codecs, latency optimization — so you don't have to.

The part that matters for AI voice agents: LiveKit has an agent framework. You write a Python worker that connects to their cloud service and waits. When a user joins a room, LiveKit dispatches your agent into that room. The agent listens to the user's microphone, processes speech, thinks, and talks back. All in real time.

The latency is wild. It feels like talking to someone, not waiting for a computer.

The Architecture

Three pieces:

The API — A FastAPI server that handles text chat (RAG search over my newsletter content) and generates LiveKit room tokens when someone clicks the mic button.

The voice agent — A Python worker running LiveKit's agent SDK. It connects outbound to LiveKit Cloud and waits for rooms. When someone joins, it gets dispatched. Inside the agent: voice activity detection (Silero VAD), speech-to-text (Azure Speech Services), an LLM (GPT-4.1-mini via GitHub Models), and text-to-speech (Azure Speech Services). Azure handles both ends of the voice pipeline — turning your speech into text the LLM can understand, then turning the LLM's response back into natural-sounding speech. Before every response, it searches my knowledge base for relevant context — same RAG pipeline the text chat uses.

The frontend — An Astro component with a mic button. Clicking it loads the LiveKit client SDK, requests a room token from my API, and connects to the room via WebRTC. The agent joins, and they're talking.

Both the API and the voice agent run in a single Railway container. A bash script starts both processes — if either dies, the container exits and Railway restarts it.

The RAG Part

Every time the user says something, the agent:

Transcribes the speech — Azure Speech Services converts your voice to text in real time
Embeds the transcript using GitHub Models API (text-embedding-3-small, 1536 dimensions)
Searches a SQLite vector database (sqlite-vec) for the most relevant newsletter chunks
Rebuilds the system prompt with fresh context
Generates a response (GPT-4.1-mini via GitHub Models)
Speaks it back — Azure Speech Services (en-US-JennyNeural voice) converts the text response to natural-sounding speech

This happens per utterance. The agent's knowledge stays current with whatever the user is asking about, not stuck on whatever the first question was.

The hybrid retrieval trick: Vector search alone can't answer "what's the latest issue?" because semantic similarity doesn't understand ordering. The solution: at startup, the agent queries the database for all newsletter issue URLs, extracts the numbers, and injects a content index into every system prompt:

Available newsletter issues: issue-1, issue-2, ..., issue-20
The latest/most recent issue is issue-20
Total issues: 20

Now the LLM gets both semantic context from vector search and structural metadata it can't learn from embeddings. Ask "what's the latest issue?" and it knows. Ask "tell me about GitHub Copilot" and vector search finds the right chunks. Hybrid retrieval.

Why Azure Speech Services?

The voice pipeline has two critical pieces where quality matters:

Speech-to-text accuracy. If the transcription is wrong, the whole conversation breaks. Azure Speech Services gives me high-accuracy transcription with low latency — critical for real-time voice. It handles accents, background noise, and technical terminology better than the alternatives I tested.

Natural-sounding TTS. Azure's neural voices sound human. Not robotic, not uncanny valley. The "en-US-JennyNeural" voice I use for the agent has natural pacing, intonation, and emotion. When the agent says "Let me search my knowledge base for that," it sounds like a person helping you, not a computer reading text.

Streaming support. Both Azure STT and TTS support streaming. The agent starts transcribing as you speak (no waiting for you to finish), and starts speaking as soon as the first chunk of TTS audio is ready (no waiting for the full LLM response). This cuts perceived latency in half.

LiveKit integrates with Azure Speech Services out of the box via their plugins (livekit-plugins-azure). Configuration is straightforward — set your Azure subscription key and region, pick a voice, done.

What Surprised Me

LiveKit agents are workers, not servers. They don't listen on a port. They connect outbound to LiveKit Cloud and get dispatched into rooms. This threw me at first — I kept trying to think of it as another HTTP service. It's not. It's a background worker that happens to handle real-time audio.

The voice pipeline has real latency requirements. Text chat can take 2-3 seconds and nobody cares. Voice? If there's a 2-second gap after someone finishes talking, it feels broken. LiveKit's streaming architecture handles this — the TTS starts speaking before the full LLM response is complete.

sqlite-vec is underrated. I'm running vector search in SQLite. No Pinecone, no Weaviate, no managed vector database. For a knowledge base of ~130 newsletter chunks (all 20 issues, articles, and GitHub blog posts), this is more than enough. The query takes single-digit milliseconds. Embeddings come from GitHub Models API during ingestion — free during preview, high quality (text-embedding-3-small, 1536 dims), and no local model loading headaches.

Debugging production is different. The voice agent worked locally but failed silently in Railway. The agent would listen, transcribe perfectly, but always respond with "I don't have that information." Turned out the embeddings API was returning 400 errors because an old environment variable (LIVEBRAIN_EMBEDDING_MODEL) was still set to a local model name (all-MiniLM-L6-v2) that the API didn't recognize. The fix: delete the variable and let it default to text-embedding-3-small. Real-time logging made this visible — without print() statements showing chunk retrieval counts and similarities, I would have been guessing for hours.

What's Next

I'm extracting the reusable parts of this into an open-source framework. The idea: point it at a YAML file with your content sources, run an ingestion script, and you get a voice agent that knows your stuff. Newsletter, documentation, blog — whatever you feed it.

It's not ready yet. The mainbranch-agent version works, but the generic framework needs cleanup before anyone else can use it. I'll open-source it when it's actually good, not when it's "minimum viable."

If you want to see it in action, go to mainbranch.dev and click the chat bubble. The mic button is right there.

Debug GitHub Actions from Your Terminal with gh

Andrea Liliana Griffiths — Sat, 09 May 2026 10:44:56 +0000

Debug GitHub Actions from Your Terminal with `gh`

If your GitHub Actions debugging workflow starts with opening three browser tabs, it is probably slower than it needs to be.

Most CI failures do not require the Actions UI at all. The gh CLI gives you the core loop from your terminal: find the broken run, read the failure, retry it, and watch it live. Once you get used to it, going back to the browser feels clumsy.

Find the run

gh run list --limit 10

Start here. This shows recent runs, their status, and what triggered them.

If a workflow has been stuck in queued forever, you will see it immediately. If you want to script against the output, add --json and skip the copy-paste routine entirely.

Read only what failed

gh run view <run-id> --log-failed

This is the command I was missing.

You do not always need the full log dump. You usually need the failing step. --log-failed cuts straight to the useful part, which matters a lot once your workflow grows past a handful of jobs.

If you do need everything, switch to --log. If you are debugging a matrix build, pipe the output into grep and keep moving.

Retry only the broken part

gh run rerun <run-id> --failed

This reruns only the jobs that failed, plus anything they depend on. That is usually what you want.

If the failure came from a flaky test, a registry timeout, or some other transient CI nonsense, rerunning the entire workflow is just wasted time and compute.

One gotcha: you cannot rerun a workflow while it is still in progress. The CLI can return an error that makes it sound like the workflow file is invalid. In practice, it often just means the run has not finished yet.

If you want to rerun one specific job, get the correct ID first:

gh run view <run-id> --json jobs --jq '.jobs[] | {name, databaseId}'

Use databaseId with --job. Do not trust yourself to grab a random number from the web UI and hope it matches what the CLI expects.

Watch it live

gh run watch <run-id>

This streams the run as it happens. It is the closest thing to tail -f for Actions, and it is a lot nicer than refreshing the browser every 20 seconds.

If you live in the terminal already, this feels like the missing piece.

Trigger a run without pushing a commit

gh workflow run <workflow-file>.yml --ref <branch>

If a workflow supports workflow_dispatch, use it. It is one of the simplest ways to test workflow changes without creating throwaway commits just to poke CI.

If your workflow does not expose workflow_dispatch, that is worth fixing. Manual triggers make debugging easier and demos cleaner.

The 403 that wastes too much time

A surprising number of Actions failures come down to one thing: GITHUB_TOKEN does not have the permission your workflow needs, and the error message is usually less clear than it should be.

If your workflow needs to write to the repository or update a pull request, declare permissions explicitly:

permissions:
  contents: write
  pull-requests: write

Do not rely on defaults and then act surprised when a write fails halfway through automation. Ask for the minimum you need, on purpose.

The loop I actually use

gh run list                       # find the run
gh run view <run-id> --log-failed # read the failure
gh run rerun <run-id> --failed    # retry only what broke
gh run watch <run-id>             # follow the rerun live

That is enough for a big chunk of day-to-day Actions debugging. The browser still has its place, but it does not need to be your default.

Full reference: cli.github.com/manual/gh_run

GitHub Actions: The Stuff Nobody Tells You

Andrea Liliana Griffiths — Sun, 05 Apr 2026 12:39:48 +0000

GitHub Actions: The Stuff Nobody Tells You

I work at GitHub. I use Actions every day. I've also debugged YAML at 2am, watched the log viewer eat my browser, and pushed a bunch of commits in a row just to figure out why a conditional wasn't evaluating correctly.

I'm not here to tell you Actions is perfect. It's not. The log viewer has made grown engineers question their career choices. The YAML expression syntax has a learning curve that feels more like a learning cliff. The push-wait-fail-repeat debugging loop can turn a five-minute fix into an afternoon-long hostage situation.

I know this because I've lived it. And I've watched thousands of developers live it too.

But here's what I've also seen: most of the pain comes from patterns that are avoidable. Not all of it. Some of it is the platform catching up. But a lot of it is stuff that has solutions right now that people haven't discovered yet because the easy path is to just keep copy-pasting YAML and suffering.

This article is the stuff I wish someone had told me on day one.

Stop Using the Log Viewer

I'm serious. The web UI for reading build logs is the single biggest source of frustration with Actions, and the fastest fix is to stop using it.

gh run view --log-failed

That's it. Failed step, in your terminal, instantly. No clicking through three pages. No waiting for the browser to decide whether it wants to render today. No back button roulette.

If you want the full log:

gh run view --log

If you want to watch a run in real time:

gh run watch

The CLI is faster, searchable with grep, and doesn't crash when your test suite outputs 50,000 lines. If you're still clicking through the web UI to read build logs in 2026, this is your sign to stop.

The YAML Problem Is Real. Here's How to Shrink It.

Every CI system ends up as "a bunch of YAML." Actions is no exception. But there's a difference between a 40-line workflow that does one thing clearly and a 400-line monster with nested conditionals, matrix strategies, and inline bash scripts that would make a shell programmer cry.

The 400-line monster happens because people don't know about the two features designed to prevent it. Or they don't use them.

Reusable Workflows

If you have the same CI steps across multiple repos, you're probably copy-pasting workflows. Stop.

# .github/workflows/ci.yml
jobs:
  build:
    uses: your-org/.github/.github/workflows/build.yml@main  # @main is fine for internal repos you control — but if you SHA-pin everything else, consider pinning this too
    with:
      node-version: '20'
    secrets: inherit

One workflow, maintained in one place, called from everywhere. When you update it, every repo that uses it gets the update. No drift. No "wait, which repo has the latest version of our deploy script?"

Composite Actions

Reusable workflows are for whole pipelines. Composite actions are for steps, the building blocks.

# .github/actions/setup-project/action.yml
name: 'Setup Project'
runs:
  using: 'composite'
  steps:
    - uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0
      with:
        node-version: ${{ inputs.node-version }}
    - run: npm ci
      shell: bash
    - run: npm run build
      shell: bash

Now your workflow files read like sentences, not telenovelas:

steps:
  - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  - uses: ./.github/actions/setup-project
    with:
      node-version: '20'
  - run: npm test

The YAML is still there. But it's 12 lines, not 120. And when setup changes, you change it in one place.

Break the Push-Wait-Fail Loop

The most soul-crushing part of Actions debugging: you make a one-character change to a workflow file, push it, wait four minutes for a runner to spin up, and find out you missed a quote. A bunch of commits later, your git history looks like a cry for help.

act, a community-maintained tool, runs your workflows locally in Docker containers. Same environment, no push required.

act -j build

It's not a perfect replica. Some GitHub-specific contexts don't exist locally. But for "did I break the YAML" and "does my bash script actually work," it cuts that feedback loop from minutes to seconds.

For simple syntax validation before you even run anything:

gh workflow view ci.yml

If the YAML has obvious issues, it'll surface them quickly. It's not a full linter, but it catches the basics without a push cycle.

The Marketplace Trust Problem (and What to Do About It)

Every uses: some-stranger/cool-action@v2 is code you didn't write running with access to your repo and secrets. That's a real security concern, and "just pin to a SHA" is the right answer that nobody follows.

Here's what actually works:

Pin to SHAs and let Dependabot manage updates:

uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

Add the version in a comment so humans can read it. Dependabot will open PRs when new versions drop, and you can review the diff before updating. (SHAs in this article were verified on March 30, 2026.)

Stick to GitHub-maintained actions when possible. actions/checkout, actions/setup-node, actions/cache — these are maintained by the same team that builds the platform. They're audited, tested, and updated.
For everything else, read the source. It's open source. If a marketplace action is a 20-line shell script wrapped in a Dockerfile, maybe just copy the 20 lines into a run: step and own it.
Use OpenSSF Scorecard to assess action maintainer practices before adopting.

Conditional Logic Without Losing Your Mind

The ${{ }} expression syntax is one of those things that's simple until it isn't, and then it's baffling. The edge cases around string interpolation, truthiness, and type coercion have bitten everyone at least once.

A few survival rules:

# Always quote expressions in `if:`
if: ${{ github.event_name == 'push' }}

# Use fromJSON for booleans from inputs
if: ${{ fromJSON(inputs.deploy) == true }}

# Multi-condition? Use >- to fold newlines into spaces.
if: >-
  ${{ github.ref == 'refs/heads/main' &&
      github.event_name == 'push' }}

And if your conditional logic is getting complex enough to need a flowchart, that's a sign you need a reusable workflow with inputs, not more if: statements.

The case() function is a recent addition worth knowing about. Think of it as a switch statement for expressions. It replaces nested ternaries that nobody can read.

Let Copilot Write the YAML

I'm not going to pretend the YAML is fun to write. But in 2026, you don't have to write most of it.

In VS Code with GitHub Copilot, describe what you want in a comment:

# Deploy to production on push to main, run tests first,
# cache node_modules, notify Slack on failure

Copilot generates the workflow. You review and adjust. It handles the syntax, the on: triggers, the runs-on:, the step ordering, so you focus on what the pipeline should do, not on remembering whether environment goes inside or outside jobs:.

For existing workflows, Copilot agent mode can refactor a 400-line YAML file into reusable workflows and composite actions. Tell it what you want, review the PR.

This doesn't fix Actions. It fixes you having to wrestle with it directly.

Caching: The Free Speed You're Probably Not Using

If your workflow installs dependencies on every run and you haven't set up caching, you're leaving minutes on the table for free.

- uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0
  with:
    node-version: '20'
    cache: 'npm'

TThat one line — cache: 'npm' — tells setup-node to cache your node_modules between runs. First run is normal. Every run after that skips the full npm ci download. For large projects, this cuts two to four minutes off every build.

The same pattern works for other ecosystems:

# Python
- uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
  with:
    python-version: '3.12'
    cache: 'pip'

# Go (manual cache)
- uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
  with:
    path: ~/go/pkg/mod
    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}

If you need more control, actions/cache lets you cache anything — build artifacts, Docker layers, compiled binaries. The key is hashing your lockfile so the cache invalidates when dependencies actually change.

Stop Running the Same Workflow Twice

If your team pushes fast, you've probably seen this: three commits in ten minutes, three workflow runs queued, the first two are already stale by the time they finish.

Concurrency groups fix this:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Add this at the top level of your workflow. Same branch, same workflow — the old run gets cancelled when a new one starts. No more wasting runner minutes on commits that are already superseded.

This is especially useful for PR workflows where developers are iterating quickly. Without it, you're paying for builds nobody will look at.

What's Actually Getting Better

I said I wouldn't sugarcoat this, so let me be specific about what's improved and what still needs work.

Better now:

Job summaries, structured output instead of just log lines
Larger runners, 64-core machines available, ARM runners in GA
Required workflow enforcement via rulesets, organization-wide policy without copy-paste
Larger runners, 64-core machines available on paid plans (Team/Enterprise), ARM runners in GA for public repos
Immutable actions, actions published to GHCR with provenance
case() and recent expression improvements

Still needs work:

The log viewer. It's improved, but it's not where it needs to be for large builds. Use the CLI.
Debugging experience. act helps, but first-party local execution would change everything.
The learning curve for expressions. The docs team has been steadily improving this, and it shows — but there's still room to grow.

I'm not writing this to defend GitHub's honor. I'm writing it because I've watched too many teams suffer through problems that have solutions, and those solutions aren't reaching people fast enough.

The fundamentals are there. The platform works. But "works" and "pleasant" are different things, and the gap between them is where your afternoon disappears. These patterns close that gap. Not all the way. But enough.

🆕 Update: I turned the patterns from this article into a reusable Copilot skill — a markdown file your AI coding agent can reference when writing workflows. It covers SHA pinning, matrix strategies, artifacts, permissions, timeouts, and the filesystem gotchas that eat your afternoon. Still testing it, but you can try it now: GitHub Actions Skill

GitHub Copilot CLI Enhanced with Chronicle

Andrea Liliana Griffiths — Sat, 28 Mar 2026 03:08:26 +0000

https://github.com/features/copilot

OpenClaw Just Passed React. Here's What the GitHub Star Leaderboard Actually Looks Like

Andrea Liliana Griffiths — Thu, 26 Mar 2026 22:13:47 +0000

https://dev.to/andreagriffiths11/openclaw-just-passed-react-heres-what-the-github-star-leaderboard-actually-looks-like-3d5g

OpenClaw Just Passed React. GitHub Star Leaderboard Update.

Andrea Liliana Griffiths — Thu, 26 Mar 2026 22:09:06 +0000

https://dev.to/andreagriffiths11/openclaw-just-passed-react-heres-what-the-github-star-leaderboard-actually-looks-like-3d5g

OpenClaw Just Passed React. Here's What the GitHub Star Leaderboard Actually Looks Like.

Andrea Liliana Griffiths — Thu, 26 Mar 2026 22:07:24 +0000

https://dev.to/andreagriffiths11/openclaw-just-passed-react-heres-what-the-github-star-leaderboard-actually-looks-like-3d5g

OpenClaw Just Passed React. Here's What the GitHub Star Leaderboard Actually Looks Like.

Andrea Liliana Griffiths — Thu, 26 Mar 2026 22:01:44 +0000

https://dev.to/andreagriffiths11/openclaw-just-passed-react-heres-what-the-github-star-leaderboard-actually-looks-like-3d5g

A Rapper Tweeted About GitHub, So I Built Him a Learn-to-Code Repo from My Phone

Andrea Liliana Griffiths — Wed, 25 Mar 2026 14:14:07 +0000

A Rapper Tweeted About GitHub, So I Built Him a Learn-to-Code Repo from My Phone

Meek Mill tweeted about GitHub. It was the middle of the night. I was in bed, half asleep, scrolling on my phone.

So I messaged my AI agent from my phone, told it to build a learn-to-code repo for Meek Mill styled like album tracks, and it created the repo on GitHub and assigned the task to Copilot coding agent. Copilot wrote the content, structured the tracks, and opened a PR. I reviewed and merged from my phone.

I never opened a terminal. Never opened an IDE.

The repo: dreamchasers. Six tracks plus a bonus, album format, each one teaching a real GitHub skill. Track 1 to first repo in 10 minutes. Here's the tweet.

A rapper with 10 million followers just put "GitHub" in front of people who have never heard of a pull request. Some kid scrolling past that tweet is going to think "wait, I can do that?" and the answer is yes.

You don't need a CS degree. Don't need a bootcamp. Don't even need to leave your browser. Just a GitHub account and curiosity.

What's New in Copilot CLI

I wrote the official getting started guide back in October. A lot has changed since then.

It's Free

Copilot CLI is included as a core feature of all GitHub Copilot plans: Free, Pro, Pro+, Business, and Enterprise. You get a free GitHub account, you get Copilot CLI. Each interaction uses premium requests from your plan's allowance (50/month on Free).

Three Modes: Ask, Plan, Autopilot

Press Shift+Tab to cycle between modes:

Ask/Execute mode is the default. You prompt, Copilot acts, you approve each step.

Plan mode analyzes your request, asks clarifying questions, and builds a structured implementation plan before writing any code. Catches misunderstandings before they become bad commits.

Autopilot mode carries the task forward without step-by-step approval. You outline the work, then let it run.

Model Agnostic

Use /model to switch between Claude, GPT, Gemini, and more. Switch mid-session. Run /fleet to execute across multiple models in parallel.

Interactive and Programmatic

Two interfaces:

Interactive: Run copilot and have a conversation. Use /plan to outline work, /fleet to parallelize, /delegate to hand off, /chronicle to review your session history.

Programmatic: Pass a prompt directly with copilot -p "your task here". It runs, completes the task, exits. Good for scripts and automation.

Native GitHub Integration via MCP

Copilot CLI works directly with your issues and pull requests through GitHub's native MCP server. Search issues, analyze labels, create branches, open PRs.

Custom Agents and Skills

Use AGENTS.md and Agent Skills to define custom instructions and tool access, so your agent works the same way every time.

Copilot Coding Agent

The coding agent is what I actually used to build the dreamchasers repo from my phone. It works autonomously in a GitHub Actions environment: you assign it an issue or describe a task, it explores your repo, writes the code, runs your tests and linters, and opens a pull request. You review it like any other PR.

Copilot coding agent is available with GitHub Copilot Pro, Pro+, Business, and Enterprise plans.

The Repo

dreamchasers. Six tracks plus a bonus, album format — from making your first repo to contributing to open source. Everything runs in the browser.

Want to Try Copilot CLI?

This is the tool that built the repo. It turns plain English into code, right from your terminal.

# Install Copilot CLI
npm install -g @github/copilot

# Launch it
copilot

Included in all Copilot plans, including Free. All you need is a GitHub account.

If you want to go deeper, here's the official guide I wrote for the GitHub Blog and the full documentation.

The Point

Meek Mill getting into GitHub matters because someone who grew up on Dreams and Nightmares might see this and realize the tools are free, the community is open, and nobody is checking credentials at the door.

Dream chasers ship code. 🎤

Quantum Computing: The Compute Power Behind 'Curing Cancer'

Andrea Liliana Griffiths — Tue, 24 Mar 2026 14:45:09 +0000

Quantum Computing: The Compute Power Behind "Curing Cancer"

A few weeks ago, my boss Cassidy posted a video about her feelings on AI. She called it "An attempt at a balanced perspective on AI" and described the process as repeatedly "crashing out" while working through her thoughts.

I watched it. Then I left a comment: "Let's get AI to cure cancer first, then throw it in the ocean."

I'm a breast cancer survivor. That experience rewrites your priorities. When people ask what I want from AI, I don't say better autocomplete. I say cure cancer. Then throw it in the ocean. But cure cancer first.

That comment stuck with me. I started wondering what it would actually take. Not the hype. Not the TED talks. The actual compute. And that question led me somewhere unexpected: quantum computing.

What Quantum Computing Actually Is

Let's clear something up. Quantum computers are not faster regular computers. They're fundamentally different machines that solve fundamentally different problems.

Classical computers use bits. Each bit is either 0 or 1. You know this. It's how every computer you've ever used works.

Quantum computers use qubits. A qubit can be 0, 1, or both at the same time through a property called superposition. When qubits interact through entanglement, they can represent and process vastly more information than the same number of classical bits. The math gets weird fast. But the intuition matters: quantum computers don't try every possibility sequentially. They explore probability spaces in ways that classical computers physically cannot replicate.

This isn't theoretical anymore. Google's Willow chip demonstrated a 13,000x speedup over the world's fastest supercomputer in October 2025 for a specific quantum algorithm. That's not a rounding error. That's a different category of computation.

Where We Are in 2026

The quantum computing narrative has shifted from "maybe someday" to "which modality wins."

Caltech's 6,100-Qubit Array

Caltech built a neutral-atom array with 6,100 qubits in September 2025, the largest controlled quantum system ever assembled. The previous record was around a thousand. These qubits maintained coherence for 13 seconds with 99.98% fidelity. Coherence time matters because it determines how much useful computation you can do before quantum effects collapse.

IBM's Nighthawk Processor

Running at 120 qubits, achieved a 10x speedup in quantum error correction decoding. Error correction is the bottleneck. Quantum states are fragile and every interaction with the environment introduces noise. IBM's progress means we're getting better at keeping quantum information intact long enough to compute with it.

Quantinuum's H2 Processor

Became the first quantum computer to reach Microsoft's Level 2 Resilient phase. They produced logical qubits with error rates 800x lower than physical rates using just 30 physical qubits to create four logical qubits.

The Industry Crossed a Billion Dollars in Revenue

IonQ, the largest publicly traded pure-play quantum company, hit $39.9M in Q3 2025 revenue, up 221% year-over-year. Governments have committed over $40 billion in national quantum strategies. These are not vaporware numbers.

Why Drug Discovery Changes Everything

Here's where cancer comes in.

The pharmaceutical industry has a problem: most AI-designed drug molecules look promising on computers but are nearly impossible to synthesize in labs. This is called downstream attrition. You find a candidate that should work, spend millions developing it, then discover it can't actually be manufactured.

Classical computers struggle with molecular simulation because the math of quantum mechanics scales exponentially with the number of electrons. Simulating a single caffeine molecule accurately requires classical computing resources that push against the limits of what's physically possible.

Quantum computers are naturally suited for this. They don't simulate quantum mechanics. They are quantum mechanics.

In January 2026, PolarisQB released a head-to-head study showing their quantum annealing platform running on D-Wave hardware outperformed classical generative AI for drug discovery. Classical AI took 40 hours to suggest molecules. The quantum system took 30 minutes. More importantly, the quantum-generated leads were significantly easier to synthesize in the lab.

In February 2026, Telefónica, Vithas hospitals, and Francisco de Vitoria University launched a quantum computing project specifically for cancer drug design. They're targeting the BRAF V600E mutation, an altered protein that drives uncontrolled cancer cell growth. The goal is to use quantum algorithms to generate molecules that inhibit this protein. This is not a whitepaper. It's happening now.

The Compute Requirements

I asked: what would it actually take to cure cancer with compute?

The honest answer is we don't know yet. But we're getting real data points.

The number of possible drug-like molecules exceeds 10^60. That's more than atoms in the observable universe. Classical computers cannot search this space exhaustively, so they use heuristics, approximations, and machine learning to guess at promising regions. Quantum computers approach this differently. For specific optimization problems, and drug discovery is fundamentally an optimization problem, they can explore solution spaces in ways classical algorithms cannot match.

Researchers at Caltech published a quantum computing framework in February 2026 specifically for multi-stage drug discovery, covering allosteric site identification, protein-peptide docking, and molecular dynamics. It encodes three quantum algorithms that classical methods struggle to approximate.

The scale needed for practical advantage keeps shrinking. Google's demonstration used their 105-qubit Willow chip. IBM's roadmap targets 200 logical qubits by 2028. Logical qubits are error-corrected qubits that can run reliable computations. Each logical qubit requires many physical qubits to maintain, but the ratios are improving fast.

The Hardware Reality

Different companies are betting on different qubit technologies, and none have clearly won.

Superconducting Qubits (IBM, Google, Rigetti)
Offer fast gate operations but require millikelvin temperatures. IBM operates the largest cloud-accessible quantum fleet and Google achieved the landmark quantum advantage demonstration with this approach.

Trapped Ions (IonQ, Quantinuum)
Offer higher fidelity and fully connected qubits at the cost of slower operations. IonQ holds the world record at 99.99% two-qubit gate fidelity and Quantinuum's H2 processor leads in quantum volume.

Neutral Atoms (QuEra, Pasqal, Atom Computing)
Can pack thousands of qubits in arrays with longer coherence times. This is the technology behind Caltech's 6,100-qubit breakthrough.

Photonic Computing (PsiQuantum, Xanadu)
Has room temperature operation potential but harder gate reliability. PsiQuantum raised over $2 billion and is building datacenter-scale quantum compute centers.

All of these are viable for different applications. The race is still open.

A New Research Agenda

I started this with a frustrated comment about AI hype. I ended it with a reading list of quantum physics papers and a new appreciation for how much work happens between the hype cycles.

The quantum computing industry has moved from "trust us, it's coming" to "here are the benchmarks." The applications have narrowed from "everything" to specific domains where quantum mechanics gives inherent advantages. Drug discovery and materials science lead that list.

Cancer isn't one disease. It's thousands of molecular malfunctions, each requiring an understanding of specific protein interactions, cellular pathways, and drug binding mechanisms. Classical compute hits walls. Quantum compute might help us climb over them.

I'm not saying quantum computers will cure cancer. I'm saying the people who might cure cancer are starting to use them. That's not AI hype. That's a research direction worth following.

Andrea Griffiths is a Senior Developer Advocate at GitHub and a breast cancer survivor. She writes Main Branch, a newsletter about developer fundamentals.

DEV Community: Andrea Liliana Griffiths

An agent loop that stops itself

opencode-fusion: a panel that argues, then a judge

agmsg: agents that message each other

What I built

Keeping it from eating itself

/orchestrate: the same idea with a UI

Stop paying for the same tokens twice

What I built

The numbers

When caching actually beats the librarian

What surprised me about caching

Try it yourself

What I'd actually ship

I Gave My Newsletter a Voice (Literally)

I Gave My Newsletter a Voice (Literally)

What LiveKit Actually Does

The Architecture

The RAG Part

Why Azure Speech Services?

What Surprised Me

What's Next

Debug GitHub Actions from Your Terminal with gh

Debug GitHub Actions from Your Terminal with gh

Find the run

Read only what failed

Retry only the broken part

Watch it live

Trigger a run without pushing a commit

The 403 that wastes too much time

The loop I actually use

GitHub Actions: The Stuff Nobody Tells You

GitHub Actions: The Stuff Nobody Tells You

Stop Using the Log Viewer

The YAML Problem Is Real. Here's How to Shrink It.

Reusable Workflows

Composite Actions

Break the Push-Wait-Fail Loop

The Marketplace Trust Problem (and What to Do About It)

Conditional Logic Without Losing Your Mind

Let Copilot Write the YAML

Caching: The Free Speed You're Probably Not Using

Stop Running the Same Workflow Twice

What's Actually Getting Better

GitHub Copilot CLI Enhanced with Chronicle

OpenClaw Just Passed React. Here's What the GitHub Star Leaderboard Actually Looks Like

OpenClaw Just Passed React. GitHub Star Leaderboard Update.

OpenClaw Just Passed React. Here's What the GitHub Star Leaderboard Actually Looks Like.

OpenClaw Just Passed React. Here's What the GitHub Star Leaderboard Actually Looks Like.

A Rapper Tweeted About GitHub, So I Built Him a Learn-to-Code Repo from My Phone

A Rapper Tweeted About GitHub, So I Built Him a Learn-to-Code Repo from My Phone

What's New in Copilot CLI

It's Free

Three Modes: Ask, Plan, Autopilot

Model Agnostic

Interactive and Programmatic

Native GitHub Integration via MCP

Custom Agents and Skills

Copilot Coding Agent

The Repo

Want to Try Copilot CLI?

The Point

Quantum Computing: The Compute Power Behind 'Curing Cancer'

Quantum Computing: The Compute Power Behind "Curing Cancer"

What Quantum Computing Actually Is

Where We Are in 2026

Caltech's 6,100-Qubit Array

IBM's Nighthawk Processor

Quantinuum's H2 Processor

The Industry Crossed a Billion Dollars in Revenue

Why Drug Discovery Changes Everything

The Compute Requirements

The Hardware Reality

A New Research Agenda

Further Reading

Debug GitHub Actions from Your Terminal with `gh`