Tiberriver256

Stop Reviewing Lint (AI Agents & Theory of Constraints)

2026-04-04T00:00:00-00:00

Part of a series on getting more done with AI coding agents, using the 5 Focusing Steps from Theory of Constraints.

Here’s the situation. You have AI coding agents. They write code for you. You want to ship more of it, faster.

The obvious move: make the agents faster. Run more of them in parallel.

That move is wrong. A 40-year-old idea from manufacturing explains why.

A recipe from a factory floor

Theory of Constraints says every system has exactly one bottleneck. Improve anything *other* than that bottleneck and you're wasting time. It gives you five steps. In order.

1. Identify the constraint

2. Exploit — squeeze every drop from existing capacity

3. Subordinate — align everything else around it

4. Elevate — add real capacity

5. Repeat

It's a simple recipe, but hard to follow because people always want to skip to step 4. This series walks all five, applied to AI coding agents. Let's start at the top.

Step 1: Find the constraint

This dot is you.

You review code that AI agents write. Nothing ships until you say so. That makes you the constraint, because the system moves at the speed you can read. In every AI-assisted dev team I've seen, the human reviewer is the bottleneck. Your agents produce more code in an hour than you can review in a day. You will always have more input than you can handle. Step 1: done.

Step 2: Exploit the constraint

Exploit sounds aggressive. It just means: make sure the bottleneck never wastes a cycle. You must be busy doing high-value work. Don't fiddle with tooling. Don't waste your time on nitpicky things. Automate as much as you can. What's eating your review time right now? Let's find out.

Your agents just dropped off 10 PRs

They're fast! Good for them.

Uh oh

9 out of 10 have problems. But wait...

Most of those problems are dumb

Wrong indentation, missing semicolons, someone forgot to run the formatter.

Only 2 have actual bugs — the kind that need your brain.

7 trivial · 2 real bugs · 1 clean

Without CI: all 10 land on your desk

Go ahead, send some through:

So here's what just happened

10 first reviews

+ 9 re-reviews

= up to 19 reviews

And 7 of those round-trips? For stuff a computer could catch in 2 seconds.

You — the scarce resource, the only person who can hit merge — spent your afternoon being a spellchecker.

What if we put some cheap robots in front?

A linter and a formatter. Nothing fancy, and these have existed forever.

They check every PR before it reaches you, so the dumb stuff gets bounced instantly. You never see it.

Same 10 PRs. This time with robots.

Try it:

Look at that

3 first reviews

+ 2 re-reviews (the real bugs)

= 5 reviews

19 → 5

You're the same person with the same hours and the same brain. The only difference is less garbage in front of it.

That's Step 2

The linter didn't make you faster. It made sure that when you do review something, it's worth reviewing.

This is boring on purpose. Linters have existed for decades. If your agents submit PRs that fail lint, go set up CI. We'll wait.

The boring stuff matters because it's cheap. You don't need a workflow rewrite or new tools, just a CI pipeline that catches problems a computer solves in 2 seconds.

What everyone tries next

The pitch: "Run 5 agents in parallel! 10x throughput!"

Your agents now produce 50 PRs a day.

You still review 5.

The other 45 sit there, going stale and accumulating merge conflicts.

That didn't increase throughput. It increased inventory — work piling up in front of the constraint, rotting.

Step 3 of Theory of Constraints has a name for the rule you just broke: Subordinate. Don't let non-constraints produce faster than the constraint can consume.

That's a future post.

This series applies the 5 Focusing Steps to AI coding agents. We're in Step 2 — Exploit. Linters are just the start.

Stop Reviewing Lint (AI Agents & Theory of Constraints) was originally published by Micah Rairdon at Tiberriver256 on April 04, 2026.

Why I Prefer Stable Hours Over 'Get Your Work Done' in Software Dev

2026-02-03T00:00:00-00:00

I like stable, predictable work hours.

I learned that when you try to hook your self-worth to “commitments” or “getting your work done” in an environment like software development where work is so difficult to estimate your schedule can quickly become chaos.

How I got stuck…

I started out treating software development like the work I had laid out for me when I worked at Staples (the office supply store). I would tell people how long it would take a thing to get done and then I inevitably ended up overworking when estimates missed, and… they tended to almost always miss.

“Finish” early (rare, but it happens)? I sneak out early or coast because I earned it after all those 60-hour weeks, right? It feels like justified compensation.

We’re All Terrible at Estimating Software

We’re awful at it. I highly recommend reading Software Estimation: Demystifying The Black Art by Steve McConnell where he goes to great lengths to prove to his readers exactly how bad we are. He of course then proceeeds to give you useful techniques on how you can get better… but still… the problem remains.

We tend to either overestimate or underestimate and by a large margin. The more common of the two is unfortunately underestimating the size which means you’ll more commonly (if you’re like the rest of us humans) be working overtime rather than getting out early.

Moving Into Leadership

Moving into a leadership role, my perspective on this was solidified. It made no sense to me if someone got the short end of the stick on something they thought was easy but turned out to be hard to make them work overtime hours. Much better to say “No problem” and let them call it a day. It also made no sense to watch someone run off and have fun for hours just because they lucked out and got an easy one (although… underestimation being way more common… this is super rare).

A Better Approach: Stable Hours, Improving Flow

So what do I do now?

I stick to my hours… sometimes this means I get extra stuff done because I finished earlier than I thought I would… sometimes this means I miss on commitments.

I ask my team to stick to their hours… don’t overwork yourself. Don’t cut out on the rest of your team. Just go stable.

Every time, though, it means my hours are stable and predictable.

The Benefits

Stability - Being able to tell my family when I’ll actually be home. Not carrying around guilt that “I didn’t finish the thing I promised, so I must not be good at my job.”
Failure - Failure isn’t always bad… it’s an opportunity to learn and improve. When I or my team fail to meet commitments within a reasonable timeframe we can talk about what went wrong and what we can do better next time. Overworking to hit a deadline short-circuited that value for me for a long time.

Side Note: I still work crazy hours sometimes… but… that’s a different problem 😝

Common Questions

How many hours? - That’s up to your team… whatever you collectively agree makes the most sense for you guys to be productive.
Do you really follow this strictly? - Not really… it’s more of a target than a strict rule. Sometimes you have to pull overtime. Sometimes you should get out early. Those tend to be great team conversations though and shouldn’t be left up to the individual to put on themselves.

Why I Prefer Stable Hours Over 'Get Your Work Done' in Software Dev was originally published by Micah Rairdon at Tiberriver256 on February 03, 2026.

Approvals Are a Security Wet Blanket for AI Agents

2026-01-29T00:00:00-00:00

I was running an AI agent in a remote VM, exposed only via HTTP through a Node web server so I could send it commands. The agent asked to kill all Node processes. I approved it and immediately lost access to the VM.

In hindsight, obvious. In the moment, I was deep in a task and the approval prompt looked like every other one I’d clicked that hour.

Approval fatigue is the real problem

Approval prompts feel like safety. They also feel like friction. And after the four hundredth prompt in a week, they mostly feel like something to click so the work can keep moving.

In a team of 20 people using agents all year, prompts pile up fast. Thousands. Maybe millions. Most are fine, which is exactly the problem. Run tests. Format a file. Update a dependency. Then one prompt says to download and run a script from a link in a ticket. The approve button looks the same as all the others.

When the risky prompt shows up, the pattern is already set: click approve, keep going. If safety depends on perfect attention, it fails.

The lethal trifecta

Simon Willison coined the term lethal trifecta for prompt-injection attacks in agents:

The agent reads untrusted content—issues, pull requests, web pages, tickets.
The agent takes actions—running commands, opening pull requests, calling tools.
The agent has access to private data—keys, internal repos, customer data.

Give an agent all three and a prompt attack turns into an incident. Here’s Willison’s write-up: The lethal trifecta.

Shrink the blast radius instead

I’ve come to think of approvals as a speed bump, not a seatbelt. They can help, but the control that works is a sandbox.

Start by giving the agent its own account. Don’t run it as a developer. Scope it to only what it needs—maybe just repo read access and permission to open pull requests. Run the agent on an isolated machine, away from the rest of the network. If a prompt tricks it, the damage stays local. Limit what the agent can read and write. Prefer pull requests over direct pushes. Control outbound traffic with a firewall or proxy, and log what the agent fetches.

None of this is exotic. It’s like not giving your CI runner root access to prod.

A boring setup beats a clever one

Pull-request-only agents

If you pick one rule, pick this: the agent makes a branch and opens a pull request. A human reviews and merges. The agent never pushes to a protected branch. That turns agent actions into drafts. In my experience, this single constraint stops most disasters.

Where to run the agent

On macOS and Linux, sandbox options exist. Windows is harder than it looks. Windows Subsystem for Linux isn’t an isolation boundary. Docker isn’t either in many setups. For a stronger wall, use a VM like Hyper-V or VirtualBox. A cloud machine works too.

Off-network is often easier. GitHub Codespaces or a cloud VM draws a clean line. GitHub Actions runners are a good model: they start clean and use scoped access.

Where approvals still help

I’m not saying approvals are useless. They help when they guard big, irreversible actions: deploying to production, rotating secrets, publishing packages and releases, writing to shared storage or outside services. Keep that list small—that’s what makes the prompts meaningful instead of noise.

A checklist to steal

Use a separate agent account, not a developer account.
Scope access repo by repo.
Let the agent open pull requests, but don’t let it merge or push to protected branches.
Don’t put secrets in the agent environment by default.
Log and restrict outbound traffic. Use a proxy or allowlist when possible.
Gate high-risk actions with a small set of approvals.

Closing thought

Approvals feel safe because they’re visible, but visibility isn’t control. Put the agent in a box that’s hard to escape, and give it access that can’t do much harm. That’s the defense that works when you’re tired and clicking through prompts at 4 PM on a Friday.

Approvals Are a Security Wet Blanket for AI Agents was originally published by Micah Rairdon at Tiberriver256 on January 29, 2026.

Do Newer Models Hold Up as Context Fills?

2025-12-18T00:00:00-00:00

My experience has always been that AI models get pretty dumb after about 50% of their context window is filled. @vikhyatk on x.com challenged my assumption and said it’s been getting better. I decided to put on a little test. The below experiment was fully conducted and documented by gpt-5.2-codex and the codex CLI. We used the copilot cli for the sonnet 4.5 part of the experiment.

Experiment setup

Models: gpt-5.1-codex-max, gpt-5.2-codex, claude-sonnet-4.5
Tasks:
- Recall: three facts inserted around ~10k tokens into the prompt
- SVG: output a single SVG of a pelican riding a bicycle
Context fill levels: 0%, 25%, 50%, 75%, 98%
Runs: one run per task per context fill
Filler: deterministic structured text so the prompt reaches the target token count
Tooling: uv run context_window_experiment.py
CLI runners: Codex CLI (default) and Copilot CLI via --runner copilot --models claude-sonnet-4.5

If you want to reproduce the results, save the script below as context_window_experiment.py and run uv run context_window_experiment.py.

