At 600k lines of Rust, not finding those issues yet. You can search for different versions of same concepts, I mean you need to refactor a lot anyway.

I just finished an LLM assisted Rust rewrite of a production project after a couple months. It's around 150k LOC, mostly Rust, excluding generated code and tests. Around 200k if I include tests. I'm also now starting to extract / refactor some of it's code into their own reusable crates, so my LOC isn't going to grow and might even shrink a bit. I can't speak to 1M LOC, but I'd imagine that takes a lot of human context to reason about too, and you probably want to break it up into manageable chunks if possible.

LLMs have been a boon. I have a lot of guardrails in place though to keep the LLMs focused and producing correct and ergonomic code. A lot of effort and review has gone into creating these guardrails (choice of language, linting, forced conventions, tests, etc.). A lot of these practices will be useful in future projects. I highly recommend this approach. Don't just copy skills or processes that others publish. Figure it out yourself so the lessons stick. Human in the loop, especially one that has learned through practice and failure, is still immensely valuable IMO. It's a fine line between getting stuff done and yakshaving over your tooling... but that's always been the case, as proven by my vim dotfiles. :)

It's worth noting that the AI industry is filled with tons of snakeoil and BS. You don't need to take someone's course in "21 steps to be productive with AI" or w/e. Just like learning a new programming language, dig right in and try to build something that scratches an itch. Pick a project you have complete autonomy over instead of that "spend all the tokens" crap managers were pushing until recently (this has corrected now right?).

Parent saying "Skill issue" though... What a jackarse.

I haven't hit nearly a million lines, that's true, these projects are "only" 20k and 45k lines of code or so, respectively; however, I do have directed acyclic graphs of worker agents, managed asynchronously by the agent I chat directly with, do huge architectural refactors (the most recent, was to update everything in the codebase that used the sychronous Lua standard library `io` functions to use the asynchronous, multithreaded IO system I created for the editor — at least, everything that could use the new library, which I kept deliberately simple in a few ways, and everything that wasn't already temporary, but you know) and that's turned out quite well, and at least for me, 45k sloc is nothing to sneeze at, especially since with a green field project there's less examples to keep them on track. I do regularly check in to make sure it's using my design to the fullest, as well.

I think "skill issue" is often deployed (including here) as a shortcut for what you said - "the only thing stopping them is that no one has helped them understand".

(I try not to say "skill issue" myself because it comes across as rude.)

In my experience, because as you say, the flexibility of these tools and how you engage with them is so broad, and how much the nuances of thay engagement can often matter, the only way to teach someone how to do what you do with them is to sit down and pair a program with them. Barring that, any instructions you could give would massively under-determined what they actually try as a result of your instructions, and so it ends up being an infinite loop of them just coming back and saying "it doesn't work." So in the end, people really just have to discover how these things work for themselves.

https://williamcotton.github.io/datafarm-studio/

https://williamcotton.github.io/algraf

https://williamcotton.github.io/pdl

https://github.com/williamcotton/algraf

https://github.com/williamcotton/pdl

Check out the /docs dir in the repos for each plan file and the language specs.

They are my 4th and 5th DSLs and I learned quite a bit along the way, most importantly how to separate a WASM runtime wired up to a Monaco editor “lsp” with the same crate for editor-services that works with the actual system binary LSP.

Feel free to peruse the repos! I follow compression-oriented programming, so there are places where the code is "insufficiently" DRY intentionally, as I feel out the precise use cases, and I explicitly made some other decisions (like a God editor object) for meta design reasons (I want it to be easy to modify the editor state from anywhere, just like in Emacs), so all I ask is that you review these without being excessively punative to prove your point.

https://github.com/alexispurslane/cursed/

https://github.com/alexispurslane/industrialworld/

Feel free to look at my past projects, prior to me starting to use AI (which started with gemini-ocr) to assess my baseline skill level.

I've found this to be more consistently the case than not. People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function. They put together a keyword soup post that sounds good on an AI generated resume but falls apart upon investigation.

Not specifically about the comment you replied to, but there has been an absolute Cambrian explosion of plausible sounding projects that use really complicated words that are just AI psychosis. Recently there was someone who posted a huge Lean proof on GitHub supposedly of proving P=NP. The problem is AI is really good at deluding people if that person doesn't have domain specific knowledge. AI severely makes dunning Kruger worse

The GP was just talking about not using common languages like TypeScript and frameworks like React, which is a bar of unusual that seems arguably far lower than mine, especially since I literally defined special custom DSLs with unusual semantics, and used libraries like SDL_gpu with little to no pre-existing training data. So this seems like shifting the goalposts.

Also, what would be highly unusual to you?

The most esoteric I've seen from an LLM was this light rendering fix in a TempleOS game engine: https://gitgud.io/CrunkLord420/cyberchud/-/commit/c49879751c...

Though it's still cheating with a compatibility layer, I don't think claude touched any HolyC.