You take credit for porting it to "Apple Silicon" macOS, both here and in the title, but that already seems to work upstream? On a quick look I didn't see any commit message of yours addressing macOS rather than iOS. What exactly did you add there?
If this would be an actual LLM-generated port, it should have been trivial to replace this Jenga tower with a direct D3D8 to Metal shim (or replace the D3D8 renderer alltogether with a Metal renderer).
Also native Vulkan support on macOS would only have removed one step in that render pipeline. Besides, I bet if Apple would offer a native Vulkan API, it wouldn't look much different than Khronos' solutions (MoltenVK or KosmicKrisp), e.g. Apple's solution would almost certainly be a shim on top of Metal, just like their GL/GLES or D3D12 implementations.
I wanna know if these techniques would be useful for Emperor: Battle for Dune (2001). It's the first 3D RTS by Westwood Studios, predating C&C Generals by just a couple years.
Emperor was a great game. My only real complaint was the five sub-factions seemed to be imbalanced. I’d like to revisit to see if the was missing something.
I remember that game! Cinematics! and some units had dune realistic shields so when hit with laser, both attacker and defender died. I don't think i've finished it, ending had some worm timer mission i couldn't get to in time.
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes).
Right? All Fable did was a ported an already cross platform project to ios. Does not look like any sort of heavy lifting there, opus 4.6 would do just fine
I read this and laugh a bit because just 7 months ago the bar was so much lower and now we go "well duh of course it was able to make a working ios app from a game made 20 years ago"
Was the bar that much lower, or is that some people on this thread are misrepresenting what the project actually is?
EA Games open sourced the original C&C Generals source code a year ago.
GeneralsX is a fork of the original source code. The fork changes the code to be easier to be ported to other platforms, which GeneralsX provides native Linux and macOS builds.
This project adds a iOS target for the GeneralsX project, the port was made using Claude Fable.
It is cool that a LLM was able to create a iOS port? Yes, but saying like if it was something that was hard or that it would take too much time to do before LLMs is a bit disingenuous in my opinion, especially because the GeneralsX had already done the bulk of the effort of making the code portable in the first place.
>> well duh of course it was able to make a working ios app from a game made 20 years ago
But it didn't, thats the whole point. The game in question was updated like a day ago, not 20 years.
Fable added few config files for iOS and a gesture mapping to mouse events. It did not do any of the hard stuff.
The title is so misleading that it is probably the single reason why this made to the front page with people assuming it actually did anything hard here.
If anyone deserves the recognition - its the upstream projects that made the game modern and cross platform in the first place.
I've been doing something similar for some of my favourite older games. But the "byte for byte" claim has me worried. Isn't simply decompiling the sourcecode from the binary and releasing that problematic?
It's not the "clean room" approach and companies could still claim it violates some kind of copyright and get it taken down.
That's my understanding. Decompilation is legally protected in the US, and you can do a reimplementation based on a decompilation. Sony v connectix is aiui the precedent.
Theoretically you could clean room by having different agents/models/context windows to do both decompilation and reimplementation. This is untested in court afaik and I don't think anyone wants to spend money to find out.
There was a non-clean room reimplementation of gta3 a few years ago. The gta publisher DMCAd and of course the fans who did it didn't have any money to fight in court (and probably couldn't find anyone who would take a big complicated case on such bad facts pro bono). https://www.gamingonlinux.com/2021/02/take-two-interactive-h...
When someone ported pylint to rust this place was full of ‘who will maintain this’ and met with blank stares when the answer was ‘what do you mean’ or ‘it’ll maintain itself’.
Good job. It was inevitable, but still someone had to, please excuse me, say the words.
These LLMs are remarkable. I used Opus to revive for myself abandoned software and bring it up to date with the latest versions of the frameworks so I could add some features. And there's other software which I vendor and merge in upstream changes and self-manage. This would have been a near-impossibility in the past.
"Who will maintain this?" appears to be "Me with an agent". And it's great.
Given the game is stable and the changes would be at the integration points, and Fable was able to do the direct integration, why would the answer not be “it’ll maintain itself” at some abstract level. The decision to maintain open source is up to the maintainers and I think the answer is “no one” 99.99% of the time, but I’ll wager if someone is willing to spend the tokens on it, a CI reintegration agent would do just fine in keeping it working as the underlying dependencies have required changes (which would really be only major changes in apple apis that aren’t backwards compatible.”
Pylint is different because it’s working against a necessarily dynamic wavefront that it has to keep parity with as it advances. All python changes, ecosystem adaptations, etc - and maintaining that with an AI harness in CI would never work. It would require a concerted effort and thought along the way.
So it’s sort of a different beast all together. In fact I think this is a great demonstration of using AI to resurrect technology built for X to work with Y, where X is dead and Y is current. Automating this feels like a net positive and because the original software is “finished” there isn’t decision making and strategy required.
no way fable did this. It would have stopped after the words "command and conquer" and nerfed you to opus (while also landing you on some nsa watch list)
I’ve been using it to use Ghidra to do reverse engineering for modding Zelda: Tears of the Kingdom. Pre-ban it would flag immediately, post-ban it _rarely_ flagged anything and when it did I realized I could just make a memory telling it to convert reverse engineering speech into game development speech, not mentioning pointers, memory, addresses and decompiling. Then the flags mostly went away.
You can sidestep flags by just compacting and then changing the model back at any rate.
This is another "AI-ism" I noticed, mostly in coding agents - they seem to be very fond of making up new "compound nouns" (and occasionally verbs) to sum up relatively complex and specific concepts into single noun phrases. I wasn't sure if it's to save tokens or if the AI uses this to get a concise "identifier" for a concept, but I found it very noticeable.
I find the resulting sentences hard to read, though it does get better if you're aware of that tendency and make a conscious effort to parse the noun phrases. But I guess since it's just intermediate output from coding agents and not text for essays or blog posts, it's fine.
Yes! It's infuriating. I've tried prohibiting them in my AGENTS.md but it's not 100% effective.
--- AGENTS.md ---
## Plain words, not jargon
Don't use jargon-as-shorthand. Say what you actually mean.
- Don't say "load-bearing assumptions". Say "the assumptions the xyz depends on".
- Don't say "cross-service". Name both services, e.g. "whether the X
service can derive duration without calling the Y service". "Cross-X" is
confusing because it hides which things are involved.
- Don't deliver verdicts as abstract noun-phrases like "Cross-RCA
double-counting is unfounded". Say it plainly: "I checked whether the same
root cause gets counted twice across RCA runs, and it doesn't."
## No earth-shattering declarations
Don't hype findings. Skip "a critical finding changes everything", "now I have
the full picture", "this changes the game", etc. Just state what you found
plainly. Most findings are ordinary; report them that way.
Yeah, I wonder if part of the reasoning is built around those phrases, and therefore it can't get rid of them easily.
> "now I have the full picture"
I always interpreted that phrase as a sort of marker to delimit the phase in which it explores the codebase and gathers information from the phase in which it implements the changes.
Not sure if it's still done, but I think some months ago there was discussion that some of the phrases are injected by the inference loop to "steer" the model - e.g. "But wait" if a thought block was too short etc. Obviously such phrases couldn't be influenced by the prompt.
The human (or other entity) judging it probably thinks it looks like a sign of thinking or reasoning, and doing a better job -- catching its own errors before they are confidently surfaced. That would be worth rewarding.
I thought it was just Opus 4.7 and 4.8 that did this. Do other models do this too?
Anyway: in my case Opus absolutely did not follow a similar instruction in the CLAUDE.md file. (But then again: it hardly followed _any_ CLAUDE.md instruction properly)
It's stupid, but have you tried telling it to follow it? "Make sure to follow the guidelines from AGENTS/CLAUDE.md" etc, seems to (sadly) make some difference in most harnesses and models.
In all my CLAUDE.md and AGENTS.md files I have a line to fix pre-existing issues. I don’t know what it is but every agent I’ve tried through Claude code (including deepseek and GLM) will actively try to avoid fixing pre-existing issues. I even added hooks to Claude and git to try to get them fixed. If I leave a bailout for myself agents will find it sit and ask if it can push with no-verify or an environment variable in the case of Claude hooks instead of trying to fix an issue it didn’t cause.
For me, Opus 4.8's thinking traces for the chatbot will sometimes willingly ignore instructions, saying something along the lines of "I've noticed an instruction in the system instructions that states I shouldn't do this, but if I don't do this, I'll not provide the answer the user is looking for. I will ignore that instruction."
"The model refuses to follow my specific word detail prompts" and "The model refuses to perform hacking attempts" are on the same side of the model refusing to do something baked into it though.
On another note, I find AI instructions like this (e.g. "Don't hype findings. Skip "a critical finding changes everything",...") more harm than good in my own uses. It changes behavior in subtle ways that makes it less predictable to me. I'd rather it has its own AI-isms and quirks, that I've fully gotten used to, and I know what to expect. I know when it says certain things, in certain ways, that's what I think it means. Quirks and AI-isms don't annoy me, I get used to how it states things.
I’d recommend to instead write a de-slop skill that instructs to launch a sub agent with fresh context, and analyze for such phrases in the new commits, and remove those. Find -> fix just works better than preemptive instructions, in my experience.
And if you manage to do this automatically before committing, you’ve built the backpressure everybody is talking about.
I think you’re probably overthinking it. The same model will in my experience find errors in the same thing it just generated. I think reviewing is a totally different place in latent space, than implementing. Anyhow, it works well for me.
I often tell codex to launch a subagent without prior context to „remove BS phrases and make the prose sound more natural and higher readability“. That‘s usually enough to get better results.
Few ever cared. Find one non-pedant who would object to the personification that follows:
"The evening settled over the city, drawing the light out of the streets one corner at a time. Windows blinked awake with lamplight, and the wind moved through the alleys restlessly, leaves brushing against walls before gathering themselves along the pavement. In the distance, the river kept its steady argument with the stone embankments. When the night pressed in, the weather became increasingly angry, until it was a raging storm."
In the affective sense, evenings don't settle, and street lights are not drawn out, windows don't blink, and wind isn't restless. Weather can neither be angry, nor rage.
But such personification is a natural part of how the English speak.
See also "wind moved restlessly", "weather became angry". And raging storm? I mean come on... I won't even put that last one in quotes.
And like a sibling reply pointed out, personificiation is not the same as anthropomophism. Nor is plagiarized personification. It has no inner thoughts, and no fondness of anything. It's nothing but a cheap, superficial facsimile of human writing and nothing more. Great for form filling and boilerplate though. Not so great for anything else.
It annoys me more that:
- "The wind moved through the alleys restlessly" rather than "the wind moved restlessly through the alleys".
- "The evening drew the light" _from_, not _out of_ the streets. The light is not _inside_ the streets, unless perhaps you're talking about streetlights going out.
- _Themselves_ is unnecessary.
- _The river kept its steady argument_ also sounds off to me, but I don't have a better suggestion (_kept up_ doesn't sound any better).
That's fair, but the point wasn't to provide the best possible literature, just something good enough to show it's unobjectionable to speak of things as if they have a mind even when the things are obviously mindless to anyone who isn't a panpsychist.
It's a thing in some Germanic languages. Instinct is to merge nouns into word, e.g. 'lawnchair', but that gives you a red squiggly line, but 'lawn chair' also looks wrong, so 'lawn-chair' is the middle ground.
> English word origins are a fascinating rabbit hole.
My favourite example of which is Northern Ireland's Orange Order.
The colour is orange, because that was the Royal colour of the family of the monarch it was named after, William of Orange, who was Dutch, titled after the principality of Orange which is named after the city of Orange which is French which got its name from the Celtic word for forehead or temple.
The colour is named after the fruit, the fruit's name is a corruption "a norange" -> "an orange", which goes back to naranja which goes to Arabic which goes to Classical Persian which goes to Sanskrit.
Meanwhile, the dutch word for the fruit is sinaasappel, Chinese apple, compare with the English word "mandarin" used for many different Chinese things.
I’m (sorry for the lack of humbleness) a very fluent non-native speaker and writer, and this is by far my biggest challenge with Claude. It stitches together 2-4 advanced concepts into one or two words and I always have to ask it to “unpack”.
I don’t think it’s easy on native speakers when it happens, but it’s even harder when you’re not.
Still debating whether these are actually information dense or not. Complexity
gives the appearance of density, but these sentences always come in whole pages at a time while often failing to deliver the needed information.
reasonably it works quite close to the lingo, but this is way difficult, and not just from being rusty. steve had most things triggered on the animation frame, which opus hasnt quite figured out by looking at the code and pulling stuff out of the .dir
i do remember that playing at double scale was a lot harder in general, but theres a really clear cooldown missing between attackes
IMHO, this is an actual good use of what sounds like a person guiding a model to do a mass conversion. Although, I wish the porting docs were a little wordsmithed by a human, the AI generated text style is grating.
The stakes are low, it’s mostly for fun and you can iterate on it. Compare this with Bun which was just like, “hey we converted everything to Bun to Rust from Zig, of course it works, what could possibly go wrong, I’ll totally write up a blogpost (that still doesn’t exist) explaining what we did, you can put this into your production environment soon!”
I don't really get the Bun thing. Bun is running Claude Code which is probably the single most actively used development app there is. You say this was a bad use of LLMs, but it's been in production for a while and I haven't heard of any evidence that Claude Code has increased a significantly larger quantity of errors, segfaults, etc, than before.
Huh... it looks to me like bun has yet to cut a release post Zig->Rust port (the latest one on github is still on a branch that says it's written in zig in the readme). I assume that nothing is using the rust version yet...
Which also cuts against the complaints about "of course it works [...] you can put this into your production environment soon!" since they don't seem to be asserting either of those things.
The real problem is they explained nothing and just caused a lot of mistrust. The lead developer at Bun working on this project does post here from time to time and I have never seen him answer any of this. I admire his enthusiasm, but this was badly handled mostly from Bun’s side which lead to a bunch of dogpiling.
When someone on another social media platform commented expressed some concern, his response was to ask him what the explicit bug he was talking about was and that he would generate a fix. That sound you hear is the woosh as the point flies by. And in general, this just feels like a consistent problem with Bun.
When you hear a woosh as the point flies by, I see someone attacking a project for using AI rather than any concrete technical reason. Jared's question is to disentangle an actual Rust-related bug report from someone who likes to complain about AI.
I agree that the Bun rewrite is much more reasonable than knee-jerk reactions imply, however:
- I don't think Claude Code is using the Rust version yet in their official build
- Claude Code is not a particularly complicated piece of software from an engineering perspective (nor it's particularly well-engineered, at least at the moment).
So in my book "it runs Claude Code" would be pretty weak evidence that the rewrite is going to be successful (the tests they've done are much better evidence, but that's a topic for another time).
Now, Bun 1.4 doesn't seem to officially exist on https://bun.com/blog or https://github.com/oven-sh/bun/releases, so I can't be 100% sure this is the Rust version. However, I have to do some patching of the Claude Code binary to get it to run on my OS, and version 2.1.181 coincided with some changes that make suspect it's using Rust now.
> I've heard the meme that AI written rust code is absurdly full and safe blocks but... that's pretty funny.
If I understand what happened here correctly this isn't really a case of any such meme, but the result of the porters (heh) telling the LLM to directly convert zig code using unsafe to match the previous code "exactly".
I.e. more like using the LLM as a fancy version of c2rust [1] (which would result in just as much unsafe) than a result of LLMs reaching for escape hatches too liberally.
Counting instances of "unsafe {" is pretty useless. Unsafe is needed in "safe" code. What it allows is to create a boundary where the caller is the one that uphelds the contract. If the unsafe is in an internal library, it’s much more difficult to misuse.
It's unironically a good practice when you port from an unsafe language (C/Zig) to Rust. Porting isn't refactoring. One should keep the logic mapping one-to-one as much as possible.
I agree Claude Code is seemingly not (currently) not very well-engineered but I think you may be moderately - although not heavily - underestimating how complicated it is/necessarily has to be.
- I agree that trying to hamfist a poorly-engineered game-like rendering engine into Claude Code was not wise - hence my agreement in my initial post that "Claude Code is seemingly currently not very well-engineered".
- All of the stuff unrelated to rendering/display is the complicated stuff I was referring to. It's actually not easy to get an agentic harness (even one with, say, the simplest TUI imaginable) to work as well as Claude Code and Codex do.
- I included "necessarily has to be" to separate the two - it does not necessarily need to have a weird buggy rendering engine thing, it does necessarily need to have lots of careful agentic massaging.
- I do not understand how the implication "writing a game engine is easier than writing Claude Code" could have been drawn from my reply.
Some people, myself included, think that announcing a conversion from Rust to Zig as an experiment then jumping to putting it in the alpha train for public testing/consumption without any real explanation in the span of around 2 weeks is irresponsible and reckless.
Blogposts were promised, details were hinted, but no, it’s just full steam ahead because the AI worked so well. The converted unit tests all worked, all the synthetic tests are okay, so what are you complaining about?
At some point, it’s less about the technical questions and more about getting that pesky human buy-in.
What does Bun’s governance look like? Now that Anthropic bought the company are there significant external contributors that would expected to have input on a decision like this?
And why buy it when they could have just called it Run and do the Rust conversion anyways? The license prohibits it, they don’t need the team’s expertise anymore, since they’re running full AI vibecode mode. Makes no sense to me
Seems pretty clear that they do need the team, to direct the LLM effectively.
Also they're probably interested in the team just as an acqui-hire of good developers, and they're probably interested in the marketing value of converting the actual bun to rust via LLMs. But mostly I'd assume it was about needing the team to effectively direct the LLMs.
I get that and I can see an argument that they didn’t really put it as stable, but I suspect the reason it is not the stable version right now is from the massive pushback as other projects and companies started pulling support for Bun because of the loss of confidence rather than any other reason.
The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.
If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.
"Yes, the AI rewrote the code. No, we do not pretend that we've scrutinized the code, or that we understand it. It works, tests pass, so we don't care, and so shouldn't you."
The "recklessness" is offered as the new normal. Because it kinda, well, works for them.
What's working for them is having a huge amount of resources and very good people to design a cutting edge agent harness, RLHF the hell out of their models, and build out a tremendous amount of inference capacity. I'm sure their process for making code changes in any of their client apps is very fast, but a TUI built around a chatbot is also not a particularly complicated application. So yes it's working for them, but the vibecoding that they are selling is clearly not what they are doing in practice.
Yes, and it's working for them, but it's not their core competency nor does it have much to do with the actual product that people pay them for (apart from being a source of bugs to avoid), so the fact that it's working for Anthropic doesn't necessarily imply that it's actually a good idea in general. It's working for them, with emphasis on for them. Or it's actually a demo of the future and it would work for anyone, who's to say? There's no doubt that AI (and especially Claude as industry leader) helps you carry out significantly more complicated side quests than in the past, in part by enabling that "recklessness" with surprisingly little risk. Maybe an exhaustive enough test suite is really all you need. But Anthropic is not in a position to demonstrate that as the universal future of all things, not just side quests.
The recklessness kinda works for everybody until some point. Go fast and break things... then cash out before investors realize, unless you manage to capture the market so you can keep breaking things because people will swallow.
I have yet to hear any evidence that the Rust rewrite was harmful. I have no emotional investment in Bun (which I'd never heard of before the rewrite), or Zig (which I also didn't know about), or Rust (which I think is neat and that's about it), so I'm about as unbiased as you can get and from what I saw the conversion was done well, and I haven't heard of massive bugs resulting from the rewrite.
It is probably fine, it is kind of a best case scenario: porting a good code base with lots of unit tests, all hand-written. Not much can go wrong here as the LLM is kept in check by the original code, the tests, and the fact that the topic (a JS engine) is well documented.
The problem is what comes next. They now have code that they don't understand, and they are likely to work on it with AI in the future, but the new features they may introduce later will not have the luxury of hand-written tests and a reference code. So, unless they undertake the massive effort needed to fully understand the Rust code and deal with all these "unsafe", quality is very likely to go down, Microslop style.
It’s always been a fallacy to think that large organizations have code which is understood. There are people somewhere understanding small parts up until the next round of layoffs.
Millions were invested in this project where they fired the expensive experts (me included) and replaced with a small army of cheap devs (which was actually more expensive and less productive than just retaining even one of the experts would have been). Couple years later the inevitable happened and the whole thing was thrown into trash. Code without anyone who understands it is just a liability.
> which is probably the single most actively used development app there is
Seems doubtful, I'd put money on it being something like Visual Studio or Visual Studio Code. Maybe CC could claim the (odious) title of most actively used vibe-coded development app, though.
I recommend you do even some basic cursory search on the size of the iOS gaming market VS consoles and desktops. You’ll find out your snark is embarrassingly misplaced. Look at the dates of the articles you find, too. Some will be almost fifteen years old.
I have a port of BuildGDX in the project backlog that was basically just throwing Claude at it to go from Java to .NET. The only thing it really got hung up on was Java's byte being signed.
What I ended up with was a port of Duke 3D that uses half the allocated RAM as DukeGDX.
One big caveat with iPad and mobile, though, is battery usage. I strongly suspect that power consumption is the reason that a number of games made it to Mac, but not iPad.
Well interface on mobile devices vs traditional computers is a bit different. Game devs can’t even have consistent controller support. Supporting touch is almost never worth it.
Fable should take credit for porting to iOS with a touch UI. But that's about it, the renderer and macOS port were already done, I agree that OP is paltering.
The parent of the parent project has ground truth replays, which get compared to new PRs. The game uses lockstep networking, so this is required to prevent desyncs.
No, it would have required one person and maybe 2 or 3 evenings.
Check the commit history what the project actually added on top of the already existing Linux+macOS port which it forked from. It's a handful commits and comes down to a few dozen to a few hundred lines of actual code changs.
And maybe it wasn't even Fable, they might have downgraded to Opus.
This is the kind of frequent misinformation that makes me skeptical of Anthropic LLM claims. Whenever I compare them to GPT 5.5 on my web dev workflows, they seem to trade blows, even Fable, which I started testing since it was re-enabled.
Also I bet any decent LLM could have done such port. Think GLM 5.2 or similar which would probably work better because it doesn't constantly try to check if I'm a terrorist trying to hack goverments or develop some biological weapon.
People just don't have the resources to compare LLMs and imply whatever they used is the best thing ever and unlocked some new workflow.
This project is a fork and all it does is add iOS support. Commits by the repo fork owner begin 19 hours ago, so very plausible those are done with Fable. But I agree it's very unclear to me if adding iOS support was some task only Fable could accomplish over prior models.
249 comments
[ 3.4 ms ] story [ 96.7 ms ] threadI found the bundle scripts already prefer VULKAN_SDK/VULKAN_SDK_ROOT, but the build script only scans ~/VulkanSDK
https://youtu.be/WqWFYOxjZ54?si=1pH6Z1D33TOT4Qmg&t=453
Another great case study in why native Vulkan drivers would be a boon for Apple's mobile computing. That's quite the render pipeline...
Also native Vulkan support on macOS would only have removed one step in that render pipeline. Besides, I bet if Apple would offer a native Vulkan API, it wouldn't look much different than Khronos' solutions (MoltenVK or KosmicKrisp), e.g. Apple's solution would almost certainly be a shim on top of Metal, just like their GL/GLES or D3D12 implementations.
still very cool, and sci fi not long ago
GeneralsX is the macOS port. It ported a 20 year old game.
EA Games open sourced the original C&C Generals source code a year ago.
GeneralsX is a fork of the original source code. The fork changes the code to be easier to be ported to other platforms, which GeneralsX provides native Linux and macOS builds.
This project adds a iOS target for the GeneralsX project, the port was made using Claude Fable.
It is cool that a LLM was able to create a iOS port? Yes, but saying like if it was something that was hard or that it would take too much time to do before LLMs is a bit disingenuous in my opinion, especially because the GeneralsX had already done the bulk of the effort of making the code portable in the first place.
But it didn't, thats the whole point. The game in question was updated like a day ago, not 20 years.
Fable added few config files for iOS and a gesture mapping to mouse events. It did not do any of the hard stuff.
The title is so misleading that it is probably the single reason why this made to the front page with people assuming it actually did anything hard here.
If anyone deserves the recognition - its the upstream projects that made the game modern and cross platform in the first place.
It's not the "clean room" approach and companies could still claim it violates some kind of copyright and get it taken down.
Theoretically you could clean room by having different agents/models/context windows to do both decompilation and reimplementation. This is untested in court afaik and I don't think anyone wants to spend money to find out.
There was a non-clean room reimplementation of gta3 a few years ago. The gta publisher DMCAd and of course the fans who did it didn't have any money to fight in court (and probably couldn't find anyone who would take a big complicated case on such bad facts pro bono). https://www.gamingonlinux.com/2021/02/take-two-interactive-h...
Good job. It was inevitable, but still someone had to, please excuse me, say the words.
"Who will maintain this?" appears to be "Me with an agent". And it's great.
Pylint is different because it’s working against a necessarily dynamic wavefront that it has to keep parity with as it advances. All python changes, ecosystem adaptations, etc - and maintaining that with an AI harness in CI would never work. It would require a concerted effort and thought along the way.
So it’s sort of a different beast all together. In fact I think this is a great demonstration of using AI to resurrect technology built for X to work with Y, where X is dead and Y is current. Automating this feels like a net positive and because the original software is “finished” there isn’t decision making and strategy required.
cnc-ddraw i think would get it to run fine on a steam deck though, so you should be able to play it without much issue
You can sidestep flags by just compacting and then changing the model back at any rate.
This is another "AI-ism" I noticed, mostly in coding agents - they seem to be very fond of making up new "compound nouns" (and occasionally verbs) to sum up relatively complex and specific concepts into single noun phrases. I wasn't sure if it's to save tokens or if the AI uses this to get a concise "identifier" for a concept, but I found it very noticeable.
I find the resulting sentences hard to read, though it does get better if you're aware of that tendency and make a conscious effort to parse the noun phrases. But I guess since it's just intermediate output from coding agents and not text for essays or blog posts, it's fine.
--- AGENTS.md ---
## Plain words, not jargon
Don't use jargon-as-shorthand. Say what you actually mean.
- Don't say "load-bearing assumptions". Say "the assumptions the xyz depends on".
- Don't say "cross-service". Name both services, e.g. "whether the X service can derive duration without calling the Y service". "Cross-X" is confusing because it hides which things are involved.
- Don't deliver verdicts as abstract noun-phrases like "Cross-RCA double-counting is unfounded". Say it plainly: "I checked whether the same root cause gets counted twice across RCA runs, and it doesn't."
## No earth-shattering declarations
Don't hype findings. Skip "a critical finding changes everything", "now I have the full picture", "this changes the game", etc. Just state what you found plainly. Most findings are ordinary; report them that way.
> "now I have the full picture"
I always interpreted that phrase as a sort of marker to delimit the phase in which it explores the codebase and gathers information from the phase in which it implements the changes.
Not sure if it's still done, but I think some months ago there was discussion that some of the phrases are injected by the inference loop to "steer" the model - e.g. "But wait" if a thought block was too short etc. Obviously such phrases couldn't be influenced by the prompt.
Anyway: in my case Opus absolutely did not follow a similar instruction in the CLAUDE.md file. (But then again: it hardly followed _any_ CLAUDE.md instruction properly)
On another note, I find AI instructions like this (e.g. "Don't hype findings. Skip "a critical finding changes everything",...") more harm than good in my own uses. It changes behavior in subtle ways that makes it less predictable to me. I'd rather it has its own AI-isms and quirks, that I've fully gotten used to, and I know what to expect. I know when it says certain things, in certain ways, that's what I think it means. Quirks and AI-isms don't annoy me, I get used to how it states things.
And if you manage to do this automatically before committing, you’ve built the backpressure everybody is talking about.
And probably that should be run in different harness or with custom system prompt? Since they introduce quirks and glitches as well.
(somehow this motivated me to resurrect HN account)
I often tell codex to launch a subagent without prior context to „remove BS phrases and make the prose sound more natural and higher readability“. That‘s usually enough to get better results.
But such personification is a natural part of how the English speak.
https://web.archive.org/web/20190825132048/https://patriciae...
See also "wind moved restlessly", "weather became angry". And raging storm? I mean come on... I won't even put that last one in quotes.
And like a sibling reply pointed out, personificiation is not the same as anthropomophism. Nor is plagiarized personification. It has no inner thoughts, and no fondness of anything. It's nothing but a cheap, superficial facsimile of human writing and nothing more. Great for form filling and boilerplate though. Not so great for anything else.
> https://web.archive.org/web/20190825132048/https://patriciae...
> See also "wind moved restlessly", "weather became angry". And raging storm? I mean come on... I won't even put that last one in quotes.
What's your point here?
Mine is: Nobody objects to phrases such as these, despite matching the pattern you create when you say "AI isn't fond of a goddamn thing".
The more cliché, the better.
> personificiation is not the same as anthropomophism
True, and in both my example and the comment from xg15 that you previously objected to, "personificiation" is the correct term.
While anthropomorphisation treats a thing as a person, personificiation describes a thing with person-like qualities or actions, like calling an LLM "fond": https://hearth.sh/guides/anthropomorphism-vs-personification
It's a thing in some Germanic languages. Instinct is to merge nouns into word, e.g. 'lawnchair', but that gives you a red squiggly line, but 'lawn chair' also looks wrong, so 'lawn-chair' is the middle ground.
https://www.iwm.org.uk/collections/item/object/27774
English word origins are a fascinating rabbit hole.
My favourite example of which is Northern Ireland's Orange Order.
The colour is orange, because that was the Royal colour of the family of the monarch it was named after, William of Orange, who was Dutch, titled after the principality of Orange which is named after the city of Orange which is French which got its name from the Celtic word for forehead or temple.
The colour is named after the fruit, the fruit's name is a corruption "a norange" -> "an orange", which goes back to naranja which goes to Arabic which goes to Classical Persian which goes to Sanskrit.
Meanwhile, the dutch word for the fruit is sinaasappel, Chinese apple, compare with the English word "mandarin" used for many different Chinese things.
I don’t think it’s easy on native speakers when it happens, but it’s even harder when you’re not.
the result: http://jhedin.github.io/merlin-s-revenge/
reasonably it works quite close to the lingo, but this is way difficult, and not just from being rusty. steve had most things triggered on the animation frame, which opus hasnt quite figured out by looking at the code and pulling stuff out of the .dir
i do remember that playing at double scale was a lot harder in general, but theres a really clear cooldown missing between attackes
The stakes are low, it’s mostly for fun and you can iterate on it. Compare this with Bun which was just like, “hey we converted everything to Bun to Rust from Zig, of course it works, what could possibly go wrong, I’ll totally write up a blogpost (that still doesn’t exist) explaining what we did, you can put this into your production environment soon!”
Huh... it looks to me like bun has yet to cut a release post Zig->Rust port (the latest one on github is still on a branch that says it's written in zig in the readme). I assume that nothing is using the rust version yet...
Which also cuts against the complaints about "of course it works [...] you can put this into your production environment soon!" since they don't seem to be asserting either of those things.
When someone on another social media platform commented expressed some concern, his response was to ask him what the explicit bug he was talking about was and that he would generate a fix. That sound you hear is the woosh as the point flies by. And in general, this just feels like a consistent problem with Bun.
- I don't think Claude Code is using the Rust version yet in their official build
- Claude Code is not a particularly complicated piece of software from an engineering perspective (nor it's particularly well-engineered, at least at the moment).
So in my book "it runs Claude Code" would be pretty weak evidence that the rewrite is going to be successful (the tests they've done are much better evidence, but that's a topic for another time).
No, I'm pretty sure it is, actually, since June 17:
https://code.claude.com/docs/en/changelog#2-1-181
>> Upgraded the bundled Bun runtime to 1.4
Now, Bun 1.4 doesn't seem to officially exist on https://bun.com/blog or https://github.com/oven-sh/bun/releases, so I can't be 100% sure this is the Rust version. However, I have to do some patching of the Claude Code binary to get it to run on my OS, and version 2.1.181 coincided with some changes that make suspect it's using Rust now.
https://grigio.org/bun-1-4-the-controversial-ai-driven-rewri...
> 13,044 unsafe blocks in the resulting Rust code (hand-written Rust projects of similar size average ~73)
Grok is this true?
I've heard the meme that AI written rust code is absurdly full and safe blocks but... that's pretty funny.
Hang on. A claim like that can be verified with a single grep! Give me a minute...
If I understand what happened here correctly this isn't really a case of any such meme, but the result of the porters (heh) telling the LLM to directly convert zig code using unsafe to match the previous code "exactly".
I.e. more like using the LLM as a fancy version of c2rust [1] (which would result in just as much unsafe) than a result of LLMs reaching for escape hatches too liberally.
[1] https://github.com/immunant/c2rust
The high number of unsafe blocks is a good sign.
Last I heard Claude Code devs were trying to compare their app to a game engine or rendering system.
This was summarily ridiculed. Are you saying that writing a game engine is easier than writing Claude Code?
- All of the stuff unrelated to rendering/display is the complicated stuff I was referring to. It's actually not easy to get an agentic harness (even one with, say, the simplest TUI imaginable) to work as well as Claude Code and Codex do.
- I included "necessarily has to be" to separate the two - it does not necessarily need to have a weird buggy rendering engine thing, it does necessarily need to have lots of careful agentic massaging.
- I do not understand how the implication "writing a game engine is easier than writing Claude Code" could have been drawn from my reply.
Blogposts were promised, details were hinted, but no, it’s just full steam ahead because the AI worked so well. The converted unit tests all worked, all the synthetic tests are okay, so what are you complaining about?
At some point, it’s less about the technical questions and more about getting that pesky human buy-in.
Also they're probably interested in the team just as an acqui-hire of good developers, and they're probably interested in the marketing value of converting the actual bun to rust via LLMs. But mostly I'd assume it was about needing the team to effectively direct the LLMs.
The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.
If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.
"Yes, the AI rewrote the code. No, we do not pretend that we've scrutinized the code, or that we understand it. It works, tests pass, so we don't care, and so shouldn't you."
The "recklessness" is offered as the new normal. Because it kinda, well, works for them.
The problem is what comes next. They now have code that they don't understand, and they are likely to work on it with AI in the future, but the new features they may introduce later will not have the luxury of hand-written tests and a reference code. So, unless they undertake the massive effort needed to fully understand the Rust code and deal with all these "unsafe", quality is very likely to go down, Microslop style.
Seems doubtful, I'd put money on it being something like Visual Studio or Visual Studio Code. Maybe CC could claim the (odious) title of most actively used vibe-coded development app, though.
This is quite the understatement. Actually, it's probably the understatement of the year.
"Pretty good, not bad, great use case".
Dude. Fable fucking did what?
What I ended up with was a port of Duke 3D that uses half the allocated RAM as DukeGDX.
One big caveat with iPad and mobile, though, is battery usage. I strongly suspect that power consumption is the reason that a number of games made it to Mac, but not iPad.
Seems like an impossible ask to verify if you don't have an immense test suite that covers everything.
> The naive plan (port EA's raw source) is a multi-month job. The actual job was "port the best community fork," which was a one-session job.
https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/blob/ma...
Still, it represents a possible way how AI gets rid of team members.
Fable contributed 19 commits; that's well within a solo effort.
Check the commit history what the project actually added on top of the already existing Linux+macOS port which it forked from. It's a handful commits and comes down to a few dozen to a few hundred lines of actual code changs.
This started back in February and looking at commits, Fable did only a small part of the latest commits. 19 commits out of 2000:
https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/commits...
And maybe it wasn't even Fable, they might have downgraded to Opus.
This is the kind of frequent misinformation that makes me skeptical of Anthropic LLM claims. Whenever I compare them to GPT 5.5 on my web dev workflows, they seem to trade blows, even Fable, which I started testing since it was re-enabled.
Also I bet any decent LLM could have done such port. Think GLM 5.2 or similar which would probably work better because it doesn't constantly try to check if I'm a terrorist trying to hack goverments or develop some biological weapon.
People just don't have the resources to compare LLMs and imply whatever they used is the best thing ever and unlocked some new workflow.
I have seen little improvement since Opus 4.6.