Guillermo LizasoainPayments Delivery Executive & Operator

How I work with AI

AI agents build and run my own production systems. I know what it takes to trust them.

Every change to those systems is specified, critiqued, built and reviewed by AI models, inside a cycle where a human decides what done means and authorizes every deploy. The systems act on real money, unattended, every day. This site is built the same way.

Talk about AI in your delivery

The cycle

Every change goes through the same gate, whoever wrote it.

  1. Step 1

    Specification first. A written spec with user stories, acceptance criteria that can fail, what must not change, and a rollback. Some criteria do fail, and that is the point.

  2. Step 2

    A human signs off on what done means. That is a business decision, not a technical one. No code before it.

  3. Step 3

    A second model critiques the spec and the prompt. As a critic, not a translator: what is ambiguous, unstated, or unbuildable.

  4. Step 4

    The implementer critiques before it builds. “Looks good” is an invalid answer. “This is unbuildable as written” is a normal and useful one.

  5. Step 5

    Code and tests together, on a branch, behind a flag. New behaviour ships off by default, with a kill switch.

  6. Step 6

    Adversarial review of the diff and the real output. Every new guard is mutation-tested: delete or invert it and see whether a test notices. A guard no test kills is not protected.

  7. Step 7

    A human authorizes every deploy. Nothing ships unbidden.

Earned the hard way

Rules that exist because something broke.

  • Tests written by the model that wrote the code are routinely vacuous. Mutation testing is the highest-yield check there is.
  • A plausible path is not the executed path. A claim about what the system does has to cite what actually runs: trace it, run it, or read the live artifact.
  • Internal state is wrong often enough that the system of record is consulted before a claim rests on it.
  • A test that cannot fail proves nothing. Acceptance bars are set before the work and may tighten afterwards, never loosen.
  • Research and delivery are different paths. A question gets its method and its bar before anything is measured, and its output is a finding, never code.
  • Corrections are reported loudly. A superseded claim does not stand because it was already sent.

In practice

Three places this shows up in client work.

AI-assisted delivery for payments teams.

The same cycle, installed in a product and engineering organization: usage rules, review discipline, ownership, production controls. Measured by delivery outcomes, not tool adoption. I did this inside a payments data engineering team before I did it for clients.

The service →The engagement →

AI decisioning after stable rules.

Automation programs that start with the model stall. The ones that work make the implicit policy explicit and executable first, then place AI where the rules run out. Merchant underwriting followed that order: analyst judgment became a testable rules model, and AI belongs after it, not instead of it.

The underwriting work →

Agentic commerce, from the operator's side.

Running autonomous agents against money is the same problem as letting one buy through a payment rail: mandate, evidence, recourse, reconciliation. The Perspective pieces on agent payments are written from that side of the ledger.

Perspective →

If your team is adopting AI and cannot afford production chaos.

Start with a conversation about where delivery is breaking and what review discipline exists today. The pilot plan comes after that, not before.

Get in touch