I made the experiment: Claude Code as a full engineer on GitLab, as part of the development team for a mini game. I create tickets and review merge requests, while Claude Code submits code as merge requests and iterates on them if required. It worked surprisingly well.
What’s the project? HTTP is the default protocol we use to connect with people and look up information on the web. For a long time, I wanted to offer a service accessible via SSH, where the terminal replaces the browser and SSH replaces HTTPS. To achieve that, I wanted to build a small terminal-based game. Voilà: AsciiMoria. An SSH-based game where players navigate their way through deep and dangerous mines, implemented in Rust.
The development workflow
Claude Code was wired into a project on GitLab, waiting to be assigned to issues with instructions on what to implement. Once assigned, Claude would work on a feature branch and interact with the ticket, asking for clarification if needed, for example. Each ticket would eventually result in a merge request for me to review. If I requested changes, or if the CI/CD pipeline failed, Claude would give it another shot and improve on the previous implementation.
What I liked most about this workflow was remaining in charge. I create tickets, write specs, review merge requests, request changes, and make decisions about the direction of the project. This meant I could focus on thinking about the game’s direction, corner cases, and new features without getting lost in the nitty-gritty details of building a game or an SSH server in Rust. The separation of concerns felt natural: I owned the vision, Claude owned the implementation.
The outcome
Coming straight to the point: the outcome of my experiment is a fun little game, free for everyone to play or fork.
To play it, you need a terminal and an SSH client with a local private key for authentication (ssh-keygen -t ed25519 if you don’t have a key already).
ssh asciimoria.com
The code is open source and available at https://gitlab.sauerburger.com/frank/asciimoria. The repository contains all interactions and conversations with Claude Code.
What did I learn?
A lot. I don’t want to sound foolish claiming that AI taught me things, but I freely admit I picked up many tricks along the way: how to approach certain patterns in Rust, the landscape of open source Rust libraries, new(-ish) features in Docker Compose files, new(-ish) features in GitLab CI/CD configs. Claude is extremely versatile and proficient across a remarkable breadth of technologies.
I also learned just how good AI is at getting things right the first time. We have all committed endless commit chains to fix a CI problem, caused by stupid mistakes, syntax errors, typos, or a general lack of understanding of how to configure the pipeline. Claude did none of that. In nearly every case, it had things right on the first or second attempt.
Perhaps the most surprising lesson was about the level of detail in tickets. When I was thorough in the issue description, Claude followed it to the letter - it had all the specification it needed and delivered exactly what I asked for. On the other end, when tickets were brief and superficial, Claude found sensible ways to fill in the gaps, and I had very few bad surprises. However, there is a dangerous middle ground. When I tried to be clever in the ticket description without fully understanding the underlying complexity and tricky details, Claude would take me at my word and implement something rather nonsensical. To be clear, Claude did see the hidden complexity, it simply trusted that I had made a deliberate choice when writing the specs. The lesson: be either very detailed and understand the underlying complexity or be very brief. Vague specificity is the worst of both worlds.
How was the experience?
Creating this game with AI feels a bit like cheating.
On the other hand, it also gave a very rewarding feeling. Closing tickets and burning through your backlog in very little time releases a lot of dopamine. Going back to writing code the hard way afterwards feels a bit like going through detox.
I was incredibly fascinated by how skilled my new engineer was. And I am not going to lie: it was very convenient to write tickets from my phone on the train and have a merge request ready by the time I got home, with passing unittests and the desired feature materialized in code.
However, I can see people trying to keep an AI agent working 24/7, which is not going to be healthy for our work-life balance. Just because you can create tickets (or maybe even review code) on your phone does not mean you should.
Where to go from here
For hobby projects, there is one important question to ask: do you prefer the activity of coding, or do you prefer having the finished project? To code vs the code.
Code generation has become very cheap, but the cost of ownership remains. You still have to understand the code you ship, maintain it, and make architectural decisions that go beyond what any AI can infer from a ticket. Even before good code generation was available, a key skill in software engineering was to focus on outcome rather than output. That principle is more relevant than ever, now that generating code is just a ticket away. The real work, deciding what to build and why, has not changed.
This might also interest you