Forem: Andrea Liliana Griffiths

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.

An Experiment in Voice: What Happens When AI Learns to Write Like You

Andrea Liliana Griffiths — Tue, 24 Mar 2026 14:44:10 +0000

An Experiment in Voice: What Happens When AI Learns to Write Like You

Fine-tuning Qwen3 8B with Unsloth, and what it taught me about what voice actually is.

I fine-tuned a language model on three years of my own writing. Not because I wanted a clone spitting out newsletters while I slept. Not because I thought the world needed more content with my name on it. I did it because I got curious about something specific: what actually happens when you teach an AI system how to sound like a real person?

Most fine-tuning feels like this. You grab a general model. Point it at a specific domain. Marketing copy, customer support, engineering docs. The model learns the patterns of that domain and gets better at sounding like it belongs there. But it doesn't capture perspective. It doesn't learn the actual choices a human makes when deciding how to explain something.

I wanted to try something different. So I took Qwen3 8B and trained it on three years of how I actually talk to people about technical stuff. Not the polished version that lands on The GitHub Blog. The real stuff. How I'd onboard someone new to the team. When I'd decide to start with "here's why this exists" instead of jumping to "here's how to use it." The moment where I shift from talking about theory to talking about what actually works. The tone that makes someone feel like you understand what it's like to be new to this and not stupid.

Newsletters. Conference talks. Conversations with developers learning GitHub for the first time. Issues where I had to explain something five different ways until it finally clicked. The unglamorous moments where communication actually happens.

How Unsloth made this possible

Here's the thing that made this experiment actually feasible: Unsloth.

Fine-tuning a language model normally requires serious hardware. You're talking GPU clusters, thousands of dollars, infrastructure that most people don't have access to. Unsloth is a library that optimizes the fine-tuning process so aggressively that you can train on a free Colab T4 GPU. Sixteen gigs of VRAM. That's it.

I started with Llama 3.1 8B but switched to Qwen3 8B. The base model matters more than anything you do after. Qwen3 is newer, trained on more data, and its instruction-following is significantly better out of the box. Same parameter count, better foundation. That switch alone improved the output more than any hyperparameter tweak I tried.

Unsloth does this through something called LoRA, which stands for Low-Rank Adaptation. Instead of retraining the entire model's weights (which is expensive and slow), LoRA adds small adapter matrices to specific layers. The base model stays frozen. You're only training the adapters. Think of it like adjusting the instruments on an orchestra instead of replacing the musicians. The orchestra still plays all the same notes. You're just tuning how it sounds.

I set LoRA rank to 16. That number controls how much capacity those adapters have. Higher rank means more flexibility, more VRAM, more training time. Lower rank means tighter constraints but faster convergence. Rank 16 was the sweet spot for eighty-one examples of my voice. I also set LoRA alpha to 32 (double the rank) so the adapter updates scale correctly during training.

The target modules were the attention layers: q_proj, k_proj, v_proj, o_proj, plus the feed-forward layers (gate_proj, up_proj, down_proj). Those are the parts of the model that control how it processes and generates language. That's where voice lives.

Training was sixty steps with a batch size of 2 and gradient accumulation across 4 batches. Learning rate at 1e-4, which is conservative for a small dataset. A higher learning rate would overshoot on eighty-one examples and corrupt the model's general knowledge. Lower and you're training forever.

The data went through the ChatML template, which is Qwen's format: system prompt, user message, assistant response. Each example was formatted correctly so the model learns not just what to write but how to respond to a specific prompt structure.

The export was quantized to q4_k_m. That's 4-bit quantization with K-means clustering. The model compresses from full precision (32-bit floats) down to 4-bit integers without much quality loss. Final size: about 5GB. Portable. Runs on a MacBook Pro with 16GB RAM. Local. No API calls. No privacy concerns.

Without Unsloth, this experiment doesn't happen. You'd need a lab budget or months waiting for cloud infrastructure. Instead, I did it in a free Colab notebook in an afternoon and downloaded the trained model by evening. Total cost: zero dollars and an afternoon.