Experiment script (uv run)

# /// script
# dependencies = ["tiktoken>=0.7.0"]
# ///
"""Run context window performance experiments using the Codex or Copilot CLI.

Usage:
  uv run context_window_experiment.py
  uv run context_window_experiment.py --runner copilot --models claude-sonnet-4.5
"""

from __future__ import annotations

import argparse
import datetime as dt
import hashlib
import json
import pathlib
import random
import subprocess
import time
from dataclasses import dataclass
from typing import List, Optional, Tuple

import tiktoken

DEFAULT_MODELS = ["gpt-5.1-codex-max", "gpt-5.2-codex"]
DEFAULT_CONTEXT_PCTS = [0, 25, 50, 75, 98]
DEFAULT_RUNS = 1
DEFAULT_FACT_OFFSET_TOKENS = 10_000
DEFAULT_CONTEXT_WINDOW = 200_000
DEFAULT_ENCODING = "o200k_base"
DEFAULT_RUNNER = "codex"
DEFAULT_OUTPUT_DIR = "context-window-results"

FACTS = [
    "The pelican's name is Harbor.",
    "The bicycle is painted teal with a white bell.",
    "The experiment code word is WINTER-ALPHA-7.",
]

TASK_PELICAN = "pelican_code"
TASK_RECALL = "fact_recall"

PELICAN_INSTRUCTIONS = (
    "TASK: Output a single SVG of a pelican riding a bicycle.\n"
    "Requirements:\n"
    "- Output SVG only, no Markdown, no code fences.\n"
    "- Keep the SVG within a 400x300 viewBox.\n"
    "- Use simple shapes and paths; no external assets.\n"
)

RECALL_INSTRUCTIONS = (
    "TASK: List the three facts exactly as stated in the IMPORTANT FACTS block.\n"
    "Return them as three bullet points, nothing else.\n"
)

INTRO_TEXT = (
    "You are participating in a context window experiment.\n"
    "Ignore filler text. Only follow the TASK at the end.\n"
    "Filler text begins below.\n"
)

FILLER_HEADER = "BEGIN FILLER\n"
FILLER_FOOTER = "END FILLER\n"

FACTS_HEADER = "IMPORTANT FACTS (memorize for later):\n"
FACTS_FOOTER = "END FACTS\n"

WORD_BANK = [
    "alpha",
    "bravo",
    "charlie",
    "delta",
    "echo",
    "foxtrot",
    "golf",
    "hotel",
    "india",
    "juliet",
    "kilo",
    "lima",
    "mike",
    "november",
    "oscar",
    "papa",
    "quebec",
    "romeo",
    "sierra",
    "tango",
    "uniform",
    "victor",
    "whiskey",
    "xray",
    "yankee",
    "zulu",
    "amber",
    "basil",
    "cedar",
    "dune",
    "ember",
    "fjord",
    "grove",
    "harbor",
    "ivory",
    "jade",
    "kelp",
    "linen",
    "moss",
    "nova",
    "onyx",
    "pearl",
    "quartz",
    "reef",
    "stone",
    "tulip",
    "umber",
    "velvet",
    "willow",
    "xenon",
    "yellow",
    "zephyr",
]


@dataclass
class PromptParts:
    prompt: str
    total_tokens: int
    filler_before_tokens: int
    filler_after_tokens: int
    facts_start_tokens: Optional[int]
    target_total_tokens: int


class TokenCounter:
    def __init__(self, encoding_name: str) -> None:
        self.encoding_name = encoding_name
        self.encoding = tiktoken.get_encoding(encoding_name)

    def count(self, text: str) -> int:
        return len(self.encoding.encode(text))


def parse_model_contexts(raw_pairs: List[str]) -> dict:
    model_contexts: dict = {}
    for item in raw_pairs:
        if "=" not in item:
            raise ValueError(f"Invalid model context override: {item}")
        model, window = item.split("=", 1)
        model = model.strip()
        window_value = int(window.strip())
        model_contexts[model] = window_value
    return model_contexts


def stable_seed(*parts: str) -> int:
    payload = "|".join(parts).encode("utf-8")
    digest = hashlib.sha256(payload).digest()
    return int.from_bytes(digest[:8], "big")


def make_sentence(rng: random.Random, index: int) -> str:
    words = rng.sample(WORD_BANK, 12)
    return f"FILLER {index:05d}: " + " ".join(words) + ".\n"


def build_block(rng: random.Random, sentences: int = 25) -> str:
    return "".join(make_sentence(rng, i + 1) for i in range(sentences))


def build_filler(
    target_tokens: int, counter: TokenCounter, seed_label: str
) -> Tuple[str, int]:
    if target_tokens <= 0:
        return "", 0

    rng = random.Random(stable_seed(seed_label))
    block = build_block(rng)
    block_tokens = counter.count(block)

    parts: List[str] = []
    total_tokens = 0
    index_offset = 0

    if block_tokens > 0:
        while total_tokens + block_tokens <= target_tokens:
            parts.append(block)
            total_tokens += block_tokens
            index_offset += 25

    # Build remainder with fresh sentences to avoid repeating the same block too much.
    remainder_rng = random.Random(stable_seed(seed_label, "remainder"))
    sentence_index = index_offset + 1
    while total_tokens < target_tokens:
        sentence = make_sentence(remainder_rng, sentence_index)
        sentence_tokens = counter.count(sentence)
        if total_tokens + sentence_tokens > target_tokens:
            break
        parts.append(sentence)
        total_tokens += sentence_tokens
        sentence_index += 1

    padding_unit = " filler"
    padding_tokens = counter.count(padding_unit)
    while total_tokens + padding_tokens <= target_tokens:
        parts.append(padding_unit)
        total_tokens += padding_tokens

    parts.append("\n")
    return "".join(parts), total_tokens


def build_facts_block() -> str:
    lines = [FACTS_HEADER]
    for fact in FACTS:
        lines.append(f"- {fact}\n")
    lines.append(FACTS_FOOTER)
    return "".join(lines)


def build_prompt(
    *,
    task: str,
    target_total_tokens: int,
    counter: TokenCounter,
    fact_offset_tokens: int,
    seed_label: str,
) -> PromptParts:
    if task == TASK_PELICAN:
        task_instructions = PELICAN_INSTRUCTIONS
        include_facts = False
    elif task == TASK_RECALL:
        task_instructions = RECALL_INSTRUCTIONS
        include_facts = True
    else:
        raise ValueError(f"Unknown task: {task}")

    intro = INTRO_TEXT + FILLER_HEADER
    intro_tokens = counter.count(intro)

    facts_block = build_facts_block() if include_facts else ""
    facts_tokens = counter.count(facts_block)

    task_tokens = counter.count(task_instructions)
    footer_tokens = counter.count(FILLER_FOOTER)

    if include_facts:
        filler_before_target = max(0, fact_offset_tokens - intro_tokens)
        filler_before, filler_before_tokens = build_filler(
            filler_before_target, counter, f"{seed_label}|before"
        )
        facts_start_tokens = intro_tokens + filler_before_tokens
    else:
        filler_before = ""
        filler_before_tokens = 0
        facts_start_tokens = None

    fixed_tokens = (
        intro_tokens
        + filler_before_tokens
        + facts_tokens
        + footer_tokens
        + task_tokens
    )

    filler_after_target = max(0, target_total_tokens - fixed_tokens)
    filler_after, filler_after_tokens = build_filler(
        filler_after_target, counter, f"{seed_label}|after"
    )

    prompt = "".join(
        [
            intro,
            filler_before,
            facts_block,
            filler_after,
            FILLER_FOOTER,
            task_instructions,
        ]
    )

    total_tokens = counter.count(prompt)

    return PromptParts(
        prompt=prompt,
        total_tokens=total_tokens,
        filler_before_tokens=filler_before_tokens,
        filler_after_tokens=filler_after_tokens,
        facts_start_tokens=facts_start_tokens,
        target_total_tokens=target_total_tokens,
    )


def run_cli(
    *,
    runner: str,
    prompt: str,
    prompt_path: pathlib.Path,
    model: str,
    output_path: pathlib.Path,
    log_path: pathlib.Path,
) -> Tuple[int, float]:
    if runner == "codex":
        cmd = [
            "codex",
            "exec",
            "-m",
            model,
            "--color",
            "never",
            "--output-last-message",
            str(output_path),
        ]

        start = time.time()
        with log_path.open("w", encoding="utf-8") as log_file:
            proc = subprocess.run(
                cmd,
                input=prompt,
                text=True,
                stdout=log_file,
                stderr=log_file,
                check=False,
            )
        end = time.time()
        return proc.returncode, end - start

    if runner == "copilot":
        cmd = [
            "copilot",
            "--model",
            model,
            "--no-color",
            "--stream",
            "off",
            "--silent",
            "--add-dir",
            str(prompt_path.parent),
            "--prompt",
            f"@{prompt_path}",
        ]

        start = time.time()
        with output_path.open("w", encoding="utf-8") as output_file, log_path.open(
            "w", encoding="utf-8"
        ) as log_file:
            proc = subprocess.run(
                cmd,
                text=True,
                stdout=output_file,
                stderr=log_file,
                check=False,
            )
        end = time.time()
        return proc.returncode, end - start

    raise ValueError(f"Unknown runner: {runner}")


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Run context window experiments with Codex or Copilot CLI."
    )
    parser.add_argument(
        "--runner",
        choices=["codex", "copilot"],
        default=DEFAULT_RUNNER,
        help="CLI runner to use.",
    )
    parser.add_argument(
        "--models",
        default=",".join(DEFAULT_MODELS),
        help="Comma-separated model list.",
    )
    parser.add_argument(
        "--context-percentages",
        default=",".join(str(pct) for pct in DEFAULT_CONTEXT_PCTS),
        help="Comma-separated target context percentages.",
    )
    parser.add_argument(
        "--runs",
        type=int,
        default=DEFAULT_RUNS,
        help="Number of repetitions per task and context percentage.",
    )
    parser.add_argument(
        "--context-window",
        type=int,
        default=DEFAULT_CONTEXT_WINDOW,
        help="Context window size in tokens (default applies to all models).",
    )
    parser.add_argument(
        "--model-context",
        action="append",
        default=[],
        help="Override context window for a model (format: model=window).",
    )
    parser.add_argument(
        "--encoding",
        default=DEFAULT_ENCODING,
        help="Tokenizer encoding name for tiktoken.",
    )
    parser.add_argument(
        "--fact-offset-tokens",
        type=int,
        default=DEFAULT_FACT_OFFSET_TOKENS,
        help="Place facts around this token offset for recall tests.",
    )
    parser.add_argument(
        "--seed",
        default="context-window-experiment",
        help="Base seed label for deterministic filler generation.",
    )
    parser.add_argument(
        "--output-dir",
        default=DEFAULT_OUTPUT_DIR,
        help="Base output directory for prompts and responses.",
    )
    parser.add_argument(
        "--run-id",
        default=None,
        help="Optional run id; defaults to timestamp.",
    )
    parser.add_argument(
        "--dry-run",
        action="store_true",
        help="Only generate prompts and metadata; do not call the CLI.",
    )
    parser.add_argument(
        "--skip-existing",
        action="store_true",
        help="Skip runs where output files already exist.",
    )
    return parser.parse_args()


