Marcin AI gave GPT-5.6 three very different jobs: rebuild a company website from screenshots, create a native iOS alarm app, and build a 3D chessboard controlled by spoken moves. The landing page is the easiest result to admire. The voice-controlled chessboard is the result worth studying.
A useful voice chess app has to make several systems agree. It must hear the user, understand chess notation expressed in ordinary language, reject illegal moves, maintain turn state, preview the intended move, wait for confirmation, and render the result correctly. A beautiful board is only one layer of that problem.
Video credit: Marcin AI. Watch the original GPT-5.6 three-build test on YouTube.
Source Note
This article uses Marcin's video and transcript as the source for the three builds, his prompts, timings, and observations. The reported seven-minute chess build and 23-minute iOS build are creator-reported results, not controlled benchmarks. Hardware, model access, reasoning settings, project context, tool permissions, and retries can all change the outcome.
OpenAI's GPT-5.6 launch page and current model guide are the source of record for model capabilities and availability. The architecture recommendations below use official documentation for Three.js, chess.js, the Web Speech API, and Apple Core Motion.
Link Map
| Resource | Status | Why it matters |
|---|---|---|
| Marcin AI: three GPT-5.6 builds | Creator test | The company website, voice-controlled 3D chessboard, native Swift alarm app, and the reported build process. |
| Marcin AI on YouTube | Creator credit | Original creator and source channel for the hands-on test. |
| OpenAI GPT-5.6 | Official | Product positioning, model family, capabilities, pricing, and official benchmark context. |
| OpenAI latest-model guide | Official docs | Current model-selection guidance before changing a production default. |
| Three.js scene guide | Official docs | The rendering layer for the browser-based 3D board, camera, lighting, pieces, and move animation. |
| chess.js | Official docs | A headless chess library for legal move generation, validation, board state, FEN, PGN, check, and game-over rules. |
| MDN Web Speech API | Technical reference | Browser speech recognition and synthesis, with compatibility and service-dependency caveats. |
| Apple Core Motion | Official docs | The native motion and fitness layer behind step-dependent iOS behavior. |
| GPT-5.6 Sol vs Fable 5 | JQ comparison | A broader comparison using three creator tests, official prices, and a cost-per-accepted-result framework. |
Three Builds, Three Different Tests
These projects should not be treated as one score. Each one tests a different part of agentic software development.
| Build | What GPT-5.6 had to do | What the demo proved | What it did not prove |
|---|---|---|---|
| AI Builders landing page | Interpret screenshots, extract brand cues, write copy, structure sections, and create a responsive page. | Strong visual synthesis from limited reference material. | Conversion performance, accessibility, analytics, SEO, and maintainability. |
| Voice Gambit chessboard | Render 3D chess, recognize speech, parse moves, validate legality, preserve state, preview, and confirm. | A surprisingly complete interactive prototype from a loose spoken brief. | Full chess correctness, cross-browser reliability, accessibility, safety, and production QA. |
| Steppy native iOS app | Build a Swift interface, schedule alarms, request motion access, count steps, and gate dismissal. | A polished native interface and working flow after iteration. | First-pass sensor permissions, App Store readiness, battery behavior, and all alarm edge cases. |
The Website: Visual Context Beats a Blank Prompt
Marcin supplied screenshots from his private AI Builders community and asked GPT-5.6 to create a one-page public landing page. The prompt was deliberately loose: use the material, add the expected sections and footer, include a prominent signup button, and exercise broad design freedom.
The useful technique is not the enthusiastic wording. It is the context package. Screenshots gave the agent real language, visual cues, product structure, and proof points. GPT-5.6 then turned those references into a coherent page and reused the logo. Marcin called it the cleanest one-shot landing page he had seen from this kind of prompt.
That is a good first pass, not a launch certificate. A real website still needs factual copy review, responsive checks, keyboard navigation, contrast, form behavior, event tracking, performance, metadata, and a human decision about what the page should persuade a visitor to do.
The Voice-Controlled Chessboard Is the Real Test
Marcin's brief asked for a web-based 3D chess game using Three.js. The defining interaction was voice: say a move, see a preview of the proposed destination, then say confirm or cancel. GPT-5.6 produced a project Marcin called Voice Gambit and reported that it took about seven minutes.
In the recorded demo, the app heard a white pawn move to E4, previewed E2 to E4, waited for confirmation, executed the move, and changed the turn. It rejected a white knight request when black was to move, then accepted a legal black knight move to F6. That is much more meaningful than moving a decorative piece across a board because it suggests that speech, legal-move logic, turn state, preview, and rendering were connected.
Marcin also said the prototype still had logic issues. That detail matters. A single successful line of play does not test castling, en passant, promotion, check, checkmate, disambiguation between identical pieces, undo behavior, microphone failure, or what happens when recognition returns the wrong square.
How the Chessboard Should Be Architected
The model should not improvise chess rules inside UI code. A production-minded version separates probabilistic interpretation from deterministic game logic.
| Layer | Responsibility | Recommended boundary |
|---|---|---|
| Speech input | Capture a phrase such as "knight to F3" and expose confidence or alternatives. | Web Speech API or another speech provider, with text and touch fallbacks. |
| Move parser | Convert natural language into structured intent such as piece, origin, destination, capture, or promotion. | Deterministic grammar first; use an LLM only for ambiguous phrasing, never as the rules engine. |
| Rules and state | Validate legal moves, whose turn it is, check, mate, draws, castling, en passant, and promotion. | chess.js or another tested chess library. |
| Confirmation | Highlight the proposed origin and destination, then require confirm or cancel. | A small explicit state machine with timeout and visible controls. |
| 3D presentation | Render the board and pieces, animate legal moves, and expose accessible status text. | Three.js, driven by the validated game state rather than its own copy. |
| History and recovery | Save position, move history, transcript, parsed move, validation result, and restore state. | FEN for board state, PGN for game history, plus structured event logs. |
The data flow should be simple enough to inspect: microphone -> transcript -> parsed move -> legal-move validation -> preview -> confirmation -> committed state -> 3D render -> log. If any layer fails, the move should not be committed.
The Voice Test Matrix the Demo Still Needs
| Test group | Examples | Expected behavior |
|---|---|---|
| Normal phrasing | "Pawn to E4", "move the G knight to F3", "castle kingside" | One structured legal move, visible preview, no commit before confirmation. |
| Speech ambiguity | B versus D, E versus G, "four" versus "for", low-confidence transcript | Ask a short clarifying question or show alternatives. Never guess and move. |
| Illegal moves | Wrong side, blocked piece, king left in check, impossible destination | Reject with a useful reason and preserve the current board state. |
| Special rules | Castling through check, en passant, promotion choice, threefold repetition | Match the rules library and add focused automated tests. |
| Confirmation state | Confirm, cancel, silence, unrelated speech, new move before confirmation | Use explicit states, timeout safely, and prevent duplicate execution. |
| Browser failure | Microphone denied, unsupported browser, network loss, tab backgrounded | Explain the problem and keep keyboard, notation, or touch controls available. |
| Accessibility | Screen reader, keyboard-only play, reduced motion, color-blind states | Expose board state and controls without depending on the 3D canvas alone. |
Browser speech support must be tested rather than assumed. MDN documents both recognition and synthesis under the Web Speech API, but implementations differ and some recognition paths may depend on a remote service. A local-looking web app is not automatically an offline or private voice app.
The Native iOS App: Permissions Are Product Logic
The third main build was Steppy, a native Swift alarm app that requires the user to walk a chosen number of steps before silencing the alarm. Marcin reused a prompt from an earlier Fable 5 build and asked GPT-5.6 to create the app in Codex.
The first result looked polished and the alarm fired on a physical phone, but step tracking did not work. The motion and fitness authorization path had not been wired correctly, and opening Settings did not expose the expected permission. Marcin described the issue in a second prompt, after which the app requested access and the flow improved. He reported roughly 23 minutes for the build.
This is exactly why native app testing cannot stop at the simulator or visual review. A step-gated alarm depends on the correct Core Motion API, a valid motion usage description, authorization state, sensor availability, background behavior, alarm scheduling, battery constraints, interruption handling, and tests on actual devices. Permissions are not setup decoration. They are part of the product's core logic.
Did GPT-5.6 Kill Fable 5?
No. The video is a strong GPT-5.6 field test, not a controlled model comparison. The website and voice chessboard were not shown against Fable with the same environment, tools, prompt, and evaluation rubric. The iOS app had a closer comparison because Marcin had built it with Fable before, but the GPT-5.6 version needed a second permission fix and the earlier Fable run was not reproduced side by side in the video.
What the test does support is narrower and still valuable: GPT-5.6 can turn loose multimodal context into substantial working prototypes, run independent projects concurrently, create polished interfaces, and recover when a real-device test exposes a missing implementation detail. That is enough reason to evaluate it on your own work. It is not enough reason to replace every model or engineering control.
For a broader comparison, see GPT-5.6 Sol vs Fable 5: The Manager, the Worker, and the Real Cost. The practical choice is often routing: use the model that frames the problem best, the model that executes economically, and deterministic checks that neither model controls.
A Better Prompt for the Voice Chess Build
Marcin intentionally used a loose spoken brief to test how much GPT-5.6 could infer. For a project you want to keep, replace the open-ended demo prompt with a short specification and acceptance tests.
Copy-ready production brief:
Build a browser-based voice-controlled 3D chess prototype.
GOAL
Let a player speak a move, preview the interpreted legal move,
and confirm or cancel before the board changes.
REQUIRED ARCHITECTURE
- Three.js renders the board and pieces.
- chess.js is the only source of truth for rules and game state.
- Speech is parsed into structured move intent.
- Do not let an LLM or rendering code decide move legality.
- Save FEN, PGN, transcript, parsed move, and validation result.
INTERACTION
- Accept voice, keyboard notation, and touch input.
- Show the heard phrase and parsed move.
- Highlight origin and destination.
- Require confirm or cancel before committing.
- Ask for clarification when more than one move is possible.
ACCEPTANCE TESTS
- Legal opening moves work for both colors.
- Wrong-turn and illegal moves never change state.
- Castling, en passant, promotion, check, and mate are tested.
- Duplicate confirmations cannot execute a move twice.
- Microphone denial and unsupported browsers fall back cleanly.
- Keyboard-only and screen-reader status are usable.
DEFINITION OF DONE
Run automated rule and state tests, complete a browser walkthrough,
list remaining risks, and do not call the build finished while tests fail.
SAFETY
Position this as a parked or passenger experience, never for use
by a driver while a vehicle is moving.The improved prompt gives the agent less room to hide a rules bug behind a beautiful board. It also defines what "done" means before the model starts coding.
What Builders Should Copy
- Give the model real context. Screenshots, existing assets, product language, and the target environment are more useful than adjectives.
- Separate generative work from deterministic truth. Let the model build the experience, but let tested libraries own chess rules, payments, permissions, calculations, and security boundaries.
- Test the real surface. Use the physical phone, target browser, microphone, accessibility tools, and production-like data.
- Keep confirmation for ambiguous actions. Voice is convenient precisely because it is imperfect. Preview before changing state.
- Use parallel agents only for independent work. Running the chess and iOS projects together is useful; sharing unverified state between them would not be.
- Turn every failure into an acceptance test. The missing motion permission should become a permanent device test, not just another prompt.
- Call it a prototype until the evidence says otherwise. One-shot describes how the code appeared, not whether the product is finished.