What it captured and what it didn't

The model learned how I write. Not how I think.

When you give it a technical problem, it mirrors back my sentence structure. It breaks thoughts into separate sentences instead of chaining them together with corporate connectives. It asks what you're actually trying to do before jumping to answers. It flinches away from marketing language like an instinct. It opens with the problem instead of the feature.

Those are communication choices. Patterns. Style. The model got really good at capturing them.

What it didn't capture is the thing underneath that actually matters: the ability to change your mind.

I used to be really convinced about certain stacks. Defended them hard. Built entire arguments around why they were the right choice. Then I changed my mind. I've done it with people too. Teams I thought were solid until they weren't. Technologies I was certain about until I saw something better and had to actually admit I was wrong about the first thing.

That willingness to be wrong isn't in the training data. It can't be. The model learns from what you've already written. It doesn't learn that you might write something completely different tomorrow because you figured something out today that contradicts what you said yesterday.

That's the actual gap between a system that learned your voice and a voice that belongs to a real person. You get to change. You get to contradict yourself. You get to look back at what you believed last year and go "yeah, nah, I was wrong about that."

The model will always sound like 2026 Andrea. You won't be 2026 Andrea forever.

Why I'm telling you this

Most companies are fine-tuning AI to sound professional. Polished. On-brand. Safe. But there's something more interesting you can actually do: teach an AI system to communicate the way a real technical authority communicates. Not to think like them. Just to sound like them.

If you're building documentation, that means AI that matches how you actually talk about things, not some generic "professional" tone that makes everything sound corporate. If you're a developer advocate trying to scale your explanations without losing your actual voice, it means you can get a tool that captures how you really talk about problems. If you're trying to communicate technical ideas at scale without everything turning into corporate mush, teaching voice is a different kind of leverage entirely.

The model didn't learn my perspective. It learned my patterns.

What you can actually do with this

You could use this to write more content faster. Delegate some of the explanation work. Get a communication partner that sounds like you without requiring you to actually sound like someone else.

But I didn't build this to manufacture content. I built it to understand what voice actually is. To prove that you can teach an AI system to communicate like a real person. To create something that sounds like a technical authority instead of a corporate algorithm.

The result is useful if you're trying to scale thoughtful explanation. If you need documentation that doesn't sound generic. If you want a partner that talks through problems the way you talk through problems.

But here's what it won't do: it won't change its mind. It won't wake up tomorrow and realize it was wrong about a framework, a practice, a person. It won't evolve because it learned something new. It won't contradict itself because the evidence demanded it.

That's the thing worth protecting in yourself. The freedom to be wrong. The courage to change your mind when the evidence shows up. The humility to know that what you're certain about today might be the thing you completely rethink next year.

Teaching voice to a machine is useful. But your voice matters because it's attached to a mind that keeps changing.

Update — March 17, 2026: Unsloth just launched Unsloth Studio, an open-source, no-code web UI for training, running, and exporting models locally. It runs on Mac, Windows, and Linux — no Google Colab notebook required. If you wanted to try the fine-tuning workflow from this article but didn't want to deal with notebook setup, Studio is now the easiest way to get started. Auto-creates datasets from PDFs, CSVs, and docs. Exports to GGUF. All local.

I Asked My AI Agent to Update My E-Ink Display. It Just Did It.

Andrea Liliana Griffiths — Mon, 16 Mar 2026 21:16:01 +0000

No YAML. No config files. I just said what I wanted.

I have a TRMNL on my desk. Small e-ink display — black and white, no notifications, no dopamine tricks. It cycles through plugins that show whatever you tell it to show.

I wanted one of those plugins to show a daily message from my AI agent, plus my top priorities for the day. Not pulled from GitHub Issues or scraped from a calendar API. Actual priorities — the stuff we'd been working on together.

So I told my agent: "Every day at noon, push a daily message and my top 3 priorities to my TRMNL display." I gave it the webhook URL.

