QA & Agent-Workflow Engineer

What we're building

We're building the transaction and ownership intelligence layer for business aviation. The system of record for what an aircraft is, who owns it, what it's worth, and what happened to it.

We're in stealth, in closed beta with a small group of brokers and principals. They use the product on live deals and tell us to our faces when it's wrong. We launch commercially on 1 January 2027.

Two founders: one with 27 years in tech, media and SaaS and a few exits, one with 30 years in business aviation. There's a fractional CTO too (PhD, ML) who owns infrastructure, security and the release gate. You'd work with all three.

How this codebase gets written

Almost none of it is typed by a human.

The platform (React front end, Postgres with row-level security, edge functions, a scraper fleet, LLM extraction pipelines) is built by Claude Code sessions running in parallel, each in its own git worktree, driven from Linear issues and merged through a release train that only moves when CI is green.

That's the job's context and the job's problem. When an agent writes the code, product quality comes down to the quality of the harness around the agent: what it's told, what it's forced to check, what it can't do, and what has to be green before a human hits merge.

Right now that harness is a very large CLAUDE.md, sixteen skills, a couple of hooks, a Playwright suite covering nine screens with no authenticated flow, and a lot of discipline living in the founders' heads.

Your mission

Make the harness better than the people running it, then ship through it.

Three strands, one person. We know that's a wide brief, so tell us which strand is your strongest and we'll build the role around it.

QA and release. You're the evidence behind the second gate: the human call to promote staging to production. You build the authenticated end-to-end suite (login and MFA, deal CRUD, uploads, briefing generation, exports, Stripe in test mode) and get it running automatically, at a cadence and against an environment you decide. You seed the data so it can be tested. You run the release smoke on staging and prod. You write defect reports that are reproductions, not impressions, and you re-test the fixes and say so. You think in edge cases (null input, unauthenticated, database read-only) and make the agent test them.

Agent workflow. You own CLAUDE.md, the skills, the hooks and the sub-agents, and you treat them as a product. You cut the working guide down to what an agent actually follows and move the rest into skills that load on demand. Every rule that has to hold (verify before declaring done, no unverified success reports, cost caps on paid lanes, migrations through the right path) you turn from prose into a hook that blocks. You build the evals that fail a merge. And you teach the rest of us, by example and by review, how to run a session so it lands the first time.

Build. You run the loop (issue, plan, review, tests, QA, merge) on the Must-tier items that need a person, not a night shift: billing and access (Stripe checkout, entitlements, the free tier), tail-intelligence data fixes (provenance per field, the ownership golden set), and the pre-audit security items under the CTO's review. You won't type most of it. You decide what the agent builds, you catch what it gets wrong, and you own the result.

If it works, we double down. If it doesn't, we kill it that week.

Non-negotiable: you have run this in production

Not tried it. Run it. For months, on a product with real users, where a bad merge cost something.

You need all of:

• A CLAUDE.md (or equivalent agent working guide) you wrote and maintained for a real team, and can walk us through line by line: why each rule is there, which incident put it there, what you took out and why
• At least one hook you wrote that blocked an agent from doing something, and at least one eval or test gate you wrote that failed a merge
• A test suite you built (Playwright, Cypress or similar) that ran in CI and caught regressions before users did
• A real command of QA methodology: TDD, CI and continuous-delivery pipelines, and the actual differences between unit, integration, e2e and UAT tests. Some grounding in non-functional testing, mainly performance and security, is a plus
• Production incidents you've caused, caught, or cleaned up. We want someone who's broken enough things to know where they break

And you can talk about the workflow without a glossary. Context window and what actually loads into it. Why a line in CLAUDE.md is a suggestion and a hook is a rule. Sub-agent versus fork, and when to use each. Worktrees. Compaction, and what to keep across it. When to stop correcting a session and just restart it. Model tiering and prompt caching as cost levers, not trivia.

"I use it every day for my own projects" isn't the same thing, and it shows.

What you'll own