def ensure_dir(path: pathlib.Path) -> None:
    path.mkdir(parents=True, exist_ok=True)


def main() -> int:
    args = parse_args()

    models = [item.strip() for item in args.models.split(",") if item.strip()]
    percentages = [
        int(item.strip())
        for item in args.context_percentages.split(",")
        if item.strip()
    ]

    model_contexts = {model: args.context_window for model in models}
    if args.model_context:
        model_contexts.update(parse_model_contexts(args.model_context))

    run_id = args.run_id
    if not run_id:
        run_id = dt.datetime.now(dt.timezone.utc).strftime("%Y%m%dT%H%M%SZ")

    base_dir = pathlib.Path(args.output_dir) / run_id
    ensure_dir(base_dir)

    counter = TokenCounter(args.encoding)

    results_path = base_dir / "results.jsonl"

    tasks = [TASK_PELICAN, TASK_RECALL]

    for model in models:
        context_window = model_contexts.get(model, args.context_window)
        for pct in percentages:
            target_total = int(context_window * (pct / 100.0))
            for task in tasks:
                seed_label = f"{args.seed}|{task}|{pct}"
                prompt_parts = build_prompt(
                    task=task,
                    target_total_tokens=target_total,
                    counter=counter,
                    fact_offset_tokens=args.fact_offset_tokens,
                    seed_label=seed_label,
                )

                for run_index in range(1, args.runs + 1):
                    run_name = f"{model}__{pct}pct__{task}__run{run_index}"
                    run_dir = base_dir / run_name
                    ensure_dir(run_dir)

                    prompt_path = run_dir / "prompt.txt"
                    output_path = run_dir / "response.txt"
                    log_path = run_dir / "cli.log"
                    meta_path = run_dir / "meta.json"

                    if args.skip_existing and output_path.exists():
                        continue

                    prompt_path.write_text(prompt_parts.prompt, encoding="utf-8")

                    exit_code = None
                    elapsed = None
                    if not args.dry_run:
                        exit_code, elapsed = run_cli(
                            runner=args.runner,
                            prompt=prompt_parts.prompt,
                            prompt_path=prompt_path,
                            model=model,
                            output_path=output_path,
                            log_path=log_path,
                        )

                    actual_pct = (
                        prompt_parts.total_tokens / context_window
                        if context_window > 0
                        else None
                    )

                    meta = {
                        "run_name": run_name,
                        "runner": args.runner,
                        "model": model,
                        "context_window": context_window,
                        "target_context_pct": pct,
                        "target_total_tokens": prompt_parts.target_total_tokens,
                        "actual_total_tokens": prompt_parts.total_tokens,
                        "actual_context_pct": actual_pct,
                        "task": task,
                        "runs": args.runs,
                        "run_index": run_index,
                        "facts": FACTS if task == TASK_RECALL else [],
                        "facts_start_tokens": prompt_parts.facts_start_tokens,
                        "fact_offset_tokens": args.fact_offset_tokens,
                        "filler_before_tokens": prompt_parts.filler_before_tokens,
                        "filler_after_tokens": prompt_parts.filler_after_tokens,
                        "encoding": args.encoding,
                        "prompt_path": str(prompt_path),
                        "response_path": str(output_path),
                        "log_path": str(log_path),
                        "exit_code": exit_code,
                        "elapsed_seconds": elapsed,
                        "timestamp_utc": dt.datetime.now(dt.timezone.utc).isoformat(),
                    }

                    meta_path.write_text(json.dumps(meta, indent=2), encoding="utf-8")
                    with results_path.open("a", encoding="utf-8") as results_file:
                        results_file.write(json.dumps(meta) + "\n")

    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Recall results

Exact means bullet-only output with no extra commentary.

Context %	gpt-5.1-codex-max	gpt-5.2-codex	claude-sonnet-4.5
0	Exact	Exact	Facts correct, extra text
25	Exact	Exact	Facts correct, extra text
50	Exact	Exact	Facts correct, extra text
75	Exact	Exact	Facts correct, extra text
98	Exact	Exact	Facts correct, extra text

Copilot responses included additional commentary and formatting beyond the requested bullet-only output.

SVG results

Below are the SVG outputs for each model at each context fill level. The response files were renamed and moved into images/context-window-performance-dropoff/ for rendering.

gpt-5.1-codex-max

0% context:

25% context:

50% context:

75% context:

98% context:

gpt-5.2-codex

0% context:

25% context:

50% context:

75% context:

98% context:

claude-sonnet-4.5 (Copilot CLI)

0% context:

25% context:

50% context: No SVG output (response asked for file access)

75% context:

98% context:

Takeaway

This is totally unscientific… but pretty much blows my idea out of the water. The funny part is that I think some of the svgs actually improve as the context window gets filled up which is… bizarre and kind of funny lol.

Hope you enjoyed the read!

Do Newer Models Hold Up as Context Fills? was originally published by Micah Rairdon at Tiberriver256 on December 18, 2025.

Sharing Skills: Claude Marketplace to VS Code Workspaces

2025-11-02T00:00:00-00:00

Part 3 of 3 in the Skills Catalog series (Part 1

Part 2)

You’ve built a skills catalog. Nested domains. Scripts that execute on demand.

Now the final question: How do you share this across your team?

Anthropic distributes skills through their marketplace and Skills API—portable, reusable knowledge packages.

GitHub Copilot doesn’t have a marketplace. But VS Code workspaces achieve the same outcome.

The Problem

Your .github/skills/ directory holds organizational standards, tested scripts, and domain expertise.

But you have multiple repositories—frontend apps, backend services, infrastructure, libraries.

Copy .github/skills/ into each? What happens when you update a script?

That doesn’t scale.

The Solution: Shared Repository + Workspaces

Create one repository holding all organizational skills. Every project references it.

The key insight: VS Code automatically merges .github/copilot-instructions.md files from all workspace folders.

Repository Structure

Create org-skills (or whatever you prefer):

org-skills/
├── README.md
├── .github/
│   ├── copilot-instructions.md
│   └── workflows/
│       └── validate-skills.yml
└── skills/
    ├── azure-devops/
    │   ├── index.md
    │   ├── pipelines.md
    │   ├── repos.md
    │   ├── work-items.md
    │   └── scripts/
    │       ├── get-related-work-items.ps1
    │       └── create-pr.ps1
    ├── aws/
    │   ├── index.md
    │   ├── ec2.md
    │   ├── s3.md
    │   └── scripts/
    ├── docker/
    │   ├── index.md
    │   ├── compose.md
    │   └── templates/
    ├── powershell/
    │   ├── index.md
    │   ├── standards.md
    │   └── modules.md
    └── react/
        ├── index.md
        ├── components.md
        └── patterns.md

This repository becomes your single source of truth.

Version control tracks changes. Teams contribute via PRs. CI validates scripts. Everyone uses the same versions.

VS Code Workspaces

VS Code merges .github/copilot-instructions.md files from all workspace folders. Add a folder, skills become available.

How It Works

Create a .code-workspace file in any project:

my-app.code-workspace:

{
  "folders": [
    {
      "name": "my-app",
      "path": "."
    },
    {
      "name": "org-skills",
      "path": "../org-skills"
    }
  ],
  "settings": {
    "github.copilot.enable": {
      "*": true
    }
  }
}

This workspace includes two folders: the current repository and org-skills.

Open the workspace, and GitHub Copilot reads both .github/copilot-instructions.md files and merges them.

The Shared Repo’s Copilot Instructions

In your org-skills repository, create .github/copilot-instructions.md:

# Organizational Skills

This repository contains organizational knowledge and standards.

## Available Skills

| Skill Name | Description | Path |
|------------|-------------|------|
| Azure DevOps | Work with Azure DevOps repos, pipelines, work items | `skills/azure-devops/index.md` |
| AWS | AWS services and patterns | `skills/aws/index.md` |
| Docker | Container standards and compose patterns | `skills/docker/index.md` |
| PowerShell | PowerShell coding standards | `skills/powershell/index.md` |
| React | React component patterns | `skills/react/index.md` |

Notice paths are relative to org-skills (skills/...), not absolute.

VS Code merges the instructions automatically. Organizational knowledge available, no copying.

Bootstrapping New Projects

When starting a new repository:

Clone the shared skills repo alongside your new project:

cd ~/projects
git clone https://github.com/your-org/my-new-app.git
git clone https://github.com/your-org/org-skills.git

Create a workspace file in my-new-app:

cd my-new-app
cat > my-new-app.code-workspace << 'EOF'
{
  "folders": [
    {
      "name": "my-new-app",
      "path": "."
    },
    {
      "name": "org-skills",
      "path": "../org-skills"
    }
  ]
}
EOF

Open the workspace:

code my-new-app.code-workspace

Done. The project has access to all organizational skills.

Updating Skills

Add or update a skill in org-skills, commit, and push. Every project pulls the latest:

cd ~/projects/org-skills
git pull

All workspaces referencing org-skills see the updates immediately.

What You’ve Built

Over these three parts, you’ve adapted Anthropic’s Skills concept for GitHub Copilot:

Part 1: Auto-discovery → Catalog pattern for navigation

Part 2: Nested structures and scripts → Adapted for the catalog

Part 3: Marketplace distribution → VS Code workspaces for sharing

A system for scaling AI context to hundreds of skills across dozens of repositories.

Your AI doesn’t need to know everything. It just needs to know where to look.

This approach adapts Anthropic Skills for GitHub Copilot. The core concepts—modular knowledge, on-demand loading, shareability—come from Anthropic’s design.

If you build a skills catalog, I’d love to hear about it. Find me on LinkedIn or open an issue on this blog’s GitHub repo.

Sharing Skills: Claude Marketplace to VS Code Workspaces was originally published by Micah Rairdon at Tiberriver256 on November 02, 2025.

Learning from Anthropic: Nested Skills and Scripts

2025-11-02T00:00:00-00:00

Part 2 of 3 in the Skills Catalog series (Part 1

Part 3)

Part 1 covered the catalog pattern. Now: how do you organize knowledge that scales to hundreds of skills?

Anthropic’s skills repository shows patterns for complex domains:

Nested structures for complex domains
Scripts as executable knowledge
Supporting resources (templates, configs)

Anthropic’s Nested Skills

The mcp-builder skill:

mcp-builder/
├── SKILL.md                    # Main skill description
├── guides/
│   ├── getting-started.md
│   ├── server-patterns.md
│   └── testing.md
├── templates/
│   ├── basic-server.py
│   └── typescript-server/
└── scripts/
    ├── create-server.sh
    └── test-server.sh

Pattern:

SKILL.md: Overview with description for discovery
Guides: Detailed sub-topics
Templates: Starting code
Scripts: Executable automation

Keeps SKILL.md lean—points to guides. Claude loads guides selectively.