That was the entire setup.

What it looks like

Two columns. Left side: a short message from the agent — sometimes motivational, sometimes a callback to something we worked on the day before. Right side: three numbered priorities pulled from our actual conversations and working context.

The agent knows what matters because it was there while I worked.

How it works

TRMNL plugins support a webhook strategy. You create a private plugin, get a webhook URL, and anything that POSTs JSON to that URL updates your display.

The JSON:

{
  "merge_variables": {
    "agent_name": "Luna",
    "message": "Four takes to get a clean demo. The fifth one was honest.",
    "signature": "— Luna 🌙",
    "date": "Mar 16, 2026",
    "priority_1": "Fix Railway env vars",
    "priority_2": "Test checkout flow end-to-end",
    "priority_3": "Ship the TRMNL plugins repo"
  }
}

My agent runs on OpenClaw and has a cron job that fires daily. It reads its own memory files — notes from our conversations, decisions we made, things still in progress — picks the top priorities, writes a message, and POSTs it.

You could do the same with GitHub Copilot in the CLI. Ask it to read your repo context, summarize your priorities, and push to the webhook. One prompt.

What surprised me

I didn't write a config file. No GitHub Action. No cron expression typed into a terminal.

I said: "Hey, every day at noon, push a daily message and my top 3 priorities to my TRMNL display. Here's the webhook URL."

The agent set up its own cron, figured out the JSON format, and started pushing. The next morning my display had priorities on it that I hadn't typed anywhere — pulled from things we'd actually discussed the day before.

That's what an agent does differently. You describe the outcome. It handles the wiring.

Try it yourself

I open-sourced the template and instructions: trmnl-plugins on GitHub

The agent-says plugin works with any AI agent that can make HTTP requests. The README has the exact prompt to give your agent. Setup takes about two minutes — most of that is creating the plugin on TRMNL.

I also built a GitHub Stars plugin that shows the most starred repos on GitHub. Same webhook pattern, different data. The repo has both. More coming.

With gratitude,
Andrea

Building an AI-Powered Guest Automation with the Copilot SDK

Andrea Liliana Griffiths — Fri, 13 Mar 2026 16:14:47 +0000

Building an AI-Powered Guest Automation with the Copilot SDK

Every week on Open Source Friday, we host open source maintainers on our livestream. When a guest gets confirmed, someone on the team labels the issue to kick off an action that writes a welcome message and shares prep instructions. From there, we manually create event posts and design a thumbnail (if you can call my lack of design sensibility that).

The problem? Starting from scratch every time meant we'd fall back to the same template:

"You're officially scheduled for Open Source Friday! The stream starts at 1:00 PM ET. Please join at 12:45 PM ET for prep and tech checks."

It worked. But it was boring, and we had better material sitting right there in the issue. Each guest submission included their project details, background, and what they wanted to talk about. We just weren't using it.

So I built an automation that reads their submission and writes a personalized draft. When a guest mentions they're excited to talk about their CLI tool that helps developers debug faster, the workflow catches that and generates:

"We can't wait to hear about your CLI tool and how it's helping developers debug faster. Your approach to solving this problem sounds like exactly what our audience needs to hear about."

Not perfect, but a heck of a lot better than starting with a blank comment box.

What I wanted here was not to replace the human attention. Just give us a better starting point.

What it does

A GitHub Actions workflow that triggers when we add the scheduled label to a guest's issue. It automatically:

Parses the guest submission (name, GitHub handle, project, and bio)
Generates a personalized welcome message draft using the Copilot SDK
Creates a promotional thumbnail using Puppeteer to automate our thumbnail generator
Posts everything as a scaffolded comment that we can review and personalize further

The automation doesn't replace the human review. It gives us a draft that already pulls from what they wrote, so we spend our time refining instead of starting from a blank comment box.

Why the Copilot SDK?

I wanted the automation to pull out the interesting bits from each submission and give us a draft that actually sounds human. The Copilot SDK makes this possible without building all the infrastructure myself.

