SERVICES · QA ENGINEERING

Build the right
QA architecture.

Every team's QA problem is different. I start by learning yours, then building the architecture that fits. Recent focus has been on teams shipping AI-drafted code, where traditional QA practices no longer fit and the answer is a different methodology entirely.

01 / what I build

AI agents that take repetitive QA and bug-fixing work off your engineers, running safely inside the CI and deploy setup you already have. These three come up most often. Each one is something I have built and written up in detail.

01

Higher-Confidence QA Gates

Every release waits on someone experienced to judge whether a failed test is a real problem or a false alarm. That manual check slows shipping and ties up the people you can least spare. Skip it, and you ship on a guess. This agent makes the call for you, the way your best engineer would, so the whole team gets a release decision they can trust.

  • Releases stop waiting on manual review of failed tests
  • Tells a real problem from a false alarm, reliably enough to act on
  • Frees your most experienced people from sifting through failures
  • A release decision the whole team trusts, in about a minute

see related blog →

02

Manual Testing on Every Release, Automated

Every release needs someone to look it over for the problems automated tests can't catch: an odd input, a broken permission, a path no script covers. Done by hand that is hours of work on every deploy, and shipping waits on it. This agent runs that same check automatically on every release and reports back in minutes, so the team gets a read on each deploy without waiting on anyone.

  • Runs the hands-on check a manual tester would, on every release
  • Catches the problems scripted and regression tests can't
  • Reads what each release changed and focuses its testing there
  • A clear report in about ten minutes, not hours by hand

see related blog →

03

Turn Bug Tickets Into Ready PRs

Hand it a bug report and it does the first pass of the fix: reproduces the problem, writes the change, confirms nothing else broke, and opens a pull request for your team to review. Every step has a safety check, so it stops cleanly instead of guessing, and it never merges on its own. Your engineers review a finished draft instead of starting from a blank page.

  • Turns a bug ticket into a ready-to-review pull request
  • Reproduces the bug, then confirms the fix actually works
  • Re-runs your test suite to check nothing else broke
  • Always opens a PR for a human to review, never merges itself

see related blog →

02 / how I work

No template. We start from your actual pain and prove it on real work before it touches anything that matters.

  1. Start with your pain. Which one is loudest: red builds eating your team's time, bugs slipping past your tests, or fixes piling up? We pick the agent that helps most.
  2. Build it for your setup. I wire the agent into the CI and deploy flow you already use, matched to your stack and conventions. No new platform to adopt.
  3. Keep humans in control. Every agent reports in plain language and stops cleanly when it is unsure. Nothing ships without your team's review.
  4. Expand on trust. Once one agent earns its place, the others slot onto the same foundation.
see selected work read notes from the build get in touch
STATUSOPEN TO WORK
LOCMNL · UTC+8
VER0.1.0
--:--:--