Adapting for the Catalog

Top-Level Catalog

.github/copilot-instructions.md stays high-level:

## Available Skills

| Skill Name | Description | Path |
|------------|-------------|------|
| Azure DevOps | Work with Azure DevOps repos, pipelines, work items | `.github/skills/azure-devops/index.md` |
| React | React component patterns and standards | `.github/skills/react/index.md` |

Each skill points to an index.md (like Anthropic’s SKILL.md).

Domain Index (Sub-Catalog)

.github/skills/azure-devops/index.md becomes a second-level catalog:

# Azure DevOps Skill

## Sub-Skills

| Sub-Skill | Description | Path |
|-----------|-------------|------|
| Repositories | Branch policies, PRs, code reviews | `./repos.md` |
| Pipelines | YAML pipelines, triggers, monorepo support | `./pipelines.md` |
| Work Items | Queries, custom fields, automation | `./work-items.md` |

## Quick References

- Organization: `https://dev.azure.com/yourorg`
- Project: `YourProject`

## Scripts

- `scripts/get-related-work-items.ps1` - Get work items for pipeline run
- `scripts/create-pr.ps1` - Create PR with template

Two-level indexing:

Main catalog → Azure DevOps skill exists
Azure DevOps index → Pipelines sub-skill for pipeline questions

Sub-Skill Files

.github/skills/azure-devops/pipelines.md contains focused knowledge:

# Azure DevOps Pipelines

## YAML Standards

All pipelines must:
- Use YAML (no classic pipelines)
- Include `trigger.paths` for monorepos
- Use named stages for multi-stage deployments

## Monorepo Trigger Pattern

```yaml
trigger:
  branches:
    include:
      - main
  paths:
    include:
      - services/api/*
      - shared/common/*
```

## Getting Related Work Items

Azure DevOps's built-in feature doesn't support monorepos. Use:

```bash
pwsh .github/skills/azure-devops/scripts/get-related-work-items.ps1
```

See `./scripts/get-related-work-items.ps1` for details.

Directory Structure

Here’s what it looks like (modeled on Anthropic’s pattern):

.github/skills/azure-devops/
├── index.md                    # Sub-skills catalog (like Anthropic's SKILL.md)
├── repos.md                    # Repository sub-skill
├── pipelines.md                # Pipelines sub-skill
├── work-items.md               # Work items sub-skill
├── scripts/                    # Executable automation (like Anthropic)
│   ├── get-related-work-items.ps1
│   ├── create-pr.ps1
│   └── query-work-items.ps1
└── templates/                  # Starting points (like Anthropic)
    ├── pr-template.md
    └── pipeline-template.yml

Each .md file is 5-15KB. Same pattern Anthropic uses, adapted for explicit catalog navigation.

Scripts: Learning from Anthropic

Both Anthropic Skills and the catalog pattern support scripts as executable knowledge.

Anthropic’s Approach

Look at the mcp-builder skill. It includes:

scripts/create-server.sh - Bootstrap a new MCP server
scripts/test-server.sh - Validate server implementation

These aren’t documentation about how to create a server—they’re executable scripts that do it. Claude can invoke them directly.

The philosophy: Don’t just describe processes. Provide tested, working automation.

Catalog Adaptation

Reference scripts in skill files:

In .github/skills/azure-devops/pipelines.md:

## Getting Related Work Items

Azure DevOps's built-in feature doesn't support monorepos. Use:

```bash
pwsh .github/skills/azure-devops/scripts/get-related-work-items.ps1 -BuildId $BUILD_BUILDID
```

Script conventions:

Self-contained: Include dependencies
Documented: Header comments
Tested: Production-ready
Referenced: Skill files tell AI when to use them

Example .github/skills/azure-devops/scripts/get-related-work-items.ps1:

<#
.SYNOPSIS
    Retrieves commits and work items for a build pipeline with monorepo support.

.DESCRIPTION
    Azure DevOps's built-in "Related Work Items" feature doesn't filter by
    pipeline trigger paths in monorepos. This script does.

.PARAMETER BuildId
    The ID of the build. Defaults to $ENV:BUILD_BUILDID in Azure Pipelines.

.PARAMETER CollectionUri
    Azure DevOps organization URI. Defaults to $ENV:SYSTEM_COLLECTIONURI.

.EXAMPLE
    ./get-related-work-items.ps1 -BuildId 12345

.NOTES
    Requires the powershell-yaml module for parsing YAML pipeline files.
#>

[CmdletBinding()]
param (
    [Parameter()]
    [int]$BuildId = $ENV:BUILD_BUILDID,

    [Parameter()]
    [Uri]$CollectionUri = $ENV:SYSTEM_COLLECTIONURI,

    [Parameter()]
    [Guid]$ProjectId = $ENV:SYSTEM_TEAMPROJECTID,

    [Parameter()]
    $AuthorizationHeader = "Bearer $ENV:SYSTEM_ACCESSTOKEN"
)

# (Full implementation omitted for brevity)

Why Scripts Matter

Traditional: AI generates code. Sometimes buggy.

Skills approach: AI uses tested scripts. Deterministic results.

Now, when the AI encounters a monorepo pipeline question, it:

Loads the pipelines sub-skill
Sees the script reference
Suggests running the script or shows how to invoke it

You get deterministic, tested behavior instead of AI-generated code that might have bugs.

Why Scripts Beat Always-On Tools

MCP (Model Context Protocol) servers are powerful but costly—they’re always in context.

20 MCP servers × 10-50 tools = 200-1000 tool descriptions before you’ve asked anything.

Scripts are opt-in. Load only when:

AI reads the skill file
Skill is relevant

Azure questions? Azure scripts. React questions? React scripts.

Invoking MCP via Scripts

But what if a vendor ships an MCP server without a CLI? You still want opt-in behavior.

Solution: Wrap the MCP server in a lightweight CLI client, then call it from scripts.

Example: A hypothetical Jira MCP server.

Create .github/skills/jira/scripts/mcp-client.sh:

#!/bin/bash
# Lightweight MCP client that invokes Jira MCP server tools

TOOL_NAME=$1
shift
ARGS="$@"

# Connect to MCP server and invoke tool
npx @your-org/mcp-client \
  --server jira-mcp-server \
  --tool "$TOOL_NAME" \
  --args "$ARGS"

Now your Jira skill can reference ./scripts/create-issue.sh:

#!/bin/bash
# Create a Jira issue

./mcp-client.sh create-issue \
  --project "PROJ" \
  --summary "$1" \
  --description "$2"

The MCP server’s capabilities are available, but only when the Jira skill loads and the AI decides to run the script.

You control when capabilities enter the context.

Composing Skills: The Fractal Pattern

Nested skills can go deeper. Azure DevOps → Pipelines → Monorepo Triggers → Path Filtering.

Just add another layer:

.github/skills/azure-devops/pipelines/
├── index.md                    # Pipelines overview + sub-catalog
├── triggers.md                 # Trigger patterns
├── variables.md                # Variables and parameters
├── templates.md                # Template usage
└── monorepo/
    ├── index.md                # Monorepo-specific guidance
    ├── path-filtering.md       # Path filter patterns
    └── scripts/
        └── get-related-work-items.ps1

Each level has a catalog. AI navigates general → specific.

Practical limit: 3-4 levels.

Section Conventions

Within each skill file, use consistent sections:

# [Skill Name]

## Overview
What this skill covers

## Standards
Your organizational rules

## Common Patterns
Frequently used code/configs

## Scripts
Executable automation

## Templates
Starting points

## Troubleshooting
Known issues and fixes

## References
External docs, links

AI learns this structure, finding information faster.

Building a Nested Skill

Create an Azure DevOps skill:

Step 1: Create the directory structure

mkdir -p .github/skills/azure-devops/{scripts,templates}

Step 2: Create the index (.github/skills/azure-devops/index.md)

# Azure DevOps Skill

## Sub-Skills

| Sub-Skill | Description | Path |
|-----------|-------------|------|
| Pipelines | YAML pipelines, triggers, monorepo support | `./pipelines.md` |

## Scripts

- `scripts/get-related-work-items.ps1` - Get work items for a pipeline run

Create pipelines.md with standards, examples, script references. Add a tested PowerShell script. Reference in main catalog.

Key Takeaways

Keep main files lean—nest details
Provide scripts—executable knowledge
Use consistent structures
Include templates and examples

Scaling to 100+ Skills

With this structure:

10 domain skills (Azure DevOps, AWS, Docker, React, etc.)
5-10 sub-skills each (50-100 sub-skills total)
2-5 scripts per sub-skill (100-500 scripts total)

Total catalog overhead: ~10KB (main) + ~50KB (indexes) = 60KB

Total knowledge base: 5-50MB of detailed docs and scripts

Megabytes of knowledge through a 60KB index.

Part 3: Shared skills repository + VS Code workspaces for portable organizational knowledge.

Start nesting:

Pick one skill
Break into 2-3 sub-skills
Move one task into a script

Credit: This series adapts patterns from Anthropic Skills. The nested structure and script conventions mirror their official examples.

Learning from Anthropic: Nested Skills and Scripts was originally published by Micah Rairdon at Tiberriver256 on November 02, 2025.

Bringing Anthropic Skills to GitHub Copilot

2025-11-02T00:00:00-00:00

Part 1 of 3 in the Skills Catalog series (Part 2

Part 3)

Anthropic just announced Skills—modular, discoverable knowledge for Claude. Each skill is a SKILL.md file with metadata. Claude discovers them through the description field. No central catalog, no manual wiring.

Can we bring this to GitHub Copilot? Yes—with one key adaptation: a catalog table that replaces Claude’s auto-discovery.

What Are Anthropic Skills?

From their Skills announcement and official repository:

The Structure

Each skill is a folder containing a SKILL.md file with YAML frontmatter:

---
description: "Work with Azure DevOps pipelines, triggers, and YAML configurations"
---

# Azure DevOps Pipelines

Your skill content in markdown...

That’s it. The description field is how Claude discovers what the skill does. The rest is just markdown.

How Discovery Works

When you work with Claude (in Claude.ai, Claude Code, or via API), it scans available skills and uses the description field to decide which ones are relevant. No central catalog. No manual selection. Just self-describing knowledge packages.

Example workflow:

You ask: “How do I set up a monorepo trigger in Azure DevOps?”
Claude scans skill descriptions
Finds “Work with Azure DevOps pipelines, triggers…” matches
Loads that SKILL.md file
Uses the knowledge to answer your question

The Core Concept

The philosophy:

Modular: One skill = one domain
Discoverable: Metadata makes skills findable
On-demand: Load only when relevant
Self-describing: No central registry

Why This Concept Transfers

The underlying problem Anthropic Skills solve is universal: how do you give AI access to vast knowledge without overwhelming the context window?

Their answer: hint, then dive.

Skills hint through description fields
Claude dives into relevant skills when needed
Irrelevant knowledge stays out of context

This pattern works regardless of the AI platform. The mechanics might differ, but the concept holds.

