I’ve found utility in removing code.
I feel that doing the job with the fewest lines of code, is best.
I also believe in focused/pure scope. If I write a type or API to do a job, then it should do that job, and only that job. If I want to add functionality that is out-of-scope, then I’ll often write another type, instead of adding it to the existing one. Making this type of decision is always fraught.
But, like in all things, it depends. Sometimes, reducing the overhead of things like setup and testing is a good reason to not introduce a whole new resource, but I should make it a point to document the reason for the incongruity.
This is especially true, when designing user interface. I’ve found that, usually (not all the time, though), less is more.
Josef Albers is known (amongst other things), for the quote “Sometimes, in design, one plus one is three or more.”.
> I’ve found utility in removing code.
> I feel that doing the job with the fewest lines of code, is best.
And that is one of my gripes with AI models and code. They are so, so verbose. It's a nightmare.
"Why don't you let AI implement that small feature, it will be faster.", they would ask.
Well, because if do, it will completely pollute my carefully crafted interface that I kept small, simple and understandable for easier maintenance and extension.
And yes, I might spare a few hours by having _it_ work for me. But then I need to spend a more hours to clean-up the code noise and complexification.
Sorry for having polluted the conversation by bringing AI in, when for once, ironically, it was not about AI.. I needed to vent, while fully approving of your take.
I just had to rewrite a screen written by an LLM.
It started, by giving me a 2,500-line (about 50% documentation) viewcontroller that ate so much memory that the app would jetsam after the user just did a couple of things.
I then, spent about a week, tracking down memory issues, until we narrowed it down to the MapKit cache. All this time, the LLM was making the code scarier and scarier. It was exactly what I would expect from an inexperienced (but smart) engineer, panicking, and adding more and more cruft.
The LLM ended up suggesting fixes that didn’t work that well, and made the UI janky. Also, it was terrifyingly delicate. I don't think it would have survived one feature request.
By now, the viewcontroller was over 4,000 lines.
I asked the LLM to refactor for redundancy, quality, and size.
It removed all the documentation and logging, reducing the size back to about 2,500 lines (about 1% documentation).
Yay.
Except all of the bush-league threading and awful workaround shit was still in there, but now impossible to understand.
At this point, I gave up, threw out the LLM code, and rewrote the viewcontroller from scratch. Took a day and a half. I figured out how to force MapKit to flush its cache (2 lines of code). It's a well-known issue, and the solution was the first StackOverflow answer that showed up in the search.
It’s currently about 1,400 lines (about 50% is documentation), and works great.
Lesson learned.
> It removed all the documentation and logging, reducing the size to about 2,500 lines. [..] but now impossible to understand.
Nice. Lol.
> At this point, I gave up, threw out the LLM code, and rewrote the code. It’s currently about 1,400 lines (about 50% is documentation), and works great.
I've had similar experiences. But I must be "holding it wrong", judging by all the other articles on HN..
I get the impression that your takeaway is not to use LLMs, but I think your takeaway should be to give them more oversight. The way you describe this, it sounds like you went pure vibe coding.
> I asked the LLM to refactor for redundancy, quality, and size.
What did you expect when you asked it to make it smaller?
I’ve had good success with LLM refactoring. But the refactoring has never been “go make this better and smaller”. It’s “go do this specific thing to reduce redundancy” or maybe “give me a list of ways to improve the code redundancy” and then iterate with the LLM to improve the ideas and execute on the right ones.
I don’t think you can just vibe code your way out of a vibe coded mess.
No, my takeaway is the same as with working with any other developer.
If I take responsibility for the product, then I can't afford to accept sub-standard input; no matter the source. My main mistake was not immediately putting the kibosh on the LLM, as soon as it started thrashing. Instead, I played along, for waaaayyyy too long.
The request for refactoring was actually a fairly long and detailed prompt. I can't recall it exactly, but by that time, the context was well and truly poisoned. The LLM had decided that its way was best, and could not be persuaded, otherwise.
The same goes for humans, in a similar situation. I've encountered almost the exact same behavior, many times.
I am quite aware that my personal standards tend to be a lot tougher than what seems to be the norm, these days, so I am willing to admit that I may be demanding too much, but that's how I was trained.
But I have been making extensive use of LLMs, for the last few months, and they have been incredibly helpful. The Rubicon has been crossed. There's no going back, but I also need to make sure that I don't get drunk on Kool-Aid. LLMs are still very much a WiP.
I evaluate how good models are now by how good they are at removing code.
It’s fairly simple (assuming the test harness and agents.md are well written): do iterations of trying to remove code, ensure it passes, then have a human review it. Less code to review that way.
I think when somebody trains code golfing LLMs with reinforcement learning they will inadvertently be smarter
> removing code
Cue link to Negative 2,000 LoC [0]:
0. https://www.folklore.org/Negative_2000_Lines_Of_Code.html