zolty.systems

Multiple language models consulted as a panel

A panel of LLMs: using Gemini and Claude to pressure-test decisions

TL;DR One model = one blind spot. Claude and Gemini were trained on different datasets, have different architectures, and will miss different things. Consult for breadth, not consensus. The goal is to widen your analysis surface and catch blindspots, not to reach agreement. If all three models agree, that’s suspicious—run stress tests. The bridge is simple: Playwright drives a logged-in Gemini tab via Chrome DevTools Protocol, pastes your prompt, and scrapes the response when done. Real session, no API key. Two modes: (1) cold second-opinion—hand off a problem and ask for an independent take; (2) adversarial debate—assign sides, force defense, then reconcile. Both work; adversarial is brutal and useful for high-stakes calls. Anchoring is the trap. If you show Model B what Model A said and ask “do you agree?”, you get theater. Always pose cold or ask for the opposite argument first. Every Model Has Its Blind Spot I make the same mistakes in code as everyone else. My reasoning hits walls. I miss architectural gotchas and cut corners on testing. An LLM does the same, just in different places. ...

Two AI agents talking over a chat channel

Claude asks Claude for help: an agent-to-agent bridge over Mattermost

TL;DR Two Claude agents running in separate project contexts share a private Mattermost channel to ask each other for help without human intervention. A deterministic polling gate (bash + curl) checks for new messages before spawning the expensive responder LLM — idle polls cost almost nothing. The responder runs on the Claude Code subscription (keychain OAuth), not API credits, and keeps the LLM cheap. Scheduled every ~3 minutes by macOS launchd; armed/disarmed by loading/unloading the launch agent. Supervised autonomy: the responder can read, triage, draft, and explain — but NOT commit, spend money, change access, or deploy. Why one agent asks another I run parallel Claude Code sessions on different projects. They’re isolated — each has its own repo context, its own workflow, its own focus. But sometimes they need each other. ...

Supervising AI agents by reading the documentation they generate instead of the diffs

I don't read the PRs: supervising Claude by reading the docs it leaves behind

TL;DR I point Claude at a problem, give it a direction, and let it run — and most of the time I don’t read the merge request it opens. On an internal homelab where the blast radius is my own cluster, backups are real, and everything’s reproducible from code, line-by-line diff review is the wrong altitude. Instead I supervise after the fact by reading the artifacts the agents leave behind: the /docs/ folder, a Wiki.js wiki full of Mermaid diagrams, auto-generated architecture SVGs, and this blog. Reading those — not the diffs — is what’s actually caught problems: dead systems still wired in, duplicate config, a deploy that quietly deleted itself. ...

I built a headless refurb bench: imaging surplus PCs without a monitor

TL;DR The headless problem: Running a refurb bench means stacking PCs, but monitors/keyboards create noise and clutter. You need remote hands. PiKVM V4 Plus is a network KVM: remote video capture, USB keyboard/mouse emulation, virtual media mounting, and ATX relay control—all in a $300 device. Multiport Switch extender lets one PiKVM control up to four machines simultaneously by flipping an RJ45 port. Dell CCTK (Command | Configure) automates BIOS settings from WinPE: set AHCI, enable PXE, disable Secure Boot, configure Wake-on-LAN, tag assets—all without touching F2. Unattended imaging = BIOS automation + PXE boot + virtual media mounting. Chain ten machines without hands-on intervention. Gotchas matter: AHCI after Windows install = BSOD; Secure Boot changes need a setup password; BitLocker auto-encrypts Win11 and blocks generalize; Deep Sleep disables S5 wake. Why I Needed This I’ve been buying government-surplus refurbished machines to flip—mostly surplus OptiPlex machines—and my original setup was a single monitor, keyboard, and mouse swapped between machines. That works for one box. It doesn’t scale to five. ...

Photogrammetry scan turned into a 3D print

Phone scan to 3D print: photogrammetry, a watertight mesh, and Bambu