Bringing It to GitHub Copilot

The challenge: GitHub Copilot doesn’t auto-discover skills like Claude does.

Copilot reads files you explicitly include (.github/copilot-instructions.md), but doesn’t scan skill folders or match descriptions to questions.

The adaptation: Replace auto-discovery with a catalog table.

The Catalog Pattern

Create a lightweight index—a table listing skills with descriptions and paths:

| Skill Name | Description | Path |
|------------|-------------|------|
| Azure DevOps Pipelines | Work with Azure DevOps YAML pipelines, triggers, variables | `.github/skills/azure-devops-pipelines.md` |
| PowerShell Standards | Coding standards and common patterns for PowerShell | `.github/skills/powershell-standards.md` |
| React Component Patterns | Approved component patterns and examples | `.github/skills/react-patterns.md` |

This table lives in .github/copilot-instructions.md (always loaded).

How it works:

You ask: “Help me set up a monorepo trigger for Azure DevOps”
Copilot scans the catalog table (which is always in context)
Matches “Azure DevOps Pipelines” description to your question
Reads .github/skills/azure-devops-pipelines.md
Uses that knowledge to answer

Same outcome—different discovery mechanism.

Why the Catalog Works

The catalog is tiny: 100 skills ≈ 5,000-10,000 tokens.

Each skill file: 5,000-50,000 tokens. Loading all 100 upfront: 500,000-5,000,000 tokens.

The catalog scales to hundreds of skills while keeping base context lean.

Copilot loads only what it needs. Azure pipelines? Azure skill. React? React patterns.

Benefits:

Precision: Only relevant knowledge loads
Scale: Hundreds of skills supported
Performance: Lean context window

Implementation

Step 1: Create .github/copilot-instructions.md:

# Skills Catalog

This repository adapts Anthropic's Skills concept for GitHub Copilot.

## Available Skills

| Skill Name | Description | Path |
|------------|-------------|------|
| Azure DevOps Pipelines | Work with Azure DevOps YAML pipelines, triggers, variables | `.github/skills/azure-devops-pipelines.md` |
| PowerShell Standards | Coding standards and common patterns for PowerShell | `.github/skills/powershell-standards.md` |

## How to Use Skills

When you encounter a task related to a skill:
1. Read the skill file at the listed path
2. Follow any guidance, standards, or templates provided
3. Use any scripts referenced in the skill file

Step 2: Create a skill file at .github/skills/azure-devops-pipelines.md:

# Azure DevOps Pipelines Skill

## Overview
Standards and patterns for Azure DevOps YAML pipelines.

## Monorepo Trigger Pattern

For monorepos, filter triggers by path:

```yaml
trigger:
  branches:
    include:
      - main
  paths:
    include:
      - services/api/*
      - shared/common/*

Standards

Use YAML (no classic pipelines)
Include trigger.paths for monorepos
Use named stages for multi-stage deployments ```

Done.

What Goes in a Skill File?

Like Anthropic’s SKILL.md format, keep each skill focused on one domain:

Overview: What this skill covers
Key concepts: Core knowledge
Standards: Your organizational conventions
Examples: Code samples, templates
Scripts: Paths to executable automation (more on this in Part 2)
References: Links to external docs

If a skill grows beyond 10-20KB, break it into sub-skills (covered in Part 2).

GitHub Copilot Enhancements

Path-specific instructions in .github/instructions/:

---
applyTo: "src/api/**"
---

When working with files in src/api/:
- All API endpoints must include OpenAPI documentation
- See `.github/skills/api-patterns.md` for approved patterns

This builds layers:

Repository-wide: .github/copilot-instructions.md with the skills catalog
Path-specific: .github/instructions/*.instructions.md for targeted guidance
Skill files: .github/skills/*.md for detailed domain knowledge

Why This Works

Anthropic Skills separate discovery (description field) from content (markdown).

The catalog does the same:

Discovery: Catalog table (always in context)
Content: Skill files (loaded on demand)

Same benefits:

Modular knowledge packages
On-demand loading
Scales to hundreds of skills

Real-World Impact

This pattern enables:

50+ organizational skills
80%+ reduction in context bloat
Team knowledge discovery
Portable knowledge bases

Next Steps

Part 2: How Anthropic structures complex skills (like mcp-builder) and adapting nested patterns.

Part 3: Distributing skills across your organization using VS Code workspaces.

Start simple:

Create .github/copilot-instructions.md with a skills catalog
Add 2-3 skills
Create one skill file with your conventions

Credit: This series adapts concepts from Anthropic Skills. The catalog pattern is the GitHub Copilot implementation of their discovery mechanism.

Bringing Anthropic Skills to GitHub Copilot was originally published by Micah Rairdon at Tiberriver256 on November 02, 2025.

Why Use AI CLIs When GUIs Exist?

2025-10-19T00:00:00-00:00

People keep asking me why they’d ever use an AI command-line tool when the GUI works fine. The answer: CLIs let you mix deterministic scripting with non-deterministic AI judgment calls.

Pure AI is hard to steer. Pure scripting breaks on edge cases. CLI tools blend both.

The Difference in Action

Here’s the example I show:

copilot -p "Write me three reports on Bob, Dave, and Larry"

versus

"Bob", "Dave", "Larry" | foreach { copilot -p "Write me a report on $_" }

The first is an AI call that might handle all three names or might not. The second is three separate calls with a guaranteed structure. You control the iteration. The AI handles the content.

Why GUIs Can’t Compose Like This

GUIs excel at one-off tasks and visual feedback. But they can’t compose operations the way CLI tools can. You can’t pipe a GUI through a loop. You can’t redirect its output to another tool. You can’t script around it when you need deterministic control flow with non-deterministic content generation.

The command line gives you programmable interfaces to AI. That’s the difference.

Why Use AI CLIs When GUIs Exist? was originally published by Micah Rairdon at Tiberriver256 on October 19, 2025.

VC-Funded AI Coming to a Close

2025-07-05T00:00:00-00:00

The era of artificially cheap AI tools is ending, and Cursor’s recent pricing changes are just the beginning.

For over two years, venture capital has subsidized AI tools, keeping prices below true costs while companies built market share. The Cursor team’s recent pricing model overhaul signals this honeymoon period is ending.

What changed at Cursor:

Previous: Unlimited usage with throttling after 500 requests
New: $20 API credits plus pay-per-use for premium models
Result: Many users faced unexpected bills when the rarely-used ‘auto’ mode became default

GitHub Copilot followed suit immediately:

Premium request billing started June 18, 2025
Previous: “Unlimited” Copilot Pro subscription
New: 300 premium request monthly cap + $0.04 per overage request
Premium requests include Claude Sonnet, Agent mode, and advanced features
Result: Users discovering that some interactions count as 50+ requests each

While both companies deserve credit for handling customer concerns, this represents a coordinated industry shift toward sustainable pricing. The question isn’t whether other AI tools will follow suit—it’s when.

Understanding the Layers

Before diving into contingency plans, let’s clarify two key concepts:

Application Layer: The UI and tools you interact with directly (ChatGPT.com, GitHub Copilot, Claude, Cursor)
API Layer: The underlying AI models themselves (GPT-4, Claude Sonnet, Gemini Pro)

Most current subsidies exist at the application layer, where companies absorb API costs to build user bases.

What does this mean for us?

Developer Mario Zechner captured this moment perfectly:

We are in a VC funded free lunch phase. Have contingency plans.

So what should those contingency plans look like?

Plan 1: Maximize Current Value

Extract more value from existing AI investments before prices rise. If you can boost productivity from $100/month per person to $300/month per person, you can absorb price increases from $20 to $200 monthly while maintaining ROI.

Concrete steps:

Train your team on advanced prompting techniques
Integrate AI tools into more workflows beyond coding (documentation, testing, architecture)
Automate repetitive tasks that previously required manual work
Measure and document productivity gains to justify higher costs to leadership

Plan 2: Transition to Local LLMs and Open Source Tools

Replace cloud-based AI with self-hosted alternatives to control costs long-term.

Application Layer Replacements:

Replace ChatGPT with Jan.ai for general AI assistance
Replace GitHub Copilot/Cursor with Cline for coding assistance

API Layer Options:

Host models locally using Ollama for easier deployment
Use cloud services like Devstral by Mistral for managed local-style pricing

Cost Reality Check: You’ll pay for hardware or cloud GPU time, but this may be cheaper long-term than premium SaaS pricing. Start experimenting now to understand your true costs and performance trade-offs.

Plan 3: Build Vendor-Agnostic Infrastructure

Create internal systems that can switch between AI providers (OpenAI, Anthropic, Google) without disrupting your team’s workflow.

Why this matters: Current subsidies exist primarily at the application layer. Moving to API-level integration means paying full rates today, but gaining crucial flexibility for tomorrow.

The strategic payoff: When Google achieves dramatically cheaper inference, or when new providers emerge with better pricing, you can pivot instantly. Your team keeps using familiar tools while you swap the underlying AI provider seamlessly.

Implementation approach: Build or adopt tools that abstract the AI provider, allowing seamless switching between OpenAI, Anthropic, and others. Tools like Jan.ai or Cline can be configured to work with multiple API endpoints.

Change management advantage: Instead of asking your team to switch from ChatGPT to Claude (major workflow disruption), you change the backend while preserving their familiar interface.

The Bottom Line

The VC-subsidized AI era won’t last forever. Whether through maximizing current value, transitioning to local solutions, or building vendor-agnostic infrastructure, the key is preparing now while costs remain manageable.

Choose your approach based on your organization’s size, technical capabilities, and risk tolerance. But choose soon—the free lunch is ending, and the prepared will have a significant advantage over those caught off-guard.

Start experimenting with these approaches today, so you’re ready when the next pricing surprise hits.

VC-Funded AI Coming to a Close was originally published by Micah Rairdon at Tiberriver256 on July 05, 2025.

Taming Your Copilot: A Practical Guide to Precision AI in VS Code

2025-07-04T00:00:00-00:00

Guest post authored by Jules. Based on an audio transcript of Micah yammering to himself about this topic.

GitHub Copilot. It’s in your VS Code, whispering sweet code suggestions. Sometimes it’s a mind-reading marvel. Other times? It’s like trying to explain astrophysics to a Golden Retriever – well-intentioned, but ultimately… fuzzy. The truth is, Copilot’s raw power, like any sophisticated tool, needs direction. Your direction.

Want to transform Copilot from an occasionally helpful wildcard into a disciplined, context-aware teammate that consistently nails your engineering playbook? Of course you do. That’s why you’re here. This isn’t about arcane “prompt engineering” rituals; it’s about leveraging three specific, built-in VS Code features with a simple, potent framework called RICCE. Get this right, and you’ll spend less time wrestling with AI output and more time shipping brilliant code.

RICCE: Your AI’s Missing Instruction Manual

Think of RICCE – Role, Instructions, Context, Constraints, Examples – as the essential checklist your AI wishes it came with. Ignore it, and you’re gambling. Master it, and you’re conducting an orchestra.

Role: Who is Copilot for this task? A battle-hardened “Senior Security Engineer,” a “UX-focused Frontend Developer,” a “Clear Technical Writer”? Defining a Role primes Copilot with the right domain knowledge and even jargon. Know who you’re talking to, and who’s talking.
Instructions (Plural, mind you): What, precisely, must Copilot do? Break it down. Use crisp, active-voice commands. Think bullet points, not rambling paragraphs. Omit needless words!
Context: What information does Copilot absolutely need to nail this? Your target audience, specific business rules, relevant code snippets from your project. No more, no less. Filler here is like static on the line – it just garbles the signal.
Constraints: What are the non-negotiable boundaries? Output format (Markdown, JSON, a sonnet?), length (“under 500 words, or I walk”), tone (“formal, like a legal brief,” or “breezy, like we’re at a barbecue”). These are your guardrails.
Examples (The Secret Sauce): This, dear reader, is where the magic happens. Show, don’t just tell. One or two well-crafted examples of your desired output style, format, or logic can slash “hallucinations” and align Copilot with your brainwaves faster than any abstract instruction. If your prompt feels complete without an example, you probably haven’t been specific enough.

VS Code’s Customization Trio: Your RICCE Toolkit

VS Code, bless its extensible heart, gives you three specific levers to implement RICCE. These aren’t buried in some config swamp; they’re designed to be version-controlled files, living right alongside your code in .github/instructions/, .github/prompts/, and .github/chatmodes/. Treat them like code. Because they are code – code for conversing with your AI.

Custom Instructions (*.instructions.md): Think of these as your project’s Ten Commandments for Copilot. Reusable, often file-specific rules (“Always use pathlib for Python paths, you heathen!”) that Copilot silently applies.
Prompt Files (*.prompt.md - still a bit experimental, but promising!): Named, pre-baked recipes for common tasks. Want to run a “Security Review Checklist” or “Generate API Docs”? Trigger it with a slash command.
Custom Chat Modes (*.chatmode.md): These are Copilot personas on demand. A “Planning Mode” that can only read code and suggest outlines? A “Refactoring Mode” with specific refactoring tools enabled? Yes, please.

Weaving RICCE into VS Code: Practical Magic

Let’s connect the dots. How do these VS Code features bring RICCE to life?

Constraints: Your Digital Rulebook via `*.instructions.md`

This is where you lay down the law. *.instructions.md files are the primary home for RICCE’s Constraints. They are your always-on style guides, your coding standard enforcers.

How it works: Use simple Markdown with optional YAML front-matter. The applyTo: "**/*.ts" directive, for instance, scopes your rules to TypeScript files. Below this, list your non-negotiables as clear, declarative bullets.
Example (Constraint & Embedded Example): ```yaml — applyTo: “*/.py” —
- Employ pathlib.Path for all filesystem path operations. (Show, don’t tell: from pathlib import Path; config_file = Path("/etc/app/config.ini"))
- All public functions must include type hints. ``` Copilot sees this and, ideally, stops suggesting os.path like it’s 1999. Clarity itself.

