Building a Full-Stack Game Through an Autonomous Agent Pipeline

This is a personal, self-initiated project, not professional production experience. It's a working multiplayer game used as the vehicle for exploring agent-orchestrated software delivery.

Problem

AI coding assistants are good at writing a function when asked. I wanted to explore a different question: what does it take for a requirement to flow through planning, implementation, testing, and review with no manual handoffs in between, and what breaks first when you try that?

Context

A multiplayer Battleship game (React/TypeScript frontend, Spring Boot backend) built specifically to exercise that pipeline: place ships, play against a computer opponent or a second human player over a shareable game code, restore an interrupted session, pause and resume. The game itself is a real, working product, but its actual purpose was to be the load-bearing example for the delivery pipeline built around it.

Constraints

• The pipeline needed to run without a human writing implementation code by hand between requirement intake and PR.
• State had to be correct under real multiplayer conditions: two independent sessions, reconnect-after-refresh, and proof-of-seat-ownership for every action, not just a single-player toy.
• Verification had to be real, not simulated: actual unit tests (JUnit, Vitest), actual end-to-end browser tests (Playwright), and an actual PR opened through the GitHub CLI.

My Role

Designer of the agent pipeline and the game's technical foundation: defining how requirements move through planning, implementation, testing, and review stages, what each stage is allowed to do, and what "done" means before a PR is opened.

Architecture / Approach

A requirement enters through a planning stage and flows through implementation, testing, and review stages before release, with each stage scoped to its own responsibility rather than one agent doing everything. On the product side, session identity is handled with a cryptographic per-seat token issued on game creation or join, stored client-side and never re-disclosed by the server. Every board action requires proof of seat ownership, which is what makes "refresh the page and rejoin with your game code" safe rather than a way to hijack someone else's seat.

Key Decisions

• Pipeline stages with distinct responsibilities, not one agent doing everything. Splitting planning, implementation, testing, and review meant each stage could be verified independently instead of trusting one pass to get everything right at once.
• Real verification gates, not self-reported completion. The pipeline runs actual test suites (JUnit, Vitest, Playwright) rather than treating "the agent said it's done" as a completion signal.
• Session correctness via per-seat tokens over trusting the client. Every board-affecting action is checked against a server-issued token tied to that seat, which is what makes multiplayer state trustworthy across reconnects.
• HTTP polling now, WebSockets deferred. State sync currently uses one-second polling, a known, explicit trade-off documented as a future improvement that doesn't require backend domain changes, rather than something hidden or accidentally shipped.

Trade-offs

Running delivery through an agent pipeline end-to-end is slower to set up than opening an editor and writing the feature directly: the value is in what it reveals about where automated pipelines need real guardrails (permission boundaries, verification gates, explicit human-reviewable output) rather than in raw development speed for a project this size. Polling instead of a push-based sync is a simpler, less scalable choice made deliberately for this scope, with the upgrade path already scoped rather than deferred to "figure it out later."

Impact / Outcome

A working multiplayer game (single-player against a computer opponent, two-player over a shared game code, session restore, and pause/resume) delivered through a pipeline that goes from requirement to a reviewed PR without manual implementation steps in between, backed by real unit and end-to-end test coverage.

Lessons

The hard part of agentic delivery isn't getting an agent to write code: it's defining stage boundaries and verification gates precise enough that "the pipeline says it's done" is actually trustworthy. That governance question turned out to be more interesting than the game itself.