• The agent harness: CLAUDE.md, .claude/skills, .claude/agents, hooks, settings, and how they change over time
• The night shift. The unattended overnight runs where agents work a queue of small, well-scoped issues and open one PR each, for a human to review in the morning. You take it over from the founders once you're in seat: the queue, the acceptance checks that decide an issue is safe to run without a human, the morning review of every PR and every stop, and the call on when autonomy widens (always after review, never up front)
• The authenticated e2e suite and seeded staging, green before every release candidate, on a cadence you define
• Release evidence: UAT notes on every PR, smoke on staging and prod, the deploy board
• The eval gates that stop AI-generated code merging when it's wrong in ways ordinary tests miss
• Per-screen QA reviews against the approved designs, logged. Thirteen screens before 11 December
• Delivery of the Must-tier work assigned to you (billing and access, tail-intelligence data fixes, pre-audit code items) through the agent loop, with the evidence attached to every PR
• Coaching: a working session with each engineer and founder on how to run their sessions

You won't own the release verdict (that stays with the fractional CTO) or the product decisions. What you get is the layer everything else depends on, and the authority to decide how it's built.

Who you are

• Fluent English
• Senior enough to tell a founder his session prompt was the bug
• You treat the agent as an unreliable component you engineer around. Not magic, not a threat
• You'd rather ship one gate that's right on Friday than five that are nearly right in October. You cut scope, not corners
• You find breaking things satisfying, and writing down how you broke them more satisfying
• You're comfortable being the only person in the room whose job is to say "not yet"
• TypeScript/React, Postgres with row-level security, and GitHub Actions are your working languages. You can read a Stripe webhook handler or an RLS policy the agent wrote and say whether it's right. You don't need to be the fastest engineer on the team. You need to be the one who checks
• Aviation knowledge isn't required for this seat. The aircraft-data engineering sits with a colleague who flies. You'll pick up the domain traps from the working guide and from asking

Bonus

• You've written MCP servers or wired them into an agent workflow
• You've run agent teams or fleets of parallel sessions and dealt with the mess
• You know Supabase, RLS and pgTAP
• You've done accessibility or design-review QA against Figma frames
• You've written about any of this in public

Shape of the engagement

• Contract through Deel, day rate, invoiced weekly, paid on time
• At least half-time, and full-time if you can, through the January launch. What happens after, we decide together in December. Below half-time doesn't work: there's too much to hold across QA, the harness and the night shift.
• Mutual NDA before we share the repo
• Scoped access: staging, the repo, Linear. Production stays with the founders
• Start: as soon as we agree terms. We want you in the seat by mid-October

Why take it

• You build the harness for a codebase that's genuinely agent-written end to end, with real history to learn from and a launch date that makes it matter
• A founder who runs twenty sessions a day and will argue with you about every rule, then change his mind when you're right
• You're early on something built to matter: small team, real product, a launch on the calendar, and every intention of being very good at this
• You get to sharpen at the frontier of how software and QA actually get done now, and come out fluent in it before the market is
• Paid properly from day one. Day rate, contracted, invoiced weekly. No unpaid founder energy, nothing deferred
• Real flexibility on hours, built around gates and suites rather than presence

To apply

Apply below. A few things, short is fine, CVs optional.

1. A CLAUDE.md you wrote for a real team. Paste it or link it. Then a few bullets: which rules earned their place through an incident, which one you'd delete tomorrow, and what you moved out and where.

2. The harness problem. ~400 words, bullets are fine.

You inherit an agent-written codebase. The working guide is 700 lines. It has a 370-line section that grants the agent standing authorisation to open, review and merge PRs under conditions. There's a Stop hook that runs typecheck. Every other quality rule (verify before declaring done, never report success unverified, paid extraction lanes have a daily cap, apply migrations with db push and never the MCP tool) is prose. Releases go out several times a day. There's no authenticated e2e suite.

a) What do you do in week one, and in what order? Be specific about what moves where.

b) Which of those prose rules become hooks, which become CI, which stay prose, and why each.

c) What's the first e2e test you write, and what has to exist before you can run it on a schedule?

3. Your QA methodology in practice. How you use TDD and CI/CD, where you draw the line between unit, integration, e2e and UAT, and any performance or security testing you've done.

4. Something you broke. A production incident you caused, caught or cleaned up. What happened, what you changed so it couldn't happen again, and whether it did.

Process: application, then a 30-minute call, then a decision. We aim to come back within 5 working days.

We process applications through Tally, review them in Notion, and contract through Deel. We use what you send only to assess you for this role, keep it for up to 12 months, and don't share it further. To see, correct or delete what we hold, email hr@aipholdinginc.com.