Here is the thing though: while one may be a total newbie and can barely type code apart from say downloading Python 3.9 if you have to deal with tremendous amount of code you'd have to compile, address potential errors (during compilation), if the LLM gives you code that erronously works against your goal (example: it automatically put a safety 'alignment' on my project basically forbidding 'rm -rf' to be run on my computer...but i'm on windows so i saw this "safety" feature and just manually deleted it from the code).
The question is: Is there any difference between a junior dev or rather someone just starting and someone who's been coding for years or even decades? In a way it's kind of like asking "do mathematicians use calculators the same way non-mathematicians use them?" I guess the difference is minimal?
The hard part about programming is not writing down some syntax that does some function. The hard part is designing the system to scale properly as you add more features, it's dividing the problem into parts that make sense so that they can be easily understood and reasoned about. Typing the solution into an editor is one of the easy steps once you understand the solution.
> (example: it automatically put a safety 'alignment' on my project basically forbidding 'rm -rf' to be run on my computer...but i'm on windows so i saw this "safety" feature and just manually deleted it from the code).
I hope you replaced it with corresponding rules about `deltree` and `rmdir`.
> The question is: Is there any difference between a junior dev or rather someone just starting and someone who's been coding for years or even decades
There are many differences in how they approach the task of coding. I couldn't tell you anything specific about LLM use. Certainly I have seen explanations of how more experienced devs can get value from using LLMs, in ways that are basically inaccessible to juniors.
But if the overall differences could be simply and usefully explained, it wouldn't take years to become senior. I strongly advise you to stop looking for shortcuts and start building your understanding.
My heuristics for assessing the difficulty of changes revolve around "load bearing-ness".
It's basically free to change code no one uses. It's not bearing any load. If your metric is LOC you can be very "productive"! But from another perspective you cannot tell if you are productive yet, the value is not realized until people pay for it and rely on it.
Changes in software that people use affect "load bearing" LOC. There is "pucker factor".
You can kinda multiply together: what is the inherent complexity of the domain, is the change reversible, is your change stateful, how many customers use it, how deeply do they interface with it, how many stakeholders are involved in the change, what are the consequences of failure / mistakes, how many cases / paths do you need to test - to get a feel for the true difficulty of a change.
The difficulty of a change is separate from the value it creates, but often they're related. Why? Because in widely used software if a thing lots of people valued was easy, it would already be done. Of course pathologies do exist where people do difficult things for no good reason or foolishly leave easy money on the table.
Greenfields / startups are a special case / time, where difficulty seems temporarily uncoupled from value. You can make huge and potentially valuable changes quickly and easily if no one is using your thing. But there is no free lunch because the downside is that you are only creating potential value, you still have risk that all the code you wrote is useless.
This is why some some people might say 30 LOC / day is a lot while others might name a much higher number. The people saying the lower number are the ones with existing customers, they are talking about "load bearing" LOC.
f(n) = x/y. value = goal/loc.
"goal" here is just arbitrary number of usefullnes of code that aligns with some common uility like say 10 = ASI/eternal happiness and immortaility or whatever while 1 being 'terminator' and 7, 8 being useful business code so on. loc is self-expplanatory.
>goal / >loc -> < 10/1 a; <goal / >loc -> < 10/1 b; <goal / <loc -> < 10/1 c; >goal / <loc -> = 10/1 d
So, the very best value possible will be say "d" 10, f(n) = 10/1 - any other of the 4 possible permutations aka options will lead to worse result:
But while such simple formula could illustrate the value of software project overall, a key detail ommited could be the lowest possible number a great goal may require, most people would agree writing ASI in just <100 words aka 'one line' is just not possible, or anything useful.
It's like complaining you could write 100 000 a day when the project is Operating system or 3dsmax clone, it surely will be better to finish it early and there is a lowest bar possible that cannot be decreased even with F# or whatever language that saves words.
That would make you, approximately, the best programmer in the world.
This does not change as the project gets larger.
LLMs don't write like this without very specific instructions, and it might be difficult even then. After all, most programmers don't write like that.
But I think they should, and I'm absolutely prepared to defend that.
Losing brackets doesn't make the code harder to read. After all, Python code must be properly indented for correctness. It does mean that you can't use the % key in vim to find the end of a block easily. But Python-specific editors can easily identify the end of a block and provide a "fold" feature if you like using those. I just prefer not to write code that would benefit from that.
Pumping out that much code means you're not putting thought, care, or professionalism into the work. You're pumping out garbage and making it everyone else's problem to clean up.
If I saw anyone other than a greybeard developer pushing out code like this, I'd fire them. Very, very few people can actually work at this level and produce good code. Everyone else is just shitting out slop, ruining the product, and dragging down the entire team.
Additionally, only extremely inexperienced and naïve developers even think about LOC counts. If you're focusing on this, it tells me you have no idea what you're doing and that the code you're putting out has about as much value and utility as the shit my dog took this morning.
note that LLM-generated code is even more of a liability because when you go to maintain it you will not have the context of the decisions that went into writing it - it's legacy code from day one.
Rmember when we had to create programs reading the assembler manual and put byte by byte? It was kinda hard. Then someone invented a language. A compiler started to do all the work you did not wanted to do. And the time you took to create a program came from months to minutes.
My only question is, why use something like that Grok since you know who runs that.