Hacker News new | ask | show | jobs
by 3abiton 243 days ago
How does this differ from nanochat?
2 comments

Good question! I think you mean nanoGPT (Karpathy's minimal GPT implementation)?

Key differences:

nanoGPT: - Minimal reference implementation (~300 lines) - Educational code for understanding transformers - Requires manual setup and configuration - Great for learning the internals

create-llm: - Production-ready scaffolding tool (like create-next-app) - One command: npx create-llm → complete project ready - Multiple templates (nano/tiny/small/base) - Built-in validation (warns about overfitting, vocab mismatches) - Includes tokenizer training, evaluation, deployment tools - Auto-detects issues before you waste GPU time

Think of it as: nanoGPT is the reference, create-llm is the framework.

nanoGPT teaches you HOW it works. create-llm lets you BUILD with what you learned.

You can actually use nanoGPT's architecture in create-llm templates - they're complementary tools!

Unlike nanochat this is purely vibe-coded, improving vibes by 110%, with 112x more emoji. A key innovation that gets to the heart of the problem is that this project stores python files as strings in typscript files to help improve workflows. I imagine the author solved this engineering challenge to overcome existing limitations\emdash more efficient, interpretable, and maintainable code\emdash in existing projects.
> Unlike nanochat this is purely vibe-coded, improving vibes by 110%

Karpathy clearly said that it wasn't vibe coded. Apparently it was more time consuming to fix gpt bugs than to do it by himself.

The Python-in-TS bit made me smile But to clarify, it’s a standard TypeScript CLI — no such hacks involved, just template-based generation.
Ok, but there is no reason to bake it into the TS scripts. You could write the python scripts and package them using standard tools. In my experience only an LLM would do that, since it makes sense to generate the code and templates to insert in one go. However, if a human were to do it, the python scripts would be their own files and they would be bundled / read in as strings when/as required. A gigantic lump of text in a string makes no sense in human paradigms, even if it makes perfect sense for an LLM to do it. For humans it is incredibly hostile to update and maintain.

As a side note, without looking it up, on your device, what is the process for typing an emdash?

While you are not wrong about this not being the wisest choice, i have seen it done before countless times already long before llms arrived. So i don‘t think it‘s such a clear sign of intense llm usage as you make it out to be.
Fair point I agree embedding code as strings isn’t ideal. I did it mainly to make npx create-llm portable without needing a Python setup during scaffolding. Definitely open to improving that happy to refactor if you have suggestions.
That makes zero sense. Am I even speaking with a natural person right now?!? Your comments sound like llm bullshit and everything about this project reeks of it as well, from code to readme.
It makes sense to me. its great to see tools like create-llm which help to kickstart llm development without spending lots of time putting low level stuffs
Bro is angry about using llm to write code instead of being happy about a working code that makes it extremely easy for anyone to build their own nano gpt's.

LLM's are just the next evolution that assist you with coding tasks... similar to w3schools => blogs => stackoverflow, and now => llm's.

There's absolutely nothing wrong with using them. The problem is people who use them without reviewing their outputs.