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.

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.

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.

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.

1k lines is too much to even review in a day and I would assume it's useless.

Typical disclaimers "lines != Statements != Productivity" apply. Also I'm not counting things like unit tests and documentation.

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.