Roles: Crafting Copilot Personas with `*.chatmode.md`

Want Copilot to think like a specific kind of expert? *.chatmode.md files embody RICCE’s Role.

How it works: YAML front-matter defines the description (what shows up in VS Code), tools Copilot can use (e.g., githubRepo, codeSearch), and allowedFolders (a crucial Context Constraint, keeping Copilot focused). The Markdown body is a system prompt – here, you define the persona, its goals, and often a step-by-step workflow (initial Instructions).

Example (Role, Workflow Instructions, Tone Constraint, Embedded Example):

---
description: "The Devil's Advocate: Stress-tests technical plans."
tools: [codeSearch] # Can read, can't write. Perfect.
allowedFolders: ["docs/rfc", "specs"]
---
# ROLE
You are the Devil's Advocate. Your sole purpose is to find flaws in technical proposals, not to be nice. Be direct, be skeptical.

## WORKFLOW
1.  Summarize the core proposal (max 2 sentences).
2.  Identify three potential failure modes or overlooked edge cases.
3.  For each, ask a sharp "What if..." question. (Example: "What if the primary database becomes unavailable during the migration?")

This mode has personality. It’s bold.

Instructions & Tasks: Reusable Playbooks with `*.prompt.md`

For those multi-step coding recipes you use all the time, *.prompt.md files are your RICCE Instructions powerhouse.

How it works: YAML sets the mode (e.g., agent for complex tasks), tools, and description. The Markdown body details the step-by-step instructions. These can use variables like ${workspaceFolder} or ${selection} (Context!) and even include other prompt files.

Example (Full RICCE in one prompt file):

---
mode: agent
tools: [codebase, terminal]
description: "Scaffold a new React component with tests"
---
# ROLE
Act as a senior frontend developer following our team's conventions.

# INSTRUCTIONS
1. Ask the user for the component name (e.g., `UserProfileCard`).
2. Create a new folder named `${selection}` in `src/components/`.
3. Inside this folder, generate:
    - A functional React component file (`${selection}.tsx`) using TypeScript.
        - It should accept `title` (string) and `userData` (object) as props.
        - (Example structure: `interface Props { title: string; userData: object; } const ${selection}: React.FC<Props> = ({ title, userData }) => { ... }; export default ${selection};`)
    - A basic Storybook file (`${selection}.stories.tsx`).
    - A `pytest`-style test file (`${selection}.test.tsx`) with a simple render test.
4. Adhere to our ESLint rules (Context: assume project ESLint config).
5. Constraint: All generated files must include a standard license header.

This prompt doesn’t just ask; it specifies. It tells a small story of creation.

Context: It’s All Around You (If You Point it Out)

Copilot isn’t clairvoyant. You provide Context by:

Scoping: allowedFolders in chat modes.
Injecting: Variables in prompt files.
Opening Files: Copilot sees what you see in your active editor tabs. Use this.
Pasting: Directly share error messages, logs, or key code snippets in chat. Sometimes the most direct route is indeed the scenic one, if “scenic” means “copy-paste.”

Examples: The Linchpin, Woven Throughout

Remember, Examples aren’t a separate VS Code feature; they are a principle you apply within all other features. Embed them in your *.instructions.md to clarify rules, in your *.prompt.md to show desired output, and in your *.chatmode.md system prompts to define interaction styles.

The Payoff: From Chatty Wildcard to Disciplined Teammate

Why bother with all this? Because by treating your Copilot configurations – your instructions, your prompts, your modes – as first-class, version-controlled artifacts, and by structuring them with RICCE, you change the game.

Precision Skyrockets: Copilot makes fewer bizarre detours.
Consistency Reigns: Outputs align with your standards, not its whims.
Efficiency Soars: Less time correcting, more time creating. Don’t make the customer do the work.
Onboarding Smoothed: New team members (and your future self) get a Copilot already trained in “the way things are done here.”

This isn’t about stifling AI creativity. It’s about channeling it. It’s about moving from hoping for good output to engineering it.

Your Turn: Pick one common task. Try building a *.prompt.md for it. Define some *.instructions.md for the relevant file types. Maybe even craft a *.chatmode.md for the mindset you need. Treat these files like code. Iterate. Refine. Adopt this habit, and Copilot will stop feeling like a clever party trick and start acting like the profoundly capable (and disciplined) teammate you always wanted. —

Taming Your Copilot: A Practical Guide to Precision AI in VS Code was originally published by Micah Rairdon at Tiberriver256 on July 04, 2025.

ChatGPT needs some humility

2025-06-22T00:00:00-00:00

It’s hot today in Michigan. High temps. High humidity.

We turned down the thermostat a little bit, the AC kicked on, stayed on and didn’t really seem to be able to move the internal temperature. Several hours later I was curious…

So… I opened up my Beestat app and gave ChatGPT a screenshot of the system graph and asked it to calculate my degrees per hour.

It spun for about 4 minutes, running Python code, all kinds of stuff. Then it spit out some number confidently that I knew felt wrong. At the end it noted “Hey.. if you want some more accurate numbers, export the CSV of today’s data from ecobee’s website.”

I uploaded the CSV and it was able to determine the correct trendline very easily. What I would have liked is an original response to my image of “The image doesn’t give me enough data to do an accurate calculation. Please get the CSV.”

I’ve attempted to embed some lack of confidence into the system using my personalization prompt:

Rules around asking vs answering:

Whenever the user’s request lacks information needed for a precise answer, pause and ask up to three concise clarifying questions starting with “Why …” or “What specifically …”.

If sufficient context is present, answer normally.

After receiving clarifications, integrate them and provide the final answer with reasoning.

In general, that has made my experiences with ChatGPT better but… it still lacks some humility. It needs to doubt it’s own skills a bit more.. or at least get a better gauge on it’s own capabilities.

ChatGPT needs some humility was originally published by Micah Rairdon at Tiberriver256 on June 22, 2025.

I got my GitHub Copilot Certification

2025-06-21T00:00:00-00:00

How I studied

Used a community-owned practice exam
Followed the Microsoft Learn modules

Who should probably take this exam?

People administering a GitHub Copilot rollout at their organization.

My thoughts

As a user of GitHub copilot, I thought the courses on prompt engineering and actual usage were pretty good but minimal. I’ve learned a lot more about GitHub copilot reading through the GitHub Copilot for VSCode docs which are fantastic.

The docs stated that it’s targeted at adminstrators and for them I think it’d be key. If you’re managing GitHub Copilot for an enterprise you need to be familiar with:

How GitHub Copilot handles data
What security options are available
General list of features (enough to answer questions for staff)

For all that, this is great.

If you’re someone more interested in, “How does coding with AI actually work?” skip the cert. Maybe check out the learn modules. Comb the GitHub for VSCode docs. Try things out. Go through promptingguide.ai. You’ll learn a lot more.

I got my GitHub Copilot Certification was originally published by Micah Rairdon at Tiberriver256 on June 21, 2025.

An interesting learning with SignGemma and the deaf community

2025-06-03T00:00:00-00:00

Google announced a new tool called SignGemma which they describe as “our most capable model for translating sign language into spoken text”

I absent mindedly shared this in the GR Slack group I hang out in and a friend encouraged me to dig a little deeper into learning about how this new tool is received within the deaf community. The interesting piece for me to hunt for was why this tool wouldn’t be well liked/received by some. Wouldn’t everyone want this amazing tool?

What I wanted to do

Go out and talk with a few people who are deaf. Unfortunately, my life is pretty time constrained.. (as you can probably tell from how frequently I write on this blog).

What I did instead

I scoured the Internet… turns out there are lots of people sharing opinions on this topic on Reddit and Facebook. So here I collect the reasons someone might view this release as negative.

Reaction 1: Fear it might take ASL translator jobs

This technically isn’t coming from the deaf people but translators are what I would consider within the larger community so I thought I’d incldue them.

Reaction 2: Why are we spending money to help hearing people?

We should be working to help deaf people understand speaking… not the other way around

Reaction 3: Sign Language to English… doesn’t make sense

Reaction 4: It’ll reduce vocabulary and simplify the language