The SDK is in technical preview, and it gives you programmatic access to GitHub Copilot through a simple JavaScript API. No need to deal with raw HTTP requests or wire up authentication yourself.

Here's what makes it useful:

Multi-turn conversations. Sessions maintain context across multiple requests. If you wanted to build something more complex than a single prompt-response (like a chatbot that remembers previous questions), the SDK handles that.

Custom tools. You can define functions that Copilot can invoke during conversations. For example, you could give it a tool to fetch GitHub issues or query your database, and Copilot decides when to use it.

Lifecycle management. The SDK starts the Copilot CLI, which authenticates using the same mechanisms as the CLI itself (interactive login or environment‑provided tokens such as GH_TOKEN/GITHUB_TOKEN with the right permissions), and then proxies your requests to GitHub Copilot.

For this automation, I'm using the simplest possible pattern: one prompt in, one response out. The prompt does all the heavy lifting:

const promptLines = [
  'You are writing on behalf of the Open Source Friday team...',
  '',
  'Guest details:',
  '- Name: ' + guestName,
  '- Project: ' + projectName,
  '- About them (in their own words): ' + guestBackground,
  '',
  'Write a 2-3 sentence welcome message that:',
  '1. Greets them by name',
  '2. Matches their energy — if playful, be playful back; if formal, be warm but professional',
  '3. References something specific they said about themselves',
  '4. Shows genuine excitement about having them on the stream'
];

That instruction to "match their energy" is what makes the difference. The workflow reads what the guest wrote and mirror their tone back. From there, we tweak if needed or ship it as-is.

The stack

The Copilot SDK is available in Node.js, Python, Go, and .NET. We went with the Node.js implementation since Puppeteer (needed for thumbnail generation) already required Node in the workflow. One runtime, one install step, cleaner setup.

How it works

The Architecture

Guest issue gets "scheduled" label
    ↓
GitHub Actions workflow triggers
    ↓
1. Parse issue → extract guest data
2. Copilot SDK → generate personalized message
3. Puppeteer → create thumbnail
4. Post comment with everything
    ↓
Team reviews and tweaks
    ↓
Guest gets personalized welcome

Step 1: Parse the issue

Guests submit through a GitHub issue form. The workflow extracts their info with regex:

