Aby George

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. ...

In the previous post, we automated our tests in a pipeline. This is the last post in the series, and it covers two things that only really become relevant once a framework has been running for a while. Outgrowing a single machine, and keeping the whole thing maintainable months after the initial build. When One Machine Is Not Enough Gatling’s engine is efficient, and a single reasonably sized machine can simulate a genuinely large number of virtual users before it becomes the bottleneck rather than the system under test. That said, at some point, usually when you are stress testing a system designed for very high real world traffic, the load generator itself becomes the limiting factor, not the application you are trying to test. ...

In the previous post, we learned to actually read what Gatling produces. None of this is worth much long term if it only ever runs on someone’s laptop before a release, run manually and inconsistently. Today we automate it properly, and we sort out configuration across environments while we are at it, since the two problems tend to show up together in practice. Externalizing the Base URL Every simulation so far has hardcoded a base URL directly in the protocol configuration. That falls apart the moment you want to run the exact same simulation against a local environment, a staging environment, and occasionally production itself for a controlled test. The fix is to read it from a system property instead. ...

In the previous post, we set up assertions so a build fails automatically when performance regresses. A passing build is a good start, but the report itself still holds a lot of useful detail worth understanding properly, especially when something does go wrong and you need to figure out why. Every Gatling run produces a self contained HTML report. Open it with the show command from part one. mvn gatling:test # once the run finishes, Gatling prints the path to the report, # or open the latest one directly under target/gatling/ The Global Stats Page The landing page of the report summarizes the entire simulation. A few numbers here matter more than the rest. The percentile breakdown, shown as a chart and a table, tells you the distribution of response times across every single request in the run, not just an average. The requests per second chart over time shows whether your injection profile actually produced the load shape you intended, which is worth checking even on a passing run, since a misconfigured injection profile can silently produce far less load than you think it did. ...

Beyond the Co-Pilot: My Q2 Plan for Multi-Agent Automation First off, if you noticed complete radio silence on here over the last quarter, I have a pretty solid excuse! Work has been an absolute whirlwind. Between non-stop flights between Australia, Singapore and India, setting up new offshore engineering teams, and establishing new engineering ways of working from scratch, my calendar completely ate my side projects for breakfast. On top of that, team resource constraints meant I had to jump back into active microservice development alongside my management duties—building out core service APIs, handling edge cases, and pushing production code. ...

In the previous post, we covered the different types of performance tests. Today we cover something that turns any of those tests from “someone eyeballs the report and makes a judgment call” into an objective, automatable pass or fail result. Assertions. Without assertions, a Gatling run finishes and hands you a report, and a human has to decide whether the numbers in it are acceptable. That does not scale, and it definitely does not work inside a CI pipeline where nobody is watching the run happen live. Assertions let you encode your performance requirements directly into the simulation, so the build itself fails when those requirements are not met. ...

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. ...

In the previous post, we made scenarios behave more like real users. With everything we have built so far, injection profiles, feeders, correlation, checks, and pacing, we finally have enough pieces to talk about the different types of performance tests properly, since “run a load test” actually covers several genuinely different testing goals. Load Testing: Expected Traffic A load test answers a simple question. Does the system perform acceptably under the traffic level you actually expect. This is the baseline test you should have running regularly, ideally on every significant release. ...

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. ...

In the previous post, we made sure our checks actually catch real failures. Today we look at something just as important but easier to overlook, whether your scenario actually behaves like a real user in the first place. A scenario that fires request after request with zero delay between them does not represent any real visitor to your site. It represents a script racing through steps as fast as the network allows. That produces load numbers, but not necessarily useful ones, since real traffic has gaps in it while people actually read a page, think about what to click next, or get distracted by something else entirely. ...