Agentic Development on Aby George

Graphify - Mapping the Codebase AI Agents Actually Need

Wed, 05 Aug 2026 08:25:31 +1000

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.

Using Claude Code CLI for Flaky Test Triage

Wed, 22 Apr 2026 08:25:31 +1000

Using Claude Code CLI to triage flaky tests, teaching an agent to tell a real regression apart from environmental noise, and where a human still needs to make the final call.

OpenSpec - Spec driven development for brownfield projects

Sat, 04 Apr 2026 08:25:31 +1000

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.

Spec Kit- Spec Driven development

Mon, 02 Mar 2026 08:25:31 +1000

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.