Grok: Thousands LOC a day in C is a big deal even if the "coder" uses LLM?

I spent Friday and today using Copilot on a project and I (or it) wrote about 13k LOC: about 5k LOC of python code, 6k LOC jupyter notebooks and 2k LOC markdown files with agent orchestration. My time was spent waiting for Copilot to do the coding, then running tests and making sure they pass and they are meaningful, and then debugging. The debugging is a very interesting experience. You devise various tests to tease out what's going wrong and narrow down to a very small context so the issue becomes apparent to both you and the LLM. I didn't actually write a single line of python code myself. But a junior developer would have gotten stuck at the first problem that required debugging. These two days felt a lot like hard work. The only difference is that I have much more to show for after 2 days of work than I used to have in the past.

In every language you can take 100 LOC and compress them into less than half if you abstract it and optimize it. What I mean is that LOC doesn't tell you much about your software, but there is a a point where there is probably a lot of repetitive logic and more likely to have issues because it's not abstracted properly.

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.

15 (just 15, not k) is par for a corporate dev on a good team. 100-300 is what you might expect from a "10x engineer" or independent dev consistently in the flow state.

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.

LOC are not all the same.

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.

a good way to look at it is that problems solved is an asset, but lines of code are a liability. you pay the cost of maintaining that code because you want the benefit of the problems it solves.

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.

Thousands of lines of code per day is an enormous red flag. That is well beyond your ability to write or review on your own in a single workday.

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.

It its just a tool, use it as a tool.

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.

SLOC as a metric of productivity was always useless. AI only proves this more.

It's a big deal if LOC is proportional to how much money you make. Otherwise it's an unequivocal burden, you can't pay me any amount to adopt a 10,000 SLOC C99 codebase.