Aby George

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

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