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...

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.

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.

> 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.

> 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.

> 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.

> 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.

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).

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.)