Live data from Hacker News

Claude wrote a functional NES emulator using my engine's API

carimbo.games

51–60 of 95 posts

Re: Claude wrote a functional NES emulator using my engine's API

#51
post #15

Earlier quoted context omitted.

Forbidding LLM to write comments and docstrings (preferrably enforced by build and commit hook) is one of the best "hacks" for using that thing. LLM cannot help itself but emit poisonous comments.

Or maybe clone the comments from where it cloned the source.

Meh. No human has written the horrors llm produces. At least I am yet to see codebase like that. Let me attempt a theatrical reenactment:

    // Use buffer that is large enough to hold any possible value. Avoid using JSON configuration, this optimizes codebase and prevents possible security exploits! 
    size_t len = 32;


    // this function does not call "sort" utility using shell anymore, but instead uses optimized library function "sort" for extreme perfomance improvement!!!
    void get_permutations() {
... and so on. It basically uses comments as a wall to scribble grandiose graffiti about it's valiant conquests in following explicit instruction after fifth repeat and not commiting egregious violence agains common sense.

Re: Claude wrote a functional NES emulator using my engine's API

#53

Earlier quoted context omitted.

When I consider the utility of a hammer, my first priority is to ask what the hammer can teach me.

Do you think that the use of a hammer is an innate skill, and that woodworkers learn nothing from their craft?

Okay, so let's say the use of a coding agent isn't an innate skill, so the author was gaining experience with the tool.

Re: Claude wrote a functional NES emulator using my engine's API

#54

Earlier quoted context omitted.

When I consider the utility of a hammer, my first priority is to ask what the hammer can teach me.

Do you like to read posts about what hammer can do? Especially when it has been done 100 times already.

I'm no carpenter, but I can honestly say I've probably read a hundred articles about vim..

Re: Claude wrote a functional NES emulator using my engine's API

#55
post #8

Nice, but NES emulator is one of the most written pet projects anywhere, which makes it considerably less impressive.

This is a good point. I wonder how much NES emulator code is in Claude's training set? Not to knock what the author has done here, but I wonder if this is more of a softball challenge than it looks.

Re: Claude wrote a functional NES emulator using my engine's API

#56

Earlier quoted context omitted.

That's not how software development works. Folks think, they write code, they do their own localized evaluation and testing, then they commit and then the rest of the (down|up)stream process begins. LLM's skip over the "actually verify that the code I just wrote does what I intended it to" step. Granted, most humans don't do this step as thoroughly and carefully as would be desirable (sometimes through laziness, some…

They absolutely can do that if you give them the tools. Seeing Claude (I use it with opencode agents) run curl and playwright to verify and then fix it's implementation was a real 'wow' moment for me.

We have different experiences. Often I’ll see Claude, et. al. find creative ways to fulfill the task without satisfying my intent, e.g., changing the implementation plan I specifically asked for, changing tolerances or even tests, and frequently disabling tests.

Re: Claude wrote a functional NES emulator using my engine's API

#58
post #23
post #3

It’s a shame that the source code isn’t commented and documented more. At the very least, I would see it being helpful to add some documentation for every CPU op code being emulated.

If you let it, Claude Code will write a comment for almost every single line of code.

Even if you try to get them to not, they will still overcomment the code. Or at least overcomment it from the perspective of a human. From the perspective of the LLM, I suspect the comments are necessary for it to be able to get the code output correct.

Re: Claude wrote a functional NES emulator using my engine's API

#59

Earlier quoted context omitted.

That's not how software development works. Folks think, they write code, they do their own localized evaluation and testing, then they commit and then the rest of the (down|up)stream process begins. LLM's skip over the "actually verify that the code I just wrote does what I intended it to" step. Granted, most humans don't do this step as thoroughly and carefully as would be desirable (sometimes through laziness, some…

Claude Opus 4.5 will routinely test its own code before handing it off to you, even with zero instruction to do so.

One commercial equivalent to the project I work on, called ProTools (a DAW), has a test "harness" that took 6 people more than a year to write and takes more than a week to execute.

Last month, I made a minor change to our own code and verified that it worked (it did!). Earlier this week, I was notified of an entirely different workflow that had been broken by the change I had made. The only sort of automated testing that would have detected this would have been similar in scope and scale to the ProTools test harness, and neither an individual human nor an LLM is going to run that.

Moreover, that workflow was entirely graphically based, so unless Claude Opus 4.5 or whatever today's flavor of vibe coding LLM agent is has access to a testing system that allows it to inject mouse events into a running instance of our application (hint: it does not), there's no way it could run an effective test for this sort of code change.

I have no doubt that Claude et al. can verify that their carefully defined module does the very limited task it is supposed to do, for cases where "carefully defined" and "very limited" are appropriate. If that's the only sort of coding you do, I am sorry for your loss.

Re: Claude wrote a functional NES emulator using my engine's API

#60

Earlier quoted context omitted.

They absolutely can do that if you give them the tools. Seeing Claude (I use it with opencode agents) run curl and playwright to verify and then fix it's implementation was a real 'wow' moment for me.

We have different experiences. Often I’ll see Claude, et. al. find creative ways to fulfill the task without satisfying my intent, e.g., changing the implementation plan I specifically asked for, changing tolerances or even tests, and frequently disabling tests.

Are you a customer?
Post reply on HN