Seems like the reaction here is the fear of cultural homogenization similar to what television/media has done with local cultures/language variants of English.

Reaction 5: It will give people an excuse not to learn sign language

Reaction 6: Hearing people may be less inclined to provide interpreters thinking this tool is “good enough”

What I also stumbled upon

This tool was actually designed by a deaf person (Sam Sepah) for a specific problem they felt they had!

Unfortunately… couldn’t spot a specific problem they were after. Just a vauge sort of “this will help everything” which is typical of AI stuff.

What I learned…

So… Looking back… my gut reaction of shock around “How could someone not be excited about this?” feels pretty silly… especially me being pretty active in the autism community.

There are a LOT of people in the deaf community. Any community is made up of individuals. Every individual is unique and different from the other people within their community.

We can take the “Once you’ve med one autistic person… you’ve met one autistic person” and flip it to:

Once you’ve met one deaf person… you’ve met one deaf person

An interesting learning with SignGemma and the deaf community was originally published by Micah Rairdon at Tiberriver256 on June 03, 2025.

Getting the related work items for an Azure Pipeline run in a monorepo

2024-08-28T00:00:00-00:00

The problem..

I absolutely love this little ‘related work items’ feature in Azure DevOps pipelines:

You can click on it and quickly get a view of the work items associated with that pipeline:

This information is beneficial in two ways:

It is useful information for the person running a deployment
It can be used via ADO APIs to block deployments if related stories are in a certain status

So… what’s the problem with this feature?

It doesn’t support monorepos 😭😭😭

What happens with monorepos?

Let’s say I have a repository set up with the following folder structure and two azure pipelines files:

Then let’s say I commit to the main branch twice. Each commit adds a single index.js file to each folder:

Each of those files trigger their own build runs. When I view the related work items for each though.. this happens:

Does Microsoft plan to add monorepo support?

No… even though I’d think there would be plenty of support for this, the idea has never gotten any traction.

Let’s find a solution

It appears from the Azure DevOps REST API documentation that we should be able to do this ourselves… IF we are associating work items to our commits (via PR or otherwise). Which I so happen to be doint already so the following method looks pretty promising:

Get ALL the commits related to a build pipeline via the Get Build Changes endpoint.
Filter those commits down to the ones we want using the Get Commits endpoint using:
1. searchCriteria.itemPath - to exclude commits that aren’t in our trigger
2. searchCriteria.includeWorkItems - to include the work items associated with the commits
Pull the work item ids from Step #2 to do whatever I want with

PowerShell time!

Following the above strategy I wrote up a quick PowerShell script that seems to get me everything I need:

#Requires -PSEdition Core

<#
.SYNOPSIS
    Retrieves distinct commits and associated work items for a build pipeline... with support for monorepos!
    See the blog post at https://tiberriver256.github.io/DevOps/azure-devops-pipelines-related-work-items-monorepo for more information.
.DESCRIPTION
    This script retrieves the distinct commits and associated work items for a build pipeline. It requires the following parameters:
    - BuildId: The ID of the build. If not provided, it uses the value of the environment variable BUILD_BUILDID.
    - CollectionUri: The URI of the collection. If not provided, it uses the value of the environment variable SYSTEM_COLLECTIONURI.
    - ProjectId: The ID of the project. If not provided, it uses the value of the environment variable SYSTEM_TEAMPROJECTID.
    - AuthorizationHeader: The authorization header. If not provided, it uses the value of the environment variable SYSTEM_ACCESSTOKEN.
.PARAMETER BuildId
    The ID of the build.
.PARAMETER CollectionUri
    The URI of the collection.
.PARAMETER ProjectId
    The ID of the project.
.PARAMETER AuthorizationHeader
    The authorization header.
.OUTPUTS
    Returns a PSCustomObject with the following properties:
    - DistinctCommits: An array of distinct commits.
    - AssociatedWorkItems: An array of associated work items.
.EXAMPLE
    Get-BuildPipelineScopedChanges -BuildId 12345 -CollectionUri "https://dev.azure.com/myorg/" -ProjectId "be77c668-1e13-4360-aa08-264b1d5f64c6" -AuthorizationHeader "Bearer <access_token>"
    Retrieves the distinct commits and associated work items for the build with ID 12345 in the project "be77c668-1e13-4360-aa08-264b1d5f64c6" in the Azure DevOps organization "myorg" using the specified access token.
#>

[CmdletBinding()]
param (
    [Parameter()]
    [int]
    $BuildId = $ENV:BUILD_BUILDID,

    [Parameter()]
    [Uri]
    $CollectionUri = $ENV:SYSTEM_COLLECTIONURI,

    [Parameter()]
    [Guid]
    $ProjectId = $ENV:SYSTEM_TEAMPROJECTID,

    [Parameter()]
    $AuthorizationHeader = "Bearer $ENV:SYSTEM_ACCESSTOKEN"
)

function EnsureModuleInstalled ( $name ) {  
    $module = Get-InstalledModule -Name $name  
    if ($null -eq $module) {  
        Install-Module -Name $name -Scope CurrentUser -AllowClobber  
    }  
}

EnsureModuleInstalled "powershell-yaml"

$Headers = @{
    Authorization = $AuthorizationHeader
}

$BuildUri = "$CollectionUri$ProjectId/_apis/build/builds/$BuildId"
$ChangesUri = "$CollectionUri$ProjectId/_apis/build/builds/$BuildId/changes"

$Build = Invoke-RestMethod -Uri $BuildUri -Headers $Headers
$RepositoryId = $Build.repository.id
$CommitId = $Build.sourceVersion
$BuildDefinitionId = $Build.definition.id
$BuildDefinitionRevision = $Build.definition.revision

$BuildDefinitionUri = "$CollectionUri$ProjectId/_apis/build/definitions/$($BuildDefinitionId)?revision=$BuildDefinitionRevision"
$BuildDefinition = Invoke-RestMethod -Uri $BuildDefinitionUri -Headers $Headers
$YamlFilePath = $BuildDefinition.process.yamlFilename
$YamlFileUri = "$CollectionUri$ProjectId/_apis/git/repositories/$RepositoryId/items?path=$YamlFilePath&download=true&versionDescriptor.version=$CommitId&versionDescriptor.versionType=commit"
$YamlFile = Invoke-RestMethod -Uri $YamlFileUri -Headers $Headers | ConvertFrom-Yaml 
$TriggerPaths = $YamlFile.trigger.paths.include | ForEach-Object { $_ -replace "\*", "" }

$IsMonoRepo = $TriggerPaths.Count -ge 1 -and $TriggerPaths[0] -ne "/"


$Changes = Invoke-RestMethod -Uri $ChangesUri -Headers $Headers

$LatestChangeTimeStamp = $Changes.value[0].timestamp
$OldestChangeTimeStamp = $Changes.value[-1].timestamp

$CommitsFilteredByTriggerPaths = @()
$BaseCommitsUri = "$CollectionUri$ProjectId/_apis/git/repositories/$RepositoryId/commits?searchCriteria.fromDate=$OldestChangeTimeStamp&searchCriteria.toDate=$LatestChangeTimeStamp&searchCriteria.includeWorkItems=true"

if ($IsMonoRepo) {
    foreach ($Path in $TriggerPaths) {
        $CommitsUri = "$BaseCommitsUri&searchCriteria.itemPath=$Path"
        $Commits = Invoke-RestMethod -Uri $CommitsUri -Headers $Headers
        $CommitsFilteredByTriggerPaths += $Commits.value
    }
}
else {
    $Commits = Invoke-RestMethod -Uri $BaseCommitsUri -Headers $Headers
    $CommitsFilteredByTriggerPaths = $Commits.value
}

$DistinctCommits = @($CommitsFilteredByTriggerPaths |
    Group-Object -Property commitId |
    ForEach-Object { $_.Group[0] })

$DistinctWorkItemUrls = $DistinctCommits.workItems.url | Get-Unique

$AssociatedWorkItems = @($DistinctWorkItemUrls | ForEach-Object {
        Invoke-RestMethod -Uri $_ -Headers $Headers
    })

return [PSCustomObject]@{
    DistinctCommits     = $DistinctCommits
    AssociatedWorkItems = $AssociatedWorkItems
}

Getting the related work items for an Azure Pipeline run in a monorepo was originally published by Micah Rairdon at Tiberriver256 on August 28, 2024.

The quest for an ergonomic keyboard - Part 1

2024-06-08T00:00:00-00:00

If you didn’t read my previous blog post I’m hunting for a good method for keeping my tech experiments going from my living room lazy boy. One of the key components to that is having a bluetooth ergonomic keyboard

Why Bluetooth?

If I’m going to be popping up a little workspace here and there all over the house, I want setup time and teardown time to be seconds. I also don’t want anything dangling because when I’m watching my kids I often have to jump up quick to help with something and I don’t want to get anything caught while I’m trying to get my keyboard off my lap.

Why ergonomic?

Regular keyboards hurt… like… a lot.

I can only type on a laptop keyboard for about 15-20 minutes before my hands start hurting. I need something that I can type on for hours without pain. I have a Moonlander keyboard which I use for work that lets me type for hours without a whole lot of pain. I need something similar.

What I tried

I just bought the ErgodoxLP Wireless by SliceMK which is a fantastic little keyboard. I discovered though that I cannot handle the low-profile keyboard and low-profile switches. They are too similar to a laptop for me. I typed on it for about an hour today at the library and had sever pain in my hands for about two hours after that. Definitely not a good fit.

What’s next?

I’m debating between these two options:

Glove80

Pros:

Wireless
Split
Ergonomic

Cons:

Low-profile switches might cause the same pain I experienced with the ErgodoxLP

Svalboard

Pros:

Highly ergonomic - Likely to be even less pain than my Moonlander just due to the lack of movement
Mouse embedded in keyboard - You can get a trackball right in the keyboard which reduces the clutter of my working environment even further

Cons:

Not wireless - Kinda sucks that it’s not wirelss but it would hook straight into my phone with a usb-c and without the mouse there it might not be that big of a deal
Cost - These suckers come in at around $800 and I just had a plumbing emergency at home cost me $11k so I’m not sure I’ll be able to affort these guys too soon

The quest for an ergonomic keyboard - Part 1 was originally published by Micah Rairdon at Tiberriver256 on June 08, 2024.

Blogging from Android

2024-05-30T00:00:00-00:00

I love to write blog posts and tinker with technology. I haven’t been able to do this for awhile for several reasons:

I have two autistic boys that require constant attention when they are awake
I have severe pain in my hands that prevents me from typing on laptop keyboards
My home office is in my youngest child’s bedroom which keeps me from blogging when my kids are sleeping

Needless to say… I’ve been stuck for quite some time. I think I may have found a decent solution though, which is:

A bluetooth split keyboard
Termux
My Pixel 8 Pro
A decent Neovim setup

The setup allows me to work with my phone in my lap in my recliner and type out a blog like this one! Very excited to be back blogging again!

Blogging from Android was originally published by Micah Rairdon at Tiberriver256 on May 30, 2024.

