AI Coding in Practice

Start AI coding in a real repository with one verifiable change: define the outcome and acceptance criteria, let the agent read, edit and verify the code, then get independent review. This is BluffKing’s current path; its old role orchestration, patrols and looping gates have been retired.

Specify an observable result

A ChatGPT conversation can help clarify a requirement. OpenAI Codex and Claude Code working in a repository also need scope, permissions and acceptance criteria. “Fix room creation after session expiry, preserve the destination, and do not treat a network failure as logout” is easier to verify than “improve login.”

Goal: repair the specified behaviour.
Scope: affected callers, shared implementation and acceptance entry point.
Acceptance: normal path, error path and the visible result.
Delivery: changes, checks and remaining limits.
Authority: local merge; push or release only within the task’s authorization.

Isolate, verify, review

Each task gets its own worktree and fresh local ports from scripts/new-session.sh, against the same canonical database; shared resources such as the browser or database are used in turn when they would conflict (see what a worktree isolates). The name of an MCP server, skill or plugin does not prove it is connected, authorized or succeeded, and a rule saying “check daily” does not create a scheduled job.

After a change, run the affected compile, typecheck or build, and look at changed pages in ordinary Chrome. The only test suite is node scripts/e2e/run.mjs: every game, the top three by usage first, 100% pass within one continuous 180 seconds, run by the release owner at release time rather than per change. Every durable change is reviewed by the other vendor’s model before landing (Claude reviews Codex work, and vice versa); if that vendor is unavailable, a different model from the same vendor reviews and the reason is recorded, which is not a cross-vendor pass. Approval must be explicit with no open findings; scripts/finish-session.sh then merges into local main and never pushes or deploys.

Prove merge, push and release separately

Releases follow docs/ops/RELEASE.md through the local deployment script. The release SHA must already be on remote main, and game-runtime releases also need a fresh human_only_tables=0. Afterwards, read readiness and version provenance. A successful command proves only that command: report local merge, remote push, deployment and public availability separately.