I think having style guidance in your context is valuable for avoiding this kind of thing. Having to read awful, cliched text all day is even worse than having to read reams of useless code. I have some simple humanizing content in there that specifically calls out the rhetorical devices that AI loves, and it drastically improves the diffs and comments. It also makes the coding performance generally slightly worse, but ergonomics uber alles.
I think I have LLM burnout
11–20 of 391 posts
Re: I think I have LLM burnout
#12Avoid Gemini and the lesser ChatGPT models and your emoji problem goes away.
Re: I think I have LLM burnout
#13I don't think I have a "burnout", but LLMs are really exhausting due to amount of pressure they generate. No one is really pushing me to increase my workload, but at every moment there is always something ready, done by my clankers or clankers of other people that I could be unblocking. In the past (before LLMs) it was already hard to keep up, but now it feels like there's 10x more things waiting at any given time, and there could be 10x more if everyone just "optimized" and streamlined processes fed the AI even more tasks in parallel faster. It just being a bottleneck of everything, all the time is tiring...
I am happy about all the little side-projects, and ideas it help my realize, and I enjoy exploring this new world, but I've noticed LLMs feed my unhealthy "don't want to take a break and waste time being idle" mindset, and I need to correct it.
W.r.t. article's main complain - I think the similar thing happened due to factory manufacturing automation. What used to be a varied skillful craft in a shop became standing in a single place of an assembly line doing the exact same thing whole day. LLM took away the more creative and variable part of the work, and left the repetitive QA rubber-stamping. Probably some of the mitigations used back then could be rediscovered today.
Re: I think I have LLM burnout
#14I do not have the burnout but I certainly operate similarly to the author. I continue to be unable to establish a workflow where allowing the LLM to generate code that I review is faster than writing the code myself. Literally the only two ways out of this dilemma is to blindly trust what was generated or to generate an uncharacteristically exhaustive suite of unit tests to validate every possible scenario. I just wr…
> generate an uncharacteristically exhaustive suite of unit tests to validate every possible scenario. This is what you want. You want comprehensive tests at every level, far more than is reasonable for a human to build or maintain, from unit, functional, to full end to end and beyond. Adversarial testing (both TDD-style "write tests to demonstrate this bug", and posthoc "prove this patch wrong with a new test") is t…
I used an LLM to build this
https://github.com/dprkh/eventfs
It has good test coverage, mostly unit tests but also a number of end-to-end tests. I also made the LLM build a benchmark, which you can find at the bottom of the readme. It is obviously slow, but I thought that it is good enough to work. When I tried to write a 1 GiB file, I found that it broke down, and after writing half the file, the speed went to under one megabyte per second. Implementation is 10k+ LoC, and I have no idea what is going on there.
Re: I think I have LLM burnout
#15This is legitimately the reason I'm looking to leave programming. I got into programming because the problems of programming were interesting to me. But if the problems go from "figure out why this calculator is off by one in France" to "Get this LLM to stop spamming cutsey emojis", then maybe it's time for a career change.
(And I admit I'm salty that the "I don't give a shit about why the calculator doesn't work in France, I'm just here because they pay me to fix it" people were the ones vindicated by technological progress)
Re: I think I have LLM burnout
#16[deleted]
Re: I think I have LLM burnout
#17I do not have the burnout but I certainly operate similarly to the author. I continue to be unable to establish a workflow where allowing the LLM to generate code that I review is faster than writing the code myself. Literally the only two ways out of this dilemma is to blindly trust what was generated or to generate an uncharacteristically exhaustive suite of unit tests to validate every possible scenario. I just wr…
And for those that have similar-ish sentiments, what mental defect is had that prevents them from just drinking that sweet tasty kool-aid and just use the slop created. What demented trait is in them that causes everyone to just be a stick in the mud trying to ruin everyone else's good time?
In my personal experience, the ones most enthusiastic about LLM magic are those that can't code, but can now walk away with something functional if not quite the best code. Now that they can produce workable code, it will make everyone better. Yet, they have no idea how maintainable the slop is or if it's slop at all.
Re: I think I have LLM burnout
#18I do not have the burnout but I certainly operate similarly to the author. I continue to be unable to establish a workflow where allowing the LLM to generate code that I review is faster than writing the code myself. Literally the only two ways out of this dilemma is to blindly trust what was generated or to generate an uncharacteristically exhaustive suite of unit tests to validate every possible scenario. I just wr…
Don’t read the code!!
Re: I think I have LLM burnout
#19Earlier quoted context omitted.
> generate an uncharacteristically exhaustive suite of unit tests to validate every possible scenario. This is what you want. You want comprehensive tests at every level, far more than is reasonable for a human to build or maintain, from unit, functional, to full end to end and beyond. Adversarial testing (both TDD-style "write tests to demonstrate this bug", and posthoc "prove this patch wrong with a new test") is t…
I used an LLM to build this https://github.com/dprkh/eventfs It has good test coverage, mostly unit tests but also a number of end-to-end tests. I also made the LLM build a benchmark, which you can find at the bottom of the readme. It is obviously slow, but I thought that it is good enough to work. When I tried to write a 1 GiB file, I found that it broke down, and after writing half the file, the speed went to under…
Yep.
Re: I think I have LLM burnout
#20> My main project right now is to establish a framework for large-scale, unsupervised code generation in our codebase Anyone else working on something like this or know of any projects attempting it?
https://github.com/gastownhall/gascity is certainly a choice. I enjoyed playing with gas town but it was a little too nondeterministic for production code, I think.
Directionally if what you're doing is straightforward it's an amazing experience to be able to slap in an epic planning document and wake up the next day to it being "done", with a big asterisk that done-ness is directly proportional to how good of a spec and how good of a model you were using.
That being said, these days if you use Fable, slap in an epic planning document, and ask it to run a workflow (be sure to specify that subagents should use, say, Sonnet, or wave goodbye to your wallet), it's almost as good as gastown/gascity but far more predictable.