I think this is perfectly fine.

If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era.

I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS. A dozen people or so could even run Firefox! I remember (now legend) Terry bothering us to check out LoseThos or GodOS or whatever was its name, but quite a few people had OSs that could do more than that.

Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished.

> If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era.

Yeah, but the people authoring those learned something.

> I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS.

Great example! I, too, once had my own toy OS, and browsed OSDev wiki nonstop. The thing is no one in the OS dev community were writing things they intended to place in front of actual users!

The difference now is that these incomplete projects:

a) Don't leave their owners any wiser than when they started, and

b) Are actually intended by their owners to be used by actual users.

> I have learned a lot from those experiments, even if they're not polished.

Would you have learned as much if you told a magic box "Make me an OS" and then slapped your name on it and uploaded it to GH?

Probably not, but sometimes I wonder if the lowered activation bump lets more people try it, even if they just vibecode the whole thing, and maybe learn a thing or two in the process? They wouldn't learn as much as they would if they did it by hand, but they would've never done it by hand in the first place - so this is better maybe? I don't know. The whole field is in a weird place right now, all previous rules of thumb might be wrong.

My gut says there are fewer people in that group than there are people who would've learned something who now decided learning something isn't worth the effort. A net loss.

> Yeah, but the people authoring those learned something.

I've built tools myself with AI assistance and I've learned a bunch, and will still keep learning.

> (now legend) Terry bothering us to check out LoseThos or GodOS or whatever was its name

Temple OS :)

Dude was a tweaker xD

He had schizophrenia.

That was half memory-loss, half joke, since Terry was always changing the OSs name. Wish he was still with us, renaming it every year!

> Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished.

This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.

> This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.

Almost all of my prototypes are made this way. "I made this in a weekend", is more often, "I made this in a day". Like any trad-coded project, time to vibe code a backend vs frontend time is 1:N

> This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop

This is exactly the same as demanding, that people who post their thoughts always post original, useful thoughts. It's just not going to happen. Making something easy will increase the total volume and the majority of that volume will be junk. It's inevitable. What is needed is a search engine for quality software. Perhaps LLMs can do that, since they are better at understanding concepts than generating them.

LoseThOS didn't burn through hundreds of thousands of dollars of expensive and environmentally questionable compute.

True! It just burned though other forum contributors patience! I miss the Terry from back in the day (early 2000s?) though.

The more technical you get, the more subsitutable you become - or at least, people think of it in that way, because the whole idea is "It's not me, or the people, it's the raw technical prowess that earns its keep in this place".

But it seems like we're finally starting to accept that "accidentals" like network effects, ownership, accountability, etc. are important. Of course, that's why many of us fled to technical corners in the first place - because the "accidentals" become tied up with things like nepotism, unfair and arbitrary judges from random humans who don't understand your merit, the need for bullshitting more than real technical value. Supposedly, anyways.

My thoughts too. The LLMs made me understand that the world had been working like that long before LLMs. Luck plays an enormous part in life. We gravitated toward a discipline that seemed free of all those problems, when in fact it had those downfalls better disguised.

I think it is a very good point: "because the "accidentals" become tied up with things like nepotism, unfair and arbitrary"

I never thought of this from this perspective but indeed it seems to be totally true.

> Not understanding to the core the software you wrote, is going to exploded in your face.

Short-termism at its peak. Code maintainers will learn the hard way how to set the boundaries between ai-generated code, and human maintainable code.

> Its one thing to get a head start using this trick, its another to actually learn the code of your rewrite.

I worked for a startup that stopped feature development and did a complete rewrite of a huge codebase. I was assigned to a side project during this time and missed the entire rewrite process. I came back to a completely rewritten codebase.

There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.

If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch.

I think they did it the right way based on my pre-LLM. Rewriting into a different language as fast and basically as possible is important for getting the team switched over quickly. Rewriting into a different language in X days is actually a good goal to minimize.

> There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.

> If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch

They eventually might regret this, when they are trying to get rid of the last lines of unsafe code. Rust needs to be written differently before you can write safe things to perform fast when compared to other languages or unsafe code. It takes a lot of experience before you can see it.

I doubt it.

If this were a major issue then you'd have to always nail your Rust architecture correctly from day 1 to handle future unknowns, and this isn't the case.

More importantly, LLMs are more than capable of figuring out how to rearchitect code and they have no problem making sweeping refactors for you.

> I constantly see software being published on reddit that does X, Y, Z only for the authors to abandon it as fast as they vibe coded it.

Also if you whip something up, you tend not to care for it as much as something you took the time to create in a "proper" manner.

Also I think porting code to another language or rewriting is one of the easier tasks for an LLM, since it has an extremely detailed spec (the source code itself) and a ton of tests already (hopefully).

