logoalt Hacker News

threethirtytwotoday at 6:37 AM1 replyview on HN

Stop repeating this trope. It can spit out something you've never built before this is utterly clear and demonstrated and no longer really up for debate.

Claude code has never been built before claude code. Yet all of claude is being built by claude code.

Why are people clinging to these useless trivial examples and using it to degrade AI? Like literally in front of our very eyes it can build things that aren't just "embarrassingly solved"

I'm a SWE. I wish this stuff wasn't real. But it is. I'm not going off hype. I'm going what I do with AI day to day.


Replies

zjptoday at 6:50 AM

I think we are in violent agreement and I hope that after reading this you think so too.

I don't disagree that LLMs can produce novel products, but let's decompose Claude Code into its subproblems.

Since (IIRC) Claude Code's own author admits he built it entirely with Claude, I imagine the initial prompt was something like "I need a terminal based program that takes in user input, posts it to a webserver, and receives text responses from the webserver. On the backend, we're going to feed their input to a chatbot, which will determine what commands to run on that user's machine to get itself more context, and output code, so we need to take in strings (and they'll be pretty long ones), sanitize them, feed them to the chatbot, and send its response back over the wire."

Everything here except the LLM has been done a thousand times before. It composed those building blocks in novel ways, that's what makes it so good. But I would argue that it's not going to generate new building blocks, and I really mean for my term to sit at the level of these subproblems, not at the level of a shipped product.

I didn't mean to denigrate LLMs or minimize their usefulness in my original message, I just think my proposed term is a nice way to say "a problem that is so well represented in the training data that it is trivial for LLMs". And, if every subproblem is an embarrassingly solved problem, as in the case of an emulator, then the superproblem is also an ESP (but, for emulators, only for repeatedly emulated machines, like GameBoy -- A PS5 emulator is certainly not an ESP).

Take this example: I wanted CC to add Flying Edges to my codebase. It knew where to integrate its solution. It adapted it to my codebase beautifully. But it didn't write Flying Edges because it fundamentally doesn't know what Flying Edges is. It wrote an implementation of Marching Cubes that was only shaped like Flying Edges. Novel algorithms aren't ESPs. I had to give it access to a copy of VTK's implementation (BSD license) for it to really get it, then it worked.

Generating isosurfaces specifically with Flying Edges is not an ESP yet. But you could probably get Claude to one shot a toy graphics engine that displays Suzanne right now, so setting up a window, loading some gltf data, and displaying it definitely are ESPs.