{"slug": "workshop-brief-battleship-with-human-steered-ai", "title": "Workshop Brief: Battleship with Human-Steered AI", "summary": "A workshop brief outlines an experiment in which a human ensemble steers an AI coding agent to build a Battleship game engine with a separate text client, rather than letting the AI work autonomously. The brief requires the AI to draft plans, designs, code, and tests while humans retain responsibility for rules, API, architecture, and test decisions, and to surface open questions in a clarification session instead of assuming standard Battleship rules. It also mandates a shared Spec Loop DDD glossary and defers bonus features like variable board size and two-player mode until the main part is accepted.", "body_md": "This file contains the original workshop specification used during the workshop. See the workshop analysis and the revised version below.\n\nThis brief is shared unchanged with workshop participants and the AI coding agent.\n\nThis workshop is meant for a human ensemble working together, not for a single human occasionally approving the AI's work.\n\nThe human ensemble may add its own instructions first, or ask the AI to start with a clarification session.\n\nThis workshop is an experiment in using an AI coding agent without turning the human ensemble into passive observers.\n\nThe human ensemble stays responsible for the whole result. The humans do not need to type everything, but they do need to steer the work, review it, and accept it together.\n\nThe AI may draft plans, designs, code, and tests, but it must not quietly take over important decisions about the rules, the API, the architecture, the design, or the tests.\n\nBuild a Battleship game engine that is separate from any presentation layer.\n\nThe required client is a small text client used to test and play the engine.\n\nAfter the main part is accepted, the group may optionally add a browser demo on top of the same engine. The browser demo is out of scope until the group explicitly brings it into scope.\n\n- Start with a one-player game.\n- Use a 10x10 board.\n- Use this fleet, described only by length and count:\n  - 1 ship of length 4\n  - 2 ships of length 3\n  - 3 ships of length 2\n  - 4 ships of length 1\n- Do not rely on standard ship names from another version of Battleship.\n- Any ship may be marked as a submarine.\n- Submarines may occupy different depths.\n- Only depth charges can hit submarines.\n- The engine and the text client must stay separate.\n\nThis workshop is supposed to include real discussion. Not everything is fixed up front.\n\nImportant parts of the rules, the engine API, the architecture, the class-level design, and the test design are intentionally left open. The group should discuss them. The AI should actively surface them in a clarification session.\n\nIf an unclear point could change behavior, the public API, the design, the tests, or the task breakdown, the AI must ask instead of silently assuming a standard Battleship rule.\n\nThe AI should not waste time asking about obvious, trivial, or already settled points.\n\nThis workshop must use a shared glossary.\n\nUse it as a Spec Loop DDD glossary: a shared domain language for the workshop, not a dump of implementation terms.\n\nUse the glossary for important game-rule, API, and design terms that need one stable meaning across clarification, task files, design, and test specification.\n\nReuse existing agreed terms instead of inventing local synonyms. When a clarification session settles a term or changes its meaning, record it before later work depends on it.\n\nDo not let the same word quietly mean different things in different parts of the workshop. Do not put implementation-local details into the glossary unless they are part of the reviewed contract.\n\nThe main part is the smallest reviewable version that satisfies the workshop baseline. It includes:\n\n- a game engine that is separate from the client\n- a small text client that can play against that engine\n- starting a game\n- showing enough game state to play\n- performing attacks\n- enough support for submarine behavior that the engine/client boundary still makes sense\n\nThe exact engine API is not fixed here. The engine must support starting play and performing attacks, but the concrete public contract is part of the workshop design.\n\nKeep these as bonus features only. Do not plan or implement them before the main part is accepted.\n\n- variable board size\n- game statistics\n- two-player mode\n\n- showing statistics on demand\n- two-player terminal play\n- player-specific prompts\n- showing both boards at the end of each turn in two-player mode\n\nThe human ensemble is responsible for the whole result: the rules, the API, the architecture, the design, the implementation direction, the test intent, and the final acceptance.\n\nThe AI may write artifacts and code, but that does not move responsibility away from the human ensemble.\n\nThis is the default flow. The group may adapt it, but the review gates below must still be respected.\n\n1. The human ensemble discusses the game, the workshop goal, and any extra instructions.\n2. The AI runs a clarification session for the current scope.\n3. The human ensemble confirms the clarified baseline for the current scope.\n4. The AI creates a vertical breakdown as separate task files.\n5. The human ensemble reviews that breakdown.\n6. The AI prepares the current task file in implementation-ready detail.\n7. The human ensemble reviews and approves the current task's scope, class-level design, and exact test specification.\n8. The AI implements and tests the current task.\n9. The human ensemble reviews the result.\n10. Repeat for the next task.\n\nBecause this workshop uses separate task files and no subtasks, the human ensemble may choose the working mode separately for each task.\n\nFor a given task, one AI session handles the work in order.\n\nIf an important change appears during implementation, it goes back to planning and human review before implementation continues.\n\nFor a given task, the group may work on later tasks while an implementation agent works on the current approved task.\n\nIn parallel mode:\n\n- each reviewable slice gets its own task file\n- do not use subtasks for this workshop\n- the planning agent may edit task files, but not code\n- the implementation agent may edit code and add `Implementation notes` , but must not otherwise edit task files\n- no worktrees are assumed\n- if the implementation agent makes an important deviation to keep\nmoving, it must record that deviation in `Implementation notes` and\nbring it back for explicit human accept/reject review before the task\nis accepted\n- after humans accept a deviation, the group must make sure the task files and other planning artifacts are brought back into sync before later work depends on them\n\nThis workshop uses Spec Loop explicitly.\n\nThe AI must:\n\n- begin with a clarification session by using\n`spec-loop-clarify-task`\n- use a clarification session before planning whenever important open decisions remain\n- actively surface important open decisions about rules, API, architecture, design, and test specification\n- after the clarification session, stop for human confirmation of the clarified baseline before creating task files\n- avoid fake safety theater: do not present artificial alternatives for obvious points\n- use the task-file path, not chat-only planning\n- use the Spec Loop DDD glossary rules and keep the shared domain language updated for important terms\n- use separate task files for separate reviewable vertical slices\n- avoid subtasks in this workshop\n- split work into small reviewable slices of behavior whenever a credible split exists\n- avoid planning-only, test-only, or layer-only implementation tasks unless the humans explicitly ask for that structure\n- prepare only the current task in full implementation-ready detail\n- before asking to implement the current task, make sure humans have\nreviewed and approved:\n  - the current task scope\n  - the class-level design\n  - the exact test specification\n- use `spec-loop-prepare-execution-approval` before asking to\nimplement the current task\n- use `spec-loop-implementation-flow` after implementation is approved\n- in sequential mode, send important implementation-time changes back to planning and human review before continuing\n- for each task, allow the human ensemble to choose sequential or parallel mode\n- in parallel mode, a workshop-specific override is allowed: the\nimplementation agent may keep moving through some important\ndeviations, but it must record them in `Implementation notes` and\nbring them back for explicit human review before the task is accepted\n\nThe implementation stack is intentionally not fixed in advance.\n\nThe group may choose it during the session. If the stack choice could change the design, the tests, or the task shape, the AI should raise it in the clarification session rather than assume it.\n\nA browser demo may be added only after the main part is accepted. Until then, do not treat it as part of the main scope.\n\nBy the end of the workshop, the group should have:\n\n- a clarified baseline for the current scope\n- a shared glossary for the current scope\n- a task-file breakdown into small reviewable slices\n- an implementation-ready current task with class-level design and exact test specification before coding starts\n- reviewed code and tests for completed tasks\n- a working engine plus text client before any bonus work begins\n\nDo not start by coding.\n\nStart with a clarification session for the current scope. Resolve what is already settled. Ask about important open decisions. Do not silently fill important gaps with assumed standard Battleship rules. After the clarification session, stop for human confirmation of the clarified baseline. Then create or update task files, prepare the current task for human review, and wait for approval before implementing.", "url": "https://wpnews.pro/news/workshop-brief-battleship-with-human-steered-ai", "canonical_source": "https://gist.github.com/dpolivaev/f9c81b46ed999070064b1b3eff40fb25", "published_at": "2026-08-28 15:21:31+00:00", "updated_at": "2026-09-10 06:20:50.595151+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": [], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/workshop-brief-battleship-with-human-steered-ai", "markdown": "https://wpnews.pro/news/workshop-brief-battleship-with-human-steered-ai.md", "text": "https://wpnews.pro/news/workshop-brief-battleship-with-human-steered-ai.txt", "jsonld": "https://wpnews.pro/news/workshop-brief-battleship-with-human-steered-ai.jsonld"}}