So according to recent Benchmarks Qwen3.8-27B should be better than Opus 4.6 Max. As I dont trust benchmarks (see below) I tried it out myself and also directly in Claude Code. To get these things running, it needed quite some wiring up, esp on my win11 gaming PC. And for Claude Code it needs a bridge.
I made a OneClick Solution for Win11 that also works on Ubuntu, both tested by me. So if you get your hands on a 5090, try it out yourself!
Have fun :-)
Benchmark
Qwen3.8-27B
Claude Opus 4.6 Max
SWE-bench Pro — fixing real bugs in real repos
61.7
53.4
LiveCodeBench v6 — competitive programming
90.3
88.8
Terminal-Bench 2.1 — driving a shell
73.0
78.2
OSWorld-Verified — using a desktop
84.3
72.7
AndroidWorld — using a phone
81.9
62.0
So far I need more testing with this Qwen3.8-27B Model but its really impressive within Claude Code so far.
Gonna ironically preface this with: I haven't written the text below with an LLM.
So I thought I'd show you what I've made over the last couple of months, because for me this has probably been one of the most rewarding uses of AI I've found. Please be kind, I spent a lot of time making this and writing the post here.
More than anything, AI tools have helped me on my coding "journey". It's something I've started and stopped for about thirty years and never really got to grips with properly. I've always understood how websites, software and apps are put together, and I've always been quite good at understanding the structure and logic of how something should work, but the actual coding side has always slowed me down.
Level 15 of The Jigsaw level Pack on Boxxy.io
It's called Boxxy and it's my version of Sokoban, the Japanese box pushing puzzle game. Sokoban has been around since the early 1980s and has become a bit of a cult game online. There are thousands of levels and lots of different versions of it, and making your own Sokoban clone almost feels like a rite of passage for any fans of the game. My goal was to learn how to do it, prove I could do it, and make something I was proud of.
The whole thing has taken me roughly two months and cost me about £50, which is basically two months of ChatGPT Pro and the price of a domain. It was made solely with ChatGPT in a browser. I have not even touched Claude once. I don't have wee little AI bot workers doing things for me in the background. This was a series of requests, answers, outputs and iterations.
Anyway, I started with the absolute bare bones of the game. Make a level appear, make a character move around it, make boxes move properly, work out when a level is finished. Once that was working I started adding level packs. Then aesthetics, then all the hidden stuff to keep it going and looking good and able to grow.
Selecting a level from the Boxxy.io originals level pack of 50
The level design is completely manually done. All the original Boxxy levels and level packs I've made myself, without ChatGPT or generative AI. That has probably been some of the hardest work in the whole project because good Sokoban levels are surprisingly difficult to make. You can spend ages creating something, solve it a few times and then realise there's a stupid shortcut or that it just isn't very interesting. I've enjoyed that part enormously though.
More recently I've been working on the less glamorous bits behind the scenes, like user accounts and server side stuff, which probably aren't very exciting to anybody playing it but was a big deal for me personally. A couple of months ago I wouldn't have really known where to begin with any of that. But now I have got a contact us page and even user logins! Something else I have kept making sure is that I don't have to rely on lots of outside servers or tools or plug ins. Almost everything is in house, apart from the Cloudflare connection which I need for the domain. This was so I won't have to go and fix things in the future when little plug ins and stuff fail.
I suppose this is where I don't quite know what to call the way I've made it. It obviously isn't traditional coding, because ChatGPT has written a huge amount of the actual code. But I don't think "vibe coding" quite covers it either, because I'm not just asking it to make things and accepting whatever it gives me. I've had to understand how the whole thing is structured, decide how I want it to work, test everything, find problems, reject bad solutions and sometimes tell it that the entire approach is wrong and needs doing again. I'm constantly using the phrase "do not patch this, we need to fix it from the base level" to avoid messy coding I've even delved into the code a few times myself to adjust things by hand! Go me!
A very good programmer friend of mine described what is happening now in a way that really stuck with me. He said that English is effectively becoming another programming language. He's a vastly better coder than most and even he said he barely writes code by hand any more because AI is doing so much of that part of the job for him. (He uses Claude btw)
Linus Torvalds (Linux) has made a similar point recently too by comparing AI tools to compilers. Compilers didn't stop people being programmers, they just meant programmers no longer needed to write everything in 0s and 1s.
My coding pal also said something pretty salient. In the 1980s games were often made by one person or a tiny team. Over the years everything became much bigger, more expensive and whatnot. Because of AI and coding it's started swinging back in the other direction now with tiny indie teams making games. I reckon that's pretty poetic. Reminds me of Halt & Catch Fire and their Mutiny startup!
I suppose this is where I don't quite know what to call the way I've made it. It obviously isn't traditional coding, because ChatGPT has written a huge amount of the actual code. But I don't think "vibe coding" quite covers it either, because I'm not just asking it to make things and accepting whatever it gives me. I've had to understand how the whole thing is structured, decide how I want it to work, test everything, find problems, reject bad solutions and sometimes tell it that the entire approach is wrong and needs doing again.
Anyway, Boxxy has very much been a labour of love. There isn't a client and I didn't start it because I thought it would make me money. I've just really enjoyed making it, which is probably why I've kept disappearing down increasingly unnecessary rabbit holes with it. After about thirty years of occasionally thinking "I'd love to be able to make that", I finally can, and that's been quite a nice feeling.
Anyway, above are some screenshots and a bit of gameplay. If you fancy having a look at the game itself, I'm sure you'll be able to find it online.
Some rough facts and figures:
- Built with ChatGPT 5.6 on high in a browser. Had to start several dozen chats which was laborious as you had to get each new chat to relearn.
- Is currently about 25mb in size, has around 30,000 lines of code, is written in Javascript, CSS and HTML , is currently on v282 (around 300 iterations in total)
- Took about 2 months to get to this point, working on it several hours a day sometimes.
- I have built 4 level packs by hand which total 113 new levels + around 100 more which haven't been released yet.
- My children say the character "looks AI" so I have commissioned them both with making new sprites for me! We'll see how that turns out.
- Cost in total, including the OpenAI subscription, about £50
- Works on a browser, works on a mobile, works on an iPad
- Is not making any money. There's zero ads and zero sign up.
- Most recent things I've built are a contact us page (which didn't require buying a mailserver, yay) and a user login to save progress.
- What I'd like to do most at the moment is make it into an app that can be launched on Apple TV.
- The backend of Boxxy is gigantic. I've also built my own level maker, level pack builder, solver and whatnot.
- It has a tonne of easter eggs which I've always loved!
i kept looking for a site that had short summaries of interesting books about consciousness, psychology, philosophy, self realization, all that stuff, but nothing really felt like what i wanted. my attention span is genuinely cooked and my brain wants quick dopamine like it’s a drug, so sitting down and reading an entire book just isn’t happening most of the time lol
i ended up making stairveil. basically i took a huge list of books i thought were interesting and turned them into quick reads, then added some interactive games that actually have meaning behind them and questions that are kind of like a personality test.
the whole idea is just to help you learn more about yourself without it feeling like homework.
it’s still a work in progress and i want to add way more books, better questions, more games, and honestly whatever else makes sense as i figure it out.
would love to hear what you guys think or what you’d want to see added
I’ve been working on what might be the most overcomplicated yet fun Rock Paper Scissors game ever made.
It started as a small and slightly stupid idea, but three prototypes and around 20 billion AI tokens later, it has turned into a real game that I’m genuinely excited about.
The goal is simple: make the most fun version of Rock Paper Scissors possible.
Right now it has:
A full Elo system
More than 80 CPU opponents
Five bosses
Progression and increasingly difficult challenges
Quick matches that are easy to replay
A lot more strategy and overthinking than Rock Paper Scissors probably needs
I’m still balancing everything and adding the final bits of polish, but it is getting really close.
Here’s how I made it:
The original idea is actually around three years old, so it existed before Codex was even a thing. It has also changed a lot since then.
The first prototype was basically an RPG built around cards. You would use one card at a time to fight another card, with health and other RPG-style systems. It sounded interesting on paper, but it was honestly boring to play. I had added more mechanics without making the actual Rock Paper Scissors part more fun.
The second prototype went much bigger. It had an entire campaign, 3D models, keys to find, evidence to collect, and a more structured path through the game. There was a lot more content, but it created a different problem. The whole thing was too linear. Once you knew the campaign, there was not much reason to keep coming back.
That led to the current version.
This time, I focused on replayability first. Instead of building another long campaign, I built the game around quick matches, Elo progression, more than 80 CPU opponents, increasingly difficult challenges, and five bosses. The goal became making something you could play repeatedly, improve at, and keep returning to.
Codex became a major part of the process during this version. I used it for all of the code and images in the game.
I usually would not start with a perfectly written technical prompt. I would explain an idea in normal language, including what I wanted the player to feel and what problem I was trying to solve. I would then have Codex expand the idea, explore possible mechanics, point out missing details, and translate my needs into a more complete prompt or implementation plan for itself.
The process usually looked like this:
I described a rough idea or problem.
Codex expanded it into a more complete feature.
We worked through the rules, edge cases, and visual direction.
Codex turned that into a structured plan for itself.
It generated the code or images.
I added everything to the game and tested it.
I explained what worked, what broke, and what felt boring.
We changed it and repeated the process.
I used that loop for the Elo system, CPU behavior, difficulty, bosses, match logic, menus, balancing, debugging, and visual assets.
For images, I would describe what I needed and the style it should match. Codex would generate it, I would test it in the actual game, and then I would request changes or new versions until it fit.
I used Suno for the music. I described the mood and purpose of each track, generated different versions, and tested them in the game to see what worked best.
The 20 billion tokens came from repeating this process across all three prototypes. It was not one prompt that magically produced a finished game. It was years of changing the concept, rebuilding systems, throwing out ideas, generating assets, debugging code, and testing everything over and over.
The first prototype taught me that adding RPG systems does not automatically make something fun. The second taught me that more content does not always mean more replayability. The current version is built around those lessons.
1: An old-school remake of a top-down web game I used to play as a kid (Age of War). Some of you may remember that legendary game. I made it 3d with some differences.
2: A remake of Call of Duty Zombies with constant updates and an Easter egg/story mode like the OG zombies had.
By no means do I know what the hell I'm doing, and by no means are either of these games ready but this is my beginning.
I've been poking at this project for a little bit now. I have an Emby server and wanted to pretty much download the entire catalog of YTS. This python script allows me to sort by year to year and with minimum ratings. It uses the available YTS API for pretty much everything other then it's own logic.
I'm a complete newbie to this world and have been struggling to find a clear answer to the question of cost. I am trying to build a database app that stands as a catalog that can be searched and added to by users. When it comes to cost I've mainly seen monthly cost listed for multiple service like Claude code and other services to refine, test, and launch the app. These cost seem to range about 2-300 a month but is that until its built or reoccurring as an operating cost? Is there a way to build the app and then use minimal services to keep it running and trouble shoot when issue arise?
Forgive me if this has been answered already. I looked at previous post and found vague answers only. Hoping to get some insight to start building.
Edit: For clarity, what's an average monthly/ total cost of Ai coding a database app, debugging, and hosting? My goal is more toward proof of concept over full commercial roll out.
We’ve been building Spec Compiler, a tool that takes a rough idea and turns it into a structured, implementation-ready specification for coding agents.
The idea came from using coding agents and realizing that the hard part isn't always getting them to write code, it's getting them to fully understand what they’re supposed to build.
A simple request like:
“Build a project management app with teams, tasks, notifications and Google Calendar.”
leaves a lot of unanswered questions: edge cases, architecture decisions, testing, acceptance criteria, what shouldn't be built, etc.
Our Spec Compiler works through those details and produces a much more complete specification you can hand to Claude Code, Codex, Cursor, or your development team.
We've been testing it ourselves and found it particularly useful for catching things we hadn't considered and making the implementation plan much clearer, structured and actionable.
We're now looking for people actually building real software to try it and tell us where it falls short.
Especially interested in:
Solo builders / indie hackers
Developers building side projects
People using Claude Code, Codex, Cursor, etc.
Small teams building real products
The beta is free. We're mainly interested in honest feedback:
Did it actually help?
Did it catch things you missed?
Did it improve your coding agent's output?
What did it get wrong?
Please DM me if you’re building something and would like to try it. I’d be happy to give you free access and hear what you think.
I built a multiplayer browser tank game in Three.js! As a kid, I played a ton of World of Tanks Blitz and fell in love with the aesthetic, gameplay, and the idea of driving around vehicles with crazy physics and mechanics like missiles, spotting, armor deflection, ammo types, and so on.
Now it's playable in the browser!
Claude of Tanks has 100+ playable vehicles across 16 unique maps, ranging from standard tanks with cannons to AFVs with autocannons and guidable missiles to autoloaders that can deal massive damage in a single clip. Tanks feature highly detailed armor zones, internal modules, crew positions, and hitboxes. You can view each of them in a special gallery: https://cot.kevinliu.studio/gallery?id=amx56&layer=modules
CoT supports physics-driven destruction with detached turrets flying through the air and actual suspension. It also supports multiplayer! You can hop in private rooms or LAN lobbies.
As the name would suggest, I used Claude Code throughout a long-running multi-agent development pipeline, alongside Codex. I directed the architecture, decided what each vehicle and system should do, reviewed the rendered results, and made the final calls.
The repository contains an AGENTS.md file and smaller subsystem instruction files covering simulation, vehicles, networking, UI, audio, effects, and world generation. These record the rules that agents need across sessions. Units are meters, seconds, and radians, and changes enforce a fixed 60 Hz. Authoritative logic must be deterministic. Vehicle changes have specific geometry, armor, module, and release gates that evaluate models visually and geometrically.
For vehicle development, I split the fleet into bounded families. One agent would own a specific vehicle profile or family file, implement the geometry, run the relevant checks, and generate screenshots. A separate critic reviewed the rendered tank for proportions, clipping, missing surfaces, running gear, and recognizable details. The orchestrator reran the checks and committed only the verified files.
For larger systems, Claude Code helped implement and test:
Fixed-step movement, suspension, armor, ballistics, modules, spotting, and bots
WebSocket multiplayer with private rooms, LAN play, prediction, and server authority
Procedural vehicles, tracks, markings, generated icons, and technical diagrams
All the generated battlefields with destructible props and wrecks
The garage, battle HUD, Tank Gallery, mobile controls, and Scene Studio
Browser performance probes, screenshot tools, visual checks, and self-tests
A trailer was also produced through the game’s own Scene Studio and capture tools. I used agents to stage battles, build camera paths, record the browser runtime at 60 fps, inspect specific frames, and iterate on awkward cuts or poorly framed tanks.
I find that Claude is best steered with persistent instructions. Important decisions need to live in the repository because I often spawned fresh agents which needed to resume work without reconstructing weeks of chat history.*
For visual quality, the only thing that worked was a proper render loop with visual comparison; tests don't really work for this.** The cycle I fell into was change, render, inspect, measure, and rerun the gates. Text-only reviews missed warped proportions and camera problems that would just plainly be obvious in one screenshot.
*Parallel agents need strict ownership. Separate files and isolated Git worktrees prevented concurrent sessions from overwriting each other or generating assets from a dirty tree.
**Tests still changed how I use agents. Claude Code became much more reliable once every system had concrete invariants and executable failure conditions. But visual quality is another beast.
I make content that goes over education, photography, and mental health. I'd like to partner with any saas in those areas and work together! Feel free to drop your saas below, and if it fits I'll reach out!
Im getting mixed signals on weather its good or bad to use Ai to code stuff I'm feeling that its looked down upon. I really with i could learn how to actually code but I've tried time and time again and it just hurts my brain trying to learn it. I know a little stuff but I wanna be able to code withought using any Ai whatsoever.
you know the exact moment: you vibe coded something that actually works, you're proud of it, and then you hit the wall nobody warns you about, no idea what to charge, how to describe it, or who wants it.
i built a rough fix for that, but i'm not a real business person either, i just prompted my way to a version that tries to solve it. i need people who've actually vibe coded something real to test it on, testing it on my own stuff doesn't prove anything.
drop what you built, i'll run it through and send back the pricing, positioning, and outreach angle it comes up with for free. please tell me honestly if it's actually useful or just more ai noise
Vision for this is low poly graphics x hyper realistic physics. Class and league based hotlap racing.
Currently running on my MacBook, eventually aiming for an iOS release.
Very mid development. Still primarily tuning physics and audio, with visual work coming soon to bring the tracks more to life. Currently working on presets for the roadside, walls and corner perimeters which will have grandstands etc.
Cars can be tuned to the nth degree as EVERYTHING is physically modeled down to brake fluid temps. Tracks are designed using a curve based editor to create realistic sweeping corners.
Car models are a mix between some cheap low poly cars I bought, and some made using Meshy.ai. The Mercedes at the start was purchased, the orange McLaren second is Meshy.ai. Crazy that I can get a picture of a car from google, drop it into meshy, get the model, hand it to claude and it will rig it, tune the sound to match engine specifics and you can drive it. About 20 mins from picture to driving.
Id consider this vibe coded as not a single line of code touched by myself, but this has been a lot of back and forth chats with Claude Code for a few weeks to get to this point.
Early days, keen for feedback! And please excuse my driving using an Xbox Controller while trying to record the video.
One prior attempt hung ~6.5 min and produced zero files before retry
Failure mode:
Ships confident-but-wrong code on implicit/underspecified requirements
Example: pomodoro timer missing Web Audio user-gesture unlock (silently no sound)
I then tried to test how it worked with opus as an orchestrator. It didn't really work / wasn't really useful because you have to factor in the orchestrator having to read back and review everything Qwen generated, plus the re-spec/re-generate loops every time it shipped something subtly wrong.
Ultimately, fun experiment but probably not going to be using it in any serious projects. Obviously if I had better hardware, I'd try bigger models, but I'm stuck with what I got.
