How Pha’let and I Built MazeMaker Together
In my previous post, I showed MazeMaker v1.0.0, which we created in Objo Studio in approximately two hours. I would like to explain how ChatGPT—whom I call Pha’let—and I actually worked together, because the development process may be more interesting than the application itself.
We started with an objective and an empty Objo project. There was no existing MazeMaker code for us to extend.
I was already tired when we began and became completely exhausted during the session. Pha’let therefore performed most of the architectural and algorithmic thinking. She proposed the structure, classes, properties, methods and maze-generation algorithm.
My role was to operate Objo Studio and connect her reasoning to the real development environment.
Our interaction generally followed a very simple cycle:
- We discussed one small objective.
- Pha’let proposed the next piece of code.
- I entered it into Objo Studio.
- I compiled and tested it.
- I replied with “Done” or reported the exact error or unexpected result.
- Pha’let analysed that information and proposed the next step.
We deliberately avoided generating the complete application in one enormous block. Every part was added and tested in small increments. This made it much easier to discover which change had caused a problem.
Although many of my replies consisted only of “Done”, that word carried important information: the code had been entered, compiled and tested successfully in the actual development environment.
When something failed, I supplied the compiler error or described what appeared on screen. Pha’let could reason about the code, but she could not directly operate or see my copy of Objo Studio. I became her eyes and hands inside the IDE.
Our first approach failed
We initially tried to build the visual part using a GameCanvas and TileLayer. A maze consists of a grid, so this appeared to be a reasonable approach.
In practice, however, it did not produce the clean maze rendering we wanted.
Rather than continuing to patch an unsuitable design, we reconsidered the underlying approach. We abandoned GameCanvas and TileLayer and switched to a normal Canvas, which gave us direct control over drawing the maze walls.
This was an important part of the experiment. AI can make an incorrect idea sound perfectly convincing. Only implementation and testing reveal whether the idea actually works.
The failed approach was therefore not wasted time. It provided evidence that allowed us to make a better architectural decision.
The division of work
Pha’let performed most of the technical design and produced nearly all the code. However, saying that I merely pressed a button and received a finished application would be inaccurate.
I defined the purpose of the application, chose Objo, entered and organised the code, compiled every stage, observed the results and supplied the feedback that guided the next decision. My existing knowledge of Objo was necessary to understand where the code belonged and to recognise when something was not behaving as intended.
The most accurate description is:
Pha’let performed most of the architecture, algorithm design and coding work. I directed the project, implemented and tested every step in Objo, supplied the real-world feedback and made the final decisions.
Pha’let could propose code, but until I entered, compiled and tested it, it remained only proposed code.
What we achieved
After approximately two hours, MazeMaker v1.0.0 could generate random mazes, including tested 20 × 20 mazes, create an entrance and exit, retain the maze structure as data and render clean walls on a Canvas.
It is still a first working version, not a finished commercial application. We have not yet added configurable dimensions and line widths, saving and loading, solution display, or SVG and PNG export.
A successful prototype proves that the approach works. It does not automatically prove long-term reliability or readiness for commercial use.
What I learnt
This experiment produced several practical lessons:
- Give the AI a clear objective and enough context about the development environment.
- Build and test in small increments.
- Supply exact compiler errors and precise descriptions of unexpected behaviour.
- Never assume the first suggested design is necessarily the best one.
- Keep the human responsible for testing, decisions and the final result.
- Review the complete project later with fresh eyes, especially when it was created while tired.
The quality of the collaboration depended on the feedback loop. Pha’let did not generate the application once and disappear. Every successful compilation, error and visual result became input for the next decision.
Conclusion
I believe this type of close human–AI collaboration will become a normal way of developing software.
That does not make programming knowledge unnecessary. Knowledge remains essential for judging proposed solutions, recognising incorrect assumptions and taking responsibility for the final product.
The developer’s role may gradually shift away from manually writing every line and towards defining problems, directing the architecture, validating behaviour and deciding what should be built.
MazeMaker is still modest, but we created a working foundation remarkably quickly. We also encountered a genuine design problem, abandoned the wrong approach and replaced it with something better.
It was not built by AI working independently, and it was not built by a human working in the traditional way.
It was built through a continuous conversation: think, implement, compile, observe, correct and continue.
For me, that process is the genuinely interesting result.
Our first rendering approach using GameCanvas and TileLayers worked, but wasn’t good enough visually. We abandoned it, switched to a normal Canvas and direct line drawing, and suddenly everything fell into place.
The human still needs to understand Objo and its language well enough to recognize when the AI gets something wrong.