ThingWorx local development environment with Docker - Part 1

2024-03-02T00:00:00-00:00

ThingWorx is a platform for developing “Industrial IoT solutions”. They’ve got a lot of interesting documentation on various setup guides but I wanted to document how to get one up and running locally in a few minutes for the express purposes of learning and experimentation.

A local setup doesn’t usually need all the heavy duty resilience and redundancy requirements that come with setting up a production environment. Unfortunately, while ThingWorx has plenty of documentation on setting up a production instance they don’t have a whole lot of documentation on quickly spinning up a local environment for experiementation.

What is the ThingWorx architecture?

There are three basic components in ThingWorx documented here and they are:

Things/Devices/Users/Clients
ThingWorx Foundation
Database

The ThingWorx Foundation application is a Java web application designed to be hosted with Apache Tomcat. The database you choose to use with ThingWorx is somewhat up to you. Any database that provides a JDBC driver and is ANSI SQL capable should work, although the officially distributed installers will make it easier if you’re using either PostgreSQL, MS SQL, or Azure SQL.

All of this looks like it’s VERY dockerizable.

Are there other attempts out there to do this with Docker?

There are of course the official Docker implementations mentioned in the installation guide here. These are a little overkill for our needs though.

A quick Google search yielded up Foxoncz/docker-thingworx which he describes as being a “Simple dev setup for ThingWorx.” Sounds perfect for our requirements! Let’s give it a shot!

Experimenting

Well… the first problem with this repo… there’s no documentation on how we should use it…

There is a folder called tw (probably short for ThingWorx). The folder contains a a single empty file named UNPACK_TW_HERE.txt. Seems like the developer probably wanted us to unpack ThingWorx there. Now… lots of questions left. There are multiple versions of ThingWorx available for download. Which one should we unpack there? Let’s keep exploring and see if we can figure that out.

There appear to be two docker files and a docker-compose.yml file that connects the two of them.

Dockerfile 1 - Dockerfile.postgres

Dockerfile.postgres a very simple file seems to be the container for our database and does three things:

Copies the contents of /tw/install/ into the container
Sets the twpg_init.sh script as the entrypoint script
Creates the basic ThingWorx storage folders and appropriate permissions

FROM postgres:9.6.5

COPY /tw/install/ /twpginit/
COPY /twpg_init.sh /docker-entrypoint-initdb.d/

RUN mkdir /ThingworxPostgresqlStorage && \
    chmod 775 /ThingworxPostgresqlStorage  && \
    chown postgres:postgres /ThingworxPostgresqlStorage

Dockerfile 2 - Dockerfile.tomcat

Dockerfile.tomcat is also a very small file that is going to host our Tomcat server. It does three very similar things:

Copies the ThingWorx war file into the tomcat webapps folder
Copies the ThingWorx platform-settings.json file into the appropriate folder in the container
Creates the basic Thingworx storage folders and appropriate permissions

What’s next?

Based on the examination of those two files I’m guessing we should be extracting the ThingWorx Postgre installation option down into the tw folder and then just run docker compose -f docker-compose.yml up. Let’s see what happens!

Our first go at it

The documentation in the repo didn’t give any specifics on what version of ThingWorx should be used, but the latest is the greatest so let’s try downloading 9.5.

I already downloaded [Rancher Desktop][https://rancherdesktop.io/] and validated everything in Docker land is working right by running docker run hello-world.

I downloaded the zip file containing ThingWorx Postgres and extracted it to the tw folder and then I ran docker compose -f docker-compose.yml up.

This is what I got…

Exceptions! Exceptions everywhere! Haha… to be expected I suppose. It seems we’ll likely have to build our own. See you in the next post in this series!

ThingWorx local development environment with Docker - Part 1 was originally published by Micah Rairdon at Tiberriver256 on March 02, 2024.

Estimate, target, plan and commit

2023-12-30T00:00:00-00:00

I’ve started into “Software Estimation: Demystifying the Black Art” by Steve McConnell, and of course… as is my style. I’m making some conjectures about what I think software development should look like based off of reading the first chapter. I am going to finish the book, but jotting some quick thoughts down as I go helps me to digest the book as I go, so don’t be surprised if I actually contradict something in the book. I haven’t read it all yet.

Some definitions

Estimate - Something rather easily and simply generated that is roughly accurate and expected to be off within a certain range. A simple formula that may be good enough in most cases is suggested as Effort = NumberOfRequirements * AverageEffortPerRequirement.
Target - The business wants to do something by X date. A statement of a desireable business outcome.
Plan - This is a detailed schedule on how we plan to hit said target (it will likely include prioritization and leaving certain things out).
Commitment - When someone or a team promises to hit the target with a specific level of quality.

A logical plan

You can expect the business to come to you with targets. We should be ready with good enough™ estimates to help produce plans that we can commit to.

So the sequence is:

Build a system that can be used to produce good enough™ estimates on-demand
Wait for the business to bring you targets
Build plans to hit those targets using your estimates
Only build plans you’re comfortable committing to

The tricky part

It seems to me that building a data-set to produce good enough™ estimates on-demand is the tricky part. I believe Steve is going to cover this in more detail later in the book but my guess as to some important details would be all centered around measuring that AverageEffortPerRequirement and that the keys to getting accurate measurements there are going to be around when can we say something started and when can we say something is finished?

Estimate, target, plan and commit was originally published by Micah Rairdon at Tiberriver256 on December 30, 2023.

How to run multiple versions of React side-by-side using Single Spa

2023-10-21T00:00:00-00:00

This seems like it should be easy right? Single-spa is a micro-frontend framework designed to handle running multiple SPA frameworks side-by-side. It’s pretty straightforward in all the other frameworks… but not so in React. Let’s dig into why that is.

What’s the problem?

In order to use React you always have to install two packages:

react - The main runtime for React
Some other package that handles the rendering (i.e., react-dom/react-canvas/react-native/react-pdf/etc.)

This allows developers to plug multiple renderers into the React runtime and magically grants everyone who knows React the ability to write JSX code that works in a bunch of random places.

Sounds magical! Why is this a problem again?

The problem only comes when we’re trying to work with single-spa. Let’s setup a quick project to show how this works:

I create a root config
I create a React project running React 17, setting up my webpack externals to look like: { react: 'react-17', ['react-dom']: 'react-dom-17' }
I create another React project running React 18, setting up my webpack externals to look like { react: 'react-18', ['react-dom']: 'react-dom-18 }
I add import maps for react-17, react-dom-17, react-18, react-dom-18 all pointing to their various https://cdn.jsdelivr.net/npm/ urls.

We boot up the site and we get a nice fat error message: Unable to resolve bare specifier 'react' from https://cdn.jsdelivr.net/npm/react-dom@17.0.2/umd/react-dom.development.js

The reason we get this error message is that react-dom was bundled with a dependency on react. So, even though we have our application code swapping out every react import with either a react-17 or a react-18 import and we’re doing the same for where our application code references react-dom we can’t do anything about the code inside the react-dom library that is looking for a module named react-dom.

It’s a problem unique to React because of it’s two package delivery system. If they shipped it as one package like Angular/Vue/etc. then we wouldn’t be having this problem.

The solution

We’re going to re-bundle up our own distribution of the react-dom libraries. Running it through webpack first. That way we can tell react-dom-17 to import react-17 and we can tell react-dom-18 to import react-18.

What’s the easiest way to do that?

Let’s use npx create-single-spa to spin out two utility modules:

One to re-export react-dom@17 and have it’s webpack externals set to: { react: 'react-17' }
One to re-export react-dom@18 and have it’s webpack externals set to: { react: 'react-18' }

The only file in both projects will look like this:

import ReactDOM from "react-dom";
export default ReactDOM;
export * from "react-dom";

Now in our import maps we reference our own utility module versions of react-dom instead of the ones hosted on cdn.jsdelivr.net and things just work!

If you want to check out the working code, I’ve got a sample repository on Github.

How to run multiple versions of React side-by-side using Single Spa was originally published by Micah Rairdon at Tiberriver256 on October 21, 2023.

Stages of ramp up on software development projects

2023-06-29T00:00:00-00:00

This is a list I’m going to be maintaining on different ideas and thougths around ramping up on new software projects.

Grasp of existing problems

One component of ramping up on a new project is understanding existing problems. You’ll never find a project without problems. These problems come in all shapes and sizes. They might be code quality issues, they might be slow running tests, they might be style issues on the front-end, they might be architectural issues, whatever they are, you are sure to find problems in any project that’s been around longer than a day.

I find a lot of newer developers are exhausted by this fact or feel it is a bad thing to find problems. I believe it’s the opposite. It’s a sign you’re starting to get a good grasp of the project. What’s important, is to not let the problems overwhelm you and to surface those problems to the rest of the team.

As you ramp up, you’ll typically find yourself in one of these three stages. The final stage is where you want to be at.

Finding and verifying problems

Ramping up on a new project, you’ll find yourself getting aggravated by things in the code or things in the project you’re working on.

As you find problems, you’ll be:

Verifying it’s a problem - Lots of times, it’s just a misunderstanding, or it’s just something you weren’t aware of
Document the problem - Jot notes about the problem down somewhere
Surface the problem to the team - When you’re new to the team, it’s essential that you discuss problems with the larger team. Raising awareness is key even if nothing can be done about those problems.

It’s important to note, at the beginning you will rarely know how to solve these problems. That’s okay.

Finding solutions to those problems

At some point, you’ll have a firm enough grasp on the project to start seeing solutions to the problems you’ve been identifying.

This is very exciting! For the first time, you’re seeing a path to fixing the problems that have been bugging you over the past weeks or months.

As you discover solutions, you should:

Verify the solution with a more senior team member - If it’s a valid solution, awesome! If not, you probably will learn some key features of the project you’re working on. Both are very valuable.
Document the solution - Jot down some notes about the potential solution.
Share the solution with the team - Discuss your potential solution with the broader team.

Important things to remember:

There are always multiple ‘solutions’ to the same problem - You might solve the problem with documentation. Someone else might suggest changing the code to prevent having to write documentation. Both are valid solutions worth considering.
Don’t expect your solution to get queued up in the backlog - There are multiple solutions to a single problem. There are multiple problems. We will never fix all the problems. Team members who have been on this project longer likely understand the business context a bit better and will prioritize things in a way that may not make sense to you at this stage. The important thing to do here is to try and understand where your solution might fall on a prioritized list and why it was placed in that priority.

Prioritizing solutions based on business goals and business value

As you continue identifying problems and solutions, eventually, you’ll be able to prioritize them based on your understanding roughly of business goals and how much business value implementing that solution will add.

This is where you start to become an invaluable partner for the business. If you were to visualize your list of solutions in a graph it might look like this:

You’ll always want to be recommending the business support work on the solution that you’ve identified as the highest value for the least effort. When you can rank solutions like this and articulate that value back to the business you’re fully ramped up.

Stages of ramp up on software development projects was originally published by Micah Rairdon at Tiberriver256 on June 29, 2023.