In my experience, it will go to every length to convince you it has ported code that it hasn't. It will silently drop upstream unit tests it has no code for, if questioned it will insert some markdown giving some rational why that specific bit was deferred, after the fact, and then point you to it. This was Opus 4.6 for reference. I have had much better luck with small numbers of higher level tests that I can individually verify equivalency. I haven't tried having it do differential fuzzing on some high level interface, that seems like it might work in some cases. But to summarize, treat it like an adversary trying to deceive you.

> I have used LLMs to create stuff like word clones just for fun. It was a disaster. Sure, it had the basic functionality. But the moment you started with page structure (harder then one non-stop scrolling page), tables, images, rotating, and so many details that make up just the basics of word. Not even the extended functionality. You see every LLM just fall on its face.

What do you think of https://scramblequest.app and https://wordpeek.app ?

I have never looked at any of the code for them

edit: Yeesh, misread your comment as "word games" not "word clones" and was very confused about the claim. Probably should have noted my confusion and re-read.

I think they might mean Word as in Microsoft Word. Just based on the feature list they were describing.

Are you comparing 2 relatively simple games with... Word?

Word is basically an operating system. Unix people like to make fun of Emacs for being one, but Word is basically one, too. And all the features in there are used, otherwise Microsoft wouldn't keep them around.

>Word is basically an operating system.

And .doc files are basically a memory dump.

That was certainly true once, but now all that state is serialized to xml amd zipped up. You can unzip it and look at it if you don't value your sanity.

So what you're saying is that the files are basically a memory dump formatted as XML? :-p

A selective menory dump that when deserialized can ignore fields not present its version, but yeah.

That's why I said .doc. The format you're talking about is called .docx

Dump is a great word for it

Haha, I misread as "word games" and was very confused about the claim.

Nonsense. Provide/create proper tests for all features, and let the LLM test and fix everything.

In case of ccc (claudes C compiler) they just did not use any tests, though they are many existing C testsuite. They just stopped, when it finished compiling the kernel, still failing hundreds of tests.

It’s strange how you think AI is some static thing that only produces the type of output you experienced and isn’t constantly improving. My experience has proven the latter time and time again.

> Using a LLM to translate a project in a short time, is by itself incredible.

Not really. Transpilers have existed since forever.

The hard part is all the edge cases. (And LLMs don't solve this problem; they probably akshually exacerbate it.)

Thank you for saying this! Every now and then I start to feel like I'm either the only sane person left or I must have gone insane and don't realize it.

LLMs amazed us and we've been trying to find a good use for them since and there's a lot things like this, replacing a transpiler with a non-deterministic machine that just guesses when it doesn't know the answer.

Shouldn't we be targeting LLMs at problems that traditional software absolutely can't handle?

I'd like more people to be writing about this, because I find it fascinating. I have my own private project that is heavily LLM-coded, just to learn about what it's like. It's amazing how everything is different yet everything is the same. Big complicated features can start working quickly and give a massive endorphin boost, but then fixing them up and integrating them in properly and polishing the UI? It all feels even more painful having experienced the heady thrill of the initial implementation. And things get to a point where you can feel the inertia set in, the point where things have gotten so hacked up that the LLM can't make any progress without creating an even bigger mess. It's the point where you have to go back and fix up the architecture, or scrap the whole thing and restart with a better plan, or a bit of both (rewind to the "last sane point"). It's like developing with a jetpack -- you can go way faster towards your goal, and you can slam into walls way faster and more painfully too.

I think there are tons of learnings to be shared about how to do this stuff, but it seems like it's all blocked behind arguments over whether AI is the best or worst thing ever, and penis-measuring contents about how to hold the tool. The net benefit is a very open question, and both the doom and gloom perspective and the AI booster perspective are valuable and have a lot of things right. But there's a dearth of information about what things work, what things don't, what happens in the process of using AI, how to adjust one's behavior and which of those adjustments is harmful even if effective.

But then, I'm part of the problem. I keep meaning to write up a series of experience reports, but it's a lot of work. More fun to vibe a new feature into existence, or to finally fix a UI wart...

To build a robust piece of deep-functionality software (like an MS Word clone) with an LLM, you have to start from the underlying architectural decisions, particularly how data is structured and how it flows through the system.

If you have an LLM or human just start coding up something without nailing down those decisions first, then he/she/it will implicitly make those decisions arbitrarily in the moment (usually based more on pattern-matching than real weighing of alternatives) and the result will be a massive mess.

Ideally for an LLM, you'd hand-write a highly detailed DESIGN.md file to encode those decisions and a suite of test fixtures to enforce them.

Part of what's nice about AI is that I don't feel that bad about pulling out and rebuilding some new feature that the AI has put a lot of time into but that I personally haven't. It let's me explore certain approaches and not feel tied to certain decisions that I might have not been confident about at the outset.

As I understand it, bun was already vibe coded so nothing of value was lost in vibe porting it to a different language.

A fundamental miscommunication seems to be what part people are interested in. Just because I like to bake cakes doesn't mean I want to grow and mill my own wheat. Just because I like to make programs doesn't mean I want to tyoe code or learn the details of some library.