const nameMatch = body.match(/### Name\s*\n\s*([^\n]+)/i);
const handleMatch = body.match(/### GitHub Handle\s*\n\s*@?([^\n\s]+)/i);
const projectMatch = body.match(/### Project Name\s*\n\s*([^\n]+)/i);

Nothing fancy here. Issue forms follow a consistent format, so regex gets us what we need. Copilot helped me write the regex, one less thing to debug.)

Step 2: Call the Copilot SDK

Under the hood, the SDK starts the Copilot CLI in server mode and talks to it over JSON‑RPC. You install the CLI once, then add the SDK to your project, and the SDK manages the CLI process lifecycle for you.

- name: Install dependencies
  run: |
    npm install -g @github/copilot
    npm install @github/copilot-sdk puppeteer

Here's how they work together:

Your code (@github/copilot-sdk)
    ↓
Copilot CLI (handles auth, spawns server)
    ↓
GitHub Copilot API (the actual AI)

The SDK spawns the CLI, which authenticates using your GH_TOKEN and proxies requests to Copilot. Then it's just a few lines of code:

const { CopilotClient } = await import('@github/copilot-sdk');

const client = new CopilotClient();
await client.start();

const session = await client.createSession();
const response = await session.sendAndWait({ prompt: prompt });

if (response && response.data && response.data.content) {
  personalizedMessage = response.data.content;
}

await session.destroy();
await client.stop();

The SDK handles sessions and cleanup. I pass the prompt and get back a draft message.

Step 3: Generate thumbnail

Using Puppeteer, the workflow opens our thumbnail generator, fills in the guest's info, and captures the result:

const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();

await page.goto('https://andreagriffiths11.github.io/thumbnail-gen/');
await page.type('#guestName', guestName);
await page.type('#username', handle);
await page.click('#generateBtn');

Puppeteer is basically browser automation. It opens a headless browser (no GUI), navigates to our thumbnail generator, fills in the form fields, and extracts the canvas data. This beats manually making 50+ thumbnails a year.

Step 4: Post the comment

Everything gets assembled into a scaffolded comment with the AI-generated welcome message, thumbnail download link, prep checklist, and guest guide. We review it, make any tweaks, and the guest gets a welcome that shows we actually read their submission.

Kicking it off

One command triggers everything:

gh issue edit 195 --repo githubevents/open-source-friday --add-label "scheduled"

Or just click the label in the GitHub UI. Either way, we get a scaffolded welcome comment within minutes that we can review and send.

Lessons learned

Separate your steps. Parsing, AI generation, and thumbnail creation are separate workflow steps. One failure doesn't break everything.

Prompt engineering is real work. Getting the tone right took iteration. The breakthrough was telling Copilot to match the guest's energy, not just acknowledge their project.

Test with workflow_dispatch. Adding a manual trigger made debugging way easier than waiting for label events:

on:
  issues:
    types: [labeled]
  workflow_dispatch:
    inputs:
      issue_number:
        description: 'Issue number to test with'
        required: true
        type: number

You can test without spamming your actual issues.

AI is a starting point, not the finish line. The automation gives us a draft that's already personalized to the guest's submission. We still review every message before it goes out, but now we're refining instead of writing from scratch.

What's next

Auto-generated social media copy drafts for promoting episodes
Calendar invite automation

Try it yourself

The Copilot SDK opens up possibilities for automation that gives you a head start on tasks that need a human touch. If you have repetitive communication tasks (onboarding, responses, summaries) where you want to be personal but don't always have time to start from scratch, this pattern might help.

The key isn't replacing human attention. It's giving yourself a better starting point. You'll review everything. You'll still add personality. But instead of staring at a canned message, you're starting from something already grounded in who they are. That distinction matters. The automation reads the submission, pulls out the interesting bits, and gives you a draft. You make it yours.

The code lives in githubevents/open-source-friday if you want to see the full workflow.

About the Author: Andrea Griffiths is a Senior Developer Advocate at GitHub, where she helps engineering teams adopt and scale developer technologies. She's passionate about making technical concepts accessible—to both humans and AI agents. Connect with her on LinkedIn, GitHub, or Twitter/X.

Why AI Discoverability Matters: Optimizing Your Website for This Generation of Search

Andrea Liliana Griffiths — Fri, 13 Mar 2026 16:14:37 +0000

The Search Landscape Has Changed

When was the last time you opened Google to find an answer? Most developers I know don't anymore. They ask ChatGPT, Claude, or Perplexity. The way people discover content online has fundamentally shifted, and if your website isn't optimized for AI agents, you're basically invisible.

In 2024-2025, AI-powered search went mainstream. ChatGPT added web search. Claude started analyzing websites in real-time. Perplexity built an entire search engine around AI answers with citations. Google threw AI overviews into search results. The question isn't whether AI search matters—it's whether your content will be found when someone asks.

I've been thinking about it a LOT. When a developer asks Claude "Who are the leading voices in developer advocacy?" or a recruiter asks ChatGPT "Find me experts in AI-assisted development," your website either shows up as a cited source or it doesn't exist. There's no middle ground.

Being invisible to AI is becoming invisible, period.

How AI Agents Actually Discover Content

Traditional search engines like Google use crawlers that index your HTML, analyze your links, and rank based on hundreds of signals. AI agents? They work completely differently. Here's what they actually need:

Content they can quickly understand without parsing nested <div> tags and CSS classes
Structured information about who you are, what you actually do, and why anyone should care
Credibility signals that are consistent across your metadata
Clear citations with proper titles, descriptions, and URLs they can point to

The thing is, most websites are built for human eyes. Your beautiful hero section with animated gradients? Stunning. To an AI agent, it's incomprehensible markup. Your carefully crafted "About Me" story split across five components? Good luck extracting that coherently. The information is there, but it's not AI-accessible.

The Wake-Up Call: My Own AI Audit

I realized this problem when I asked Claude to summarize my own developer advocacy work. I have a portfolio website. I have blog posts everywhere. I have conference talks listed across the web. But when I asked Claude the basic questions someone hiring a speaker would ask, it struggled. It could find my GitHub profile and a few scattered articles, but it couldn't answer:

"What are Andrea's main projects?"
"What topics does she speak about?"
"How can I contact her for a speaking engagement?"

The information existed. It was literally on my website. But it wasn't AI-accessible. That's when I decided to rebuild my online presence with AI discoverability as a first-class citizen, not an afterthought.

What I Actually Built

Here's exactly what I implemented to make my portfolio discoverable by ChatGPT, Claude, Perplexity, and every other AI agent crawling the web:

1. Created Markdown Endpoints

The biggest breakthrough was realizing something simple: AI models are trained on text. They speak Markdown natively. So I built dedicated endpoints that serve my content in clean, hierarchical Markdown instead of HTML.

Two key endpoints:

/index.md - My complete professional profile, featured projects, talks, and writings in Markdown
/writings.md - All my articles with descriptions, tags, and reading times

These endpoints pull from the same data sources as my HTML pages but serve it in a format AI agents can parse instantly. When ChatGPT or Claude crawls my site, they get structured, semantic content instead of HTML soup.

Technically, it's straightforward:

Simple API routes that fetch from GitHub Blog API, Dev.to API, Sessionize
Format everything as clean, hierarchical Markdown
Cache responses for 1 hour to reduce server load
Return proper Content-Type: text/markdown headers

The payoff? AI agents can understand my entire career in milliseconds.

2. Explicitly Welcomed AI Crawlers (Not Everyone Does This)

Here's something that surprised me: most sites accidentally block AI crawlers. Overly strict robots.txt rules. Rate limiting that catches bots too. You're essentially shooting yourself in the foot.

I updated my robots.txt to explicitly welcome every major AI crawler and point them directly to my Markdown endpoints:

# AI Bots and Crawlers - Full access including Markdown endpoints
User-agent: GPTBot
Allow: /
Allow: /index.md
Allow: /writings.md

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: anthropic-ai
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: CCBot
Allow: /

User-agent: cohere-ai
Allow: /

That CCBot from Common Crawl? Don't sleep on it. Its dataset powers a ton of AI training runs and research projects. Explicitly allowing it means your content gets into those datasets.

3. Added Rich Structured Data (So AI Agents Know What They're Reading)

AI agents love structured data. It's like giving them a cheat sheet. I implemented Schema.org JSON-LD markup across the site:

Person Schema: My name, job title, organization, what I know about (skills), social profiles
Organization Schema: Brand consistency across platforms
WebSite Schema: Site metadata and description
Event Schema: Speaking engagements with dates, locations, whether it's in-person or hybrid
Article Schema: Blog posts with authors, publish dates, clear descriptions

This structured data serves double duty: it helps traditional search engines display rich snippets, but more importantly, it gives AI agents verifiable, machine-readable facts about my work. No guessing. No parsing ambiguity.

4. Optimized for Speed (Because AI Crawlers Have Limited Patience)

Slow site? Incomplete indexing. AI crawlers will give up if your site takes forever to load. I implemented:

Image optimization: WebP format with responsive srcset cuts file size by 92-97%
Font optimization: Self-hosted fonts with font-display: swap so text renders immediately
Lazy loading: Below-the-fold images and iframes only load when needed
Mobile-first JavaScript: Desktop-only components don't load on mobile using client:media, thanks Astro
Smart caching: 1-hour cache on Markdown endpoints

Result? My homepage loads in under 1 second. Faster crawling, better indexing.

5. Built a Dual-Format Strategy

Here's what most people miss: You don't replace your beautiful website. You augment it.

Humans still see the beautiful, interactive portfolio with animations and responsive design. The experience is great. But AI agents can request /index.md and get a clean, comprehensive profile in milliseconds.

It's like having both a visual resume and a plain-text ATS-friendly resume. Same information. Different audience. Each optimized for what that audience actually needs.

You can have both. You should have both.

The Results

How do you know if this works? I tested by asking AI assistants about my work.

Before optimization: "I can see Andrea Griffiths has a GitHub profile... There's a blog post from 2024... Let me search for more information..."

Vague. Incomplete.

After optimization: "Andrea Griffiths is a Senior Developer Advocate at GitHub specializing in AI-assisted development workflows, developer tools, and team leadership. Her notable projects include Team X-Ray, a VS Code extension for revealing team expertise, and the From Pair to Peer AI Leadership Framework. She's spoken at GitHub Universe, Netlify Compose, and JFrog SwampUP..."

Night and day.

Why This Matters for Your Career

If you're a developer, designer, writer, or any professional with an online presence, AI discoverability isn't optional anymore.

Recruiters, conference organizers, potential clients—they're all using AI assistants to research people. When they ask "Find me an expert in Kubernetes security" or "Who should I invite to speak about TypeScript best practices?", your name either comes up or it doesn't. No second chances.

In the SEO era, backlinks were currency. In the AI era, citations are everything. Every time an AI assistant cites your website, it's validating your expertise, driving qualified traffic, and building your reputation in AI training datasets. Unlike humans who visit once and leave, AI agents constantly recrawl and update their understanding—becoming persistent advocates for your work in thousands of conversations you'll never see.

That's free marketing at scale. And with AI search accelerating fast (SearchGPT, AI Overviews, Perplexity), optimizing now means you're ahead of the curve.

Getting Started: Your Checklist

Ready to make your website AI-discoverable? Here's where to start, broken into realistic effort levels:

Quick Wins:

[ ] Update your robots.txt to explicitly allow AI bots (GPTBot, ClaudeBot, CCBot, PerplexityBot)
[ ] Add basic structured data (Person schema with your name, job title, and social links)
[ ] Create a simple /about.md endpoint with your bio in Markdown
[ ] Test by asking ChatGPT or Claude "What do you know about [your name]?" and see what comes back

Medium Effort:

[ ] Implement comprehensive JSON-LD structured data across your site
[ ] Create Markdown endpoints for your main content (projects, blog posts, talks)
[ ] Optimize images with modern formats (WebP, AVIF) and lazy loading
[ ] Self-host fonts and add proper caching headers
[ ] Generate or verify your sitemap is complete

Advanced:

[ ] Monitor AI citations by periodically testing different AI assistants
[ ] Keep structured data updated when you publish new content
[ ] Experiment with different Markdown formats to see what AI agents parse best
[ ] Track referral traffic from AI search engines in your analytics
[ ] Join communities discussing AI SEO so you stay ahead of best practices

The Dual-Format Future

The web is evolving to serve two audiences: humans who want beauty and interactivity, and AI agents who want structure and semantics. The websites that thrive will master both.

Your beautiful portfolio with smooth animations and stunning design? Keep it. That's for the human who wants to feel your personality and style.

But also create clean, structured pathways for AI agents to understand your expertise, cite your work, and recommend you to millions of people asking questions you'll never hear.

Because in 2026 and beyond, being found doesn't just mean ranking on Google's first page. It means being the answer when someone asks an AI, "Who's an expert in this?"

Make sure that expert is you.

Resources & Further Reading

Schema.org Documentation - Learn about structured data types
Google's Rich Results Test - Validate your structured data
OpenAI's GPTBot Documentation - Official crawler docs
Anthropic's Claude Web Crawler - How ClaudeBot works
Common Crawl - The dataset powering many AI models

Want to see how I actually built this? Check out my website at andreagriffiths.dev or dive into the Markdown endpoint that makes it all work.