Are Humans Still Needed?

Over Christmas I wanted to see how far I could get with a difficult AI refactoring project. Not a clean greenfield app or not one of those examples where the whole problem fits into a single prompt; I decided to resurrect an old iOS game.

Flick a fruit

Flick a Fruit was released in 2013. Akash G and I had worked on it for about two years, released it with high hopes, and then watched as nobody downloaded it. We even tried burning money on facebook ads lol.

Next we watched it slowly fall apart as iOS moved on. The game was built with Objective-C, C, manual memory management, Cocos2d 1.4, OpenGL ES 1.x, old texture formats, and a Xcode project that had collected a pretty impressive amount of dust.

The codebase was not tiny either. It was roughly 150k lines of code:

I had had a long desire to revive this game. After all, I had spent two years on it. At the same time I never wanted to touch this codebase again.

So over christmas I turned to AI.

This is exactly the kind of project where the current AI coding story becomes interesting. It also has the fun property that a lot of the correctness is visual. The game can compile and still be completely broken.

Also, developing for iOS is way more challenging than just asking AI create a stupid js/HTML/webgl game in one go.

All in all, AI did get the game working again. That part is pretty fantastic. However, it was not one prompt. It took about six days, roughly a thousand prompts, and a lot of testing, reverting and explaining.

I put my learnings into two buckets. Let me go through them.

1. Out of Distribution

The biggest technical problem was the move from OpenGL ES to Metal.

The game used Cocos2d 1.4, from around 2011. That version used OpenGL ES. Later versions of Cocos2d were not a simple upgrade path, and the complete rendering engine of the game was build on top of it.

So I first asked Claude to create a plan to port the codebase to modern iOS. The plan but it was wrong in the most interesting way:

• There is no Cocos 2d Objc 4.0
• Cocos 2d has no swift package
• We were on Cocos 2d 1.4, not 2.0

Most important though, updating Cocos 2d to a new version with a very different API would just baloon the scope of this project. Also, I’m not trying to build a engineering-maxxed production app here, I just want to revive a corpse.

The better solution was much more hackish: copy the Cocos2d source into the repo and port only the renderer from OpenGL ES to Metal.

That worked because most of Cocos2d was not actually the problem. The scene system, animation system, audio system, scheduling, and input handling were still useful. The outdated part was the rendering guts.

In order to build that, I needed a small harness because the current project had 1000s of build errors.

So instead of asking AI to fix the whole project in one go, I created a tiny sample app called IHateXcode and used that to make the renderer problem small enough for Claude to solve.

There’re two decisions here which, to me, feel like out of distribution for the typical agent (except if prompted):

• Just fork the renderer and fix it
• Do that in a new project so we don’t also have to fix 1000s of other compiler errors first

2. Human Understanding and Taste

The second area was human understanding. Games are also feel, timing, rendering quality, animation, and a lot of little details that are hard to describe in a prompt.

This category was sometimes hilarious.

Flick a fruit resolves around the concept of a River where fruits flow down. The rendering was kinda broken.

So I told claude to fix it (showing this screenshot)

This was Claude’s “Fixed river rendering”.

The issue, of course, was that for a game which is different from typical UI, its sometimes difficult for AI to understand what the “right” look really entails.

From the same category came this problem where there was a bug in the renderer which caused everything to look super blocky when running on an iPhone.

Claude thought it was a retina issue:

It thought upscaling the sprites to 3x would fix the issue, however the iPad has a much bigger screen than an iPhone, so if it looks sharp on iPad, it shouldn’t look this blocky on iPhone.

… The retina iPad solution is good enough for running on iPhone. It looks great on a 13” iPad. Only on iPhone is it terribly blocky. I suspect the way we scale down the image is bad on iPhone.

Animations

I have a whole list of animation issues which are hard for AI to grasp because it can only look at individual frames of a video. Now this is somewhat of a temporary exception because LLMs are starting to gain this understanding, but for now not on a level where they would spot the kind of issues I have here.

I asked Claude to fix the animation of the “Hyke” character

Here’s Claude’s analysis of the animation above

Game Mechanics

What makes a game fun? What is a good idea in this context? If you control a game character, what “feels” right to a human?

None of that is something a agent is any good at.

I asked Claude to come up with fun ideas for the game:

In general, AI is oftentimes known to not be the best guide for good ideas (found this on reddit the other day):

This is not meant as a cheap “AI has no soul” argument. The tools are genuinely useful here. They can inspect code, suggest rendering changes, rewrite animation logic, and explain coordinate systems. But somebody still has to play the game and say: this does not feel right.

Isn’t That Just a Games Problem?

You may ask whether this is only true because games are weird.

I do not think so. There’s way more software with similar requirements:

• Presentation Software: Transitions, flow
• Design Software (Figma) “interaction quality”
• Motion Software
• Anything involving Hardware
• You don’t train a recommender system on AI
• Any human computer interaction rises with human input

Any software where the user experience matters will continue to need humans. Not necessarily humans typing every line of code, but humans judging whether the thing is good.

Are developers still needed?

I think we will become product engineers.

A good product person does not just produce a plan. A good product person decides which problems matter. That still requires contact with reality. That also requires taste. Taste means solving problems in a way that other humans find pleasant to use. This kinda entails being a human.

You will still read code. You will still debug code. You will still need to understand architecture, APIs, memory, rendering, state, and all the other annoying details. Otherwise you will not know when the agent is wrong.

But the job becomes less about typing every implementation yourself and more about building the system around the implementation. You describe the task, narrow the scope, test the result, judge the quality, and decide what comes next.

The useful future engineer understands the code, understands the product, understands the user, and can manage a small army of weird little agents without letting them destroy the codebase.

All in all, this project made me more optimistic, not less. AI got an old, broken iOS game running again, which is fantastic. But the human work did not disappear. It moved up a level.

That’s it.