TL;DR Phone scanners (Polycam, KIRI Engine, RealityScan) export raw geometry that’s sparse, has holes, and is non-manifold—not printable. First critical step: normalize scale. Scans export in meters and import at the wrong size. Fix this before anything else or Blender’s voxel remesh produces nothing. Blender’s voxel remesh rebuilds the mesh into a guaranteed watertight, manifold shell. Then decimate down to a slicer-friendly polygon budget. Export as both STL (geometry) and 3MF (units + compression). Slice in Bambu Studio and print. Watch for: voxel size mismatch, color loss after remesh, holes bigger than the voxel size, and X1C build plate limits (256×256mm). The Photogrammetry Gap There’s a seductive lie in 3D printing: buy a phone, scan something, print it. In reality, there’s a canyon between a photogrammetry scan and a printable model. ...

Recapping a dead cassette deck: a vintage-audio repair triage

TL;DR “Dead” can mean anything from a sticky play button to catastrophic power supply failure. Map the symptoms first before you commit to a $40 parts order. Electrolytic capacitors dry out over 30–40 years. The tell is ESR (equivalent series resistance), which you can’t measure with a multimeter—you need a dedicated ESR meter. Mechanical failures (belts, pinch rollers, switches) cause 50% of what looks like electronics trouble. Try contact cleaner and spin the reels manually before you touch a soldering iron. Replace the power supply filter caps first. If hum persists after disconnecting the mains input, you’ve got a trace issue, not a capacitor issue. Full recap economics: ~$15–40 in parts + 2–6 hours of work. Only worth your time if the restored unit will fetch ~60% of that total cost on resale. What “Dead” Really Means A cassette deck doesn’t come with an error code. It just stops. And the failure modes are a taxonomy you need to parse before you spend an evening at the bench. ...

Background removal and batch image generation across two Mac Studios

Beyond cover art: background removal, batch resources, and two GPUs of throwaway pixels

TL;DR Cover art was the gateway drug. The same local ComfyUI install that generates this blog’s headers also strips the cluttered background off a photo of hardware on my bench, upscales a small generation to retina resolution, and batch-produces a consistent set of illustrations from a prompt template. Two Mac Studios mean I can fire a batch at one box and keep working on the other. It’s all driven from scripts and agents, and it all costs $0 per image because it never leaves the house. ...

The Hugo, S3, CloudFront, and AI drafting pipeline behind this blog

How this blog is built: Hugo, S3, CloudFront, and an AI drafting pipeline

TL;DR This site is deliberately boring infrastructure for a reason: Hugo generates static HTML with the PaperMod theme. Terraform manages AWS (S3, CloudFront, Route53, ACM). GitHub Actions and self-hosted k3s runners deploy on every push to main. An AI pipeline (Bedrock + a Python script) drafts articles into Hugo page bundles and opens PRs for review. There’s no dynamic backend, no database, no server to maintain. The AWS bill is ~$30/month. This post is a tour of the machine that prints the other posts. ...

Prompt to ComfyUI to S3 to Hugo image generation pipeline

From prompt to published: how every image on this blog comes out of a local ComfyUI

TL;DR I don’t pay for stock photos and I don’t open Canva. Every raster image on this blog is generated on a Mac Studio sitting three feet from me, by asking Claude Code to call a generate_image MCP tool that wraps ComfyUI. The pipeline is: prompt → ComfyUI (MPS) → PNG on disk → upload_media.py → S3 → CloudFront → a Markdown reference in the post. It costs $0 per image, takes ~15 seconds, and the whole thing is repeatable because the prompt and settings live in the commit history. ...

PiKVM and Dell CCTK configuring a bench of headless small-form-factor PCs

Headless bench-PC fleet: imaging and BIOS-as-code with PiKVM and Dell CCTK

TL;DR I keep four small-form-factor PCs on a bench for testing and repurposing — bought used, need fresh OS images, fresh BIOS settings, and no monitor or keyboard. A PiKVM V4 Plus with a multiport switch gives me eyes and hands on all four boxes over the network. Dell’s cctk command-line tool (Command | Configure) lets me bake BIOS settings — boot order, AHCI mode, Wake-on-LAN, power-on-after-failure — into scripted runs instead of clicking through F2 menus. No monitor, no keyboard, no physical access for weeks at a time. Everything repeatable, everything as code. ...