In the previous post, we built a test strategy and found real bugs. The agent works and it is tested. Now we ship it. This post has three parts. First, what the evals cost and how I cut it. Second, three problems I found in a pre deployment check that would each have broken the live site. Third, the chat page itself, and how it ended up on my resume page. ...
In the previous post, we added guardrails to my resume agent. It grounds its answers, refuses off topic questions and resists prompt injection. At least, it seemed to. “Seemed to” is not good enough for a quality engineer. So this post is about proving it. We will build a test strategy for an AI agent, and then look at the bugs it found. Some of them I would never have spotted by hand. ...
In the previous post, we built the retrieval pipeline. A question goes in, and the right chunks of my resume come out. Now we add the language model. This is where things get risky. A model that writes fluent answers can also write fluent nonsense. And this agent speaks for me, on a public page. A wrong answer here is my reputation. So this post is about controls. We make the agent answer only from evidence. We make it refuse everything else. And we defend it against people who try to talk it into misbehaving. ...
A resume is a static document. A recruiter reading it has questions it cannot answer. Did you create AI agents? What did you actually do in your last role? Have you used Kafka? So I built an agent that answers those questions for me. You can try it on my resume page. Ask it anything about my background and it answers in the first person, with sources. This is the first of four posts about how I built it. Today we cover the architecture and the data pipeline. By the end you will know how a question turns into the right piece of my resume. ...
Graphify: The Missing Map for Brownfield Codebases Back when I was digging into OpenSpec, I kept circling the same problem: on a brownfield codebase, nobodycan tell you with confidence what’s actually connected to what. Specs help, but a spec still describes behaviour. That’s the gap that pulled me into Graphify. Graphify turns a codebase — code, docs, SQL schemas, configs, even PDFs — into a queryable knowledge graph, and ships as a skill for Claude Code, Cursor, Codex, Gemini CLI, Copilot, Aider, and a dozen-plus other assistants. Its like a dependency map for your code base. Instead of an agent guessing at architecture from whatever files happen to be open, it gets a real map to query. ...
Every test suite past a certain size accumulates flaky tests, ones that fail occasionally for reasons that have nothing to do with the code under test. A slow CI runner, a race condition in test setup, a shared resource another job happened to be using at the same time. The problem is never that flaky tests exist. The problem is triage time. Someone has to look at a failure, decide whether it is real or noise, and that decision eats far more time across a team than it should, especially on a suite with hundreds of tests running on every merge. ...
Spec-Driven Development for the Rest of Us: OpenSpec Last month I found GitHub’s Spec Kit and how it flips the traditional dev workflow — spec as the durable source of truth, code as the disposable output. Spec Kit’s /constitution-first, plan-then-build ceremony assumes you’re starting mostly from a blank slate. Almost nothing I touch day-to-day looks like that. It’s always years old services, inherited conventions nobody remembers agreeing to, and test suites that are more archaeology than architecture. ...
Flipping the Script: A Look at GitHub’s Spec Kit I’ve spent the last few posts obsessing over agents that write, run, and heal tests. This time I want to zoom out one level, because I think I’ve been skipping over the artifact that actually matters most to an AI coding agent: the spec itself. That’s what pulled me into Spec Kit, GitHub’s open-source toolkit for what they’re calling “Spec-Driven Development” (SDD). The pitch is deceptively simple but genuinely inverts how most of us have worked for the last twenty years. In traditional development, the spec (if one even exists past the kickoff meeting) is a scaffold — you lean on it briefly, then throw it away the moment code starts shipping. Code becomes the source of truth, and the spec rots in Confluence somewhere, quietly lying to whoever reads it next. ...