Skip to content
Jonas Fackelmeyer

The agent writes. I review.

I write specifications, steer coding agents such as Claude Code and secure the results with automated tests, reviews and quality gates. The agent brings speed; responsibility for every line stays with me.

See the review case
auth/session.tsAgent → review: Jonas
  1. export async function getSession(req) {
  2. + const token = req.query.token ?? req.cookies.sid;
  3. Review: A token in the URL ends up in logs and referrers. Accept the cookie only and add a test.
  4. return verify(token);

Simplified example

The agent
Propose code
Jonas
Review and approve

Process

From the plan to approval: every step has a clear purpose.

  1. Specification and plan first

    Before an agent writes code, it is settled what gets built and how I will judge the result.

  2. Project rules, not prompt luck

    CLAUDE.md and my own skills record conventions, commands and limits, so every session starts the same way.

  3. Small diffs, every one read

    I do not accept code I have not read and could not explain in an interview.

  4. Tests as a gate

    Type check, lint and the relevant tests must pass before a change counts as done.

  5. Security review as its own step

    I check auth, injection and secrets separately, not in passing during the normal review.

Green tests. Wrong server.

A mistake while building this website shows why automated checks and visual review belong together.

Schematic comparison of two browser windows: both tests pass. On the left, a highlighted development toolbar reveals the dev server on port 4321; on the right, the finished build runs on port 4329.
Illustrative reconstruction: both tests pass. Only the right one checks the build.

  1. Task

    Browser tests for this website: accessibility (axe), rendering on phones, content without JavaScript. They are meant to run against the finished static build, exactly what goes live.

  2. What the agent built

    A Playwright configuration that starts a preview server on port 4321 before the tests and reuses a server already running there. All tests passed.

  3. The bug in it

    At the same time, the development server was running on port 4321. The tests reused it and checked the development state instead of the build. Green only meant: the development server is fine.

  4. How the process caught it

    Before anything counts as done, I check it in the browser. The screenshots of the supposedly built site showed the development server’s toolbar, which does not exist in the build. Checking the port confirmed it.

  5. Outcome

    The tests now run on their own port and never reuse another server; a comment in the configuration records why. All tests were then run again against the build. The lesson: passing tests only prove something if it is clear what they checked.

Limits

Data, approvals and checks follow explicit rules throughout the workflow.

  • Data & secrets

    Health data and customer data never go to an AI tool. Secrets live only in environment variables, never in code, the repo or a prompt.

  • Changes requiring approval

    The agent asks before adding a production dependency, changing lockfiles, touching CI or infrastructure, deleting files or force-pushing.

  • Checks

    Checks are never bypassed: no --no-verify, no @ts-ignore, no disabled lint rule just to make something pass. The agent fixes the cause or asks.

  • Commits & pushes

    Commits and pushes happen only when I say so.

  • Mechanical guardrails

    What can be checked mechanically is enforced by a guard hook in my workflow plugin: it blocks bypassed checks and secrets and asks before everything else happens.

Impact

  • OrthoOS

    OrthoOS: in three months (07–09/2026), as founding engineer, I built a multi-tenant practice management platform, from row-level security and MFA to German dental billing formats and CI/CD.

  • This portfolio

    This website: from first draft to a bilingual, tested site in one day. Build tests check SEO, structured data and internationalisation, plus browser tests with axe and Lighthouse budgets in CI.

Take the workflow with you.

Rules, guard hook and Codex agent as an installable Claude Code plugin, with tests and an example run:

Workflow plugin on GitHub Get in touch
Simplified guard example
git commit --no-verify

Blocked

Checks must not be bypassed.

The guard matches patterns and is not a sandbox. It does not replace my review.