Field notes · AI & development
One game. Two AI systems. Less than 24 hours.
How we developed Fakturus Puzzle with Claude and Codex, and what remained to be done.
Fakturus Puzzle began with a simple idea: a game with freely movable pieces, space beside the board and personal photos. No advertising, with a free starting point and a planned full version available as a one-time purchase.
Working with Claude and Codex, we took that idea to a playable development build in less than 24 hours. The systems handled implementation within defined tasks. Here is how the work was organised, what went wrong and what still needed doing before release.
A product decision came first.
Early in the project, wishes found in user reviews became concrete tasks: rotate the pieces. Keep space outside the board. Reliably resume a puzzle. Use your own pictures. Preserve the way a game feels when adding new features.
SwiftUI and SpriteKit provided the technical foundation. A roadmap broke the work into small, verifiable steps. The systems built on existing frameworks and had defined game rules to implement.
From prototype to store captures.
The version history makes the pace tangible. The first prototype was committed at 19:11 on 14 October 2026. Revised store screenshots followed at 11:53 the next morning. That is just under 17 hours, covering many steps from game rules to presentation.
- The prototype arrives.A native jigsaw game with SwiftUI and SpriteKit provides the starting point.
- The rules become testable.PuzzleEngine separates game logic from rendering and input.
- Progress is preserved.Automatic saving and several unfinished puzzles are added.
- Two people can play together.Duo mode brings two players to the same device.
- The result becomes visible.Store screenshots for iPhone and iPad show the game, gallery and purchase screen.
How Claude and Codex worked on the project.
Both systems took part in development. The shared project state mattered: code, roadmap and tests were kept together. A task needed to be small enough to implement, check and preserve as a traceable commit.
The prescribed loop was to write a test for the intended behaviour, implement the feature, clean up and check again. This made it possible to check each task against its requirements.
By “fully autonomous”, we mean independent implementation within these tasks. People supplied the product idea and priorities. The working rules required feedback at milestones and iPhone checks; a later bug fix used a tester's saved game. Git history cannot establish the total amount of human supervision and testing time involved.
Why a puzzle got stuck at 97 per cent.
One documented bug shows why further work was needed: a puzzle looked complete but stayed at 97 per cent. The last piece covered the gap, but sat outside the snapping distance and never locked into place. The fix on 15 October used a real tester's saved game. It adjusted the snapping distance to account for zoom and added a regression test.
Other changes addressed missed grabs, board size, a magnifier covering the hint button and narrow windows. Correct game logic alone does not establish whether a piece feels right under your finger.
The existing tests cover issues including missing pieces, group states and restoring saved games. Complete solving sequences are simulated too. For this report, we read the test code and change history; we did not rerun the game's tests.
How development work is changing.
Comparing this with software development two years ago raises a question for us: how do we describe tasks so systems can work through several steps and check the results on their own? That is the workflow we had to organise for Puzzle.
We had to decide what the game should do, define manageable tasks and check the results. Technical understanding remained important for spotting mistaken assumptions in code and tests.
AI is now part of how we plan to develop software. This workflow changes which ideas we choose to try. Further projects will show which parts of the Puzzle experience transfer to other tasks.
New opportunities. New ways to fool ourselves.
The opportunity is particularly strong for small, well-defined products. A specialist tool for a business, an audience previously considered too small or an unusual game mode become easier to try. Early feedback can happen around something usable.
Speed also increases the amount that needs checking. Two AI systems can share the same mistaken assumption. Tests can confirm an implementation while missing an incomplete requirement. Attractive interfaces can hide unfinished recovery paths, error handling or privacy work.
Permissions become a product decision too: which files may an agent change? Which credentials does it need? Which actions affect real users? A fast development process needs clear boundaries and a way back if a change fails.
The project also records where its puzzle photographs and paintings come from and how they are licensed. The app icon was generated. The two silver conceptual images in this article are AI-generated as well; the game captures come from the project. Making that distinction is part of quality for us.
Which features belong in the game?
A short development cycle can tempt you to keep adding features. Duo mode lets two people play Puzzle on one device.
The next decisions still require judgement: is it understandable? Does anyone need it? Is the additional maintenance and support worthwhile? An autonomously written feature does not answer those questions by itself.
At the project state reviewed here, the roadmap still listed accessibility, further device checks, setting up the in-app purchase, privacy and legal review, beta testing and App Store release as open. A roadmap can lag behind the actual work; it does not establish that these tasks were complete.
Claude and Codex brought this project to a playable state quickly. Further use will show whether the workflow holds up for other products and how much maintenance it requires.