I think I have LLM burnout
alecscollon.com
I think I have LLM burnout
1–10 of 391 posts
Re: I think I have LLM burnout
#2Tell the llm to answer like a cavemen, if llm talk like cavemen, the answers become shorter and more compressed.
https://github.com/JuliusBrussee/caveman
It's for getting it to output shorter answers, but also could help with your burnout.
Re: I think I have LLM burnout
#3This 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.
Re: I think I have LLM burnout
#4I 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 write the business logic myself and have the LLM do a lot of the rest. Boilerplate falls into the latter as well.
Re: I think I have LLM burnout
#5I don’t understand what could possibly need to be made so fast that isn’t totally made up billable hours. Running at top speed long enough to be burned out is either ineffective, or valuable enough that someone else can take over while you sleep.
Re: I think I have LLM burnout
#6I 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 the best way to keep AI on track and make those diffs you have to read clean and easy.
An even better way is to use a more strongly typed language and really lock it down, but you can use testing in any language. I feel like my background in TDD and "TATFT" has been secret sauce when working with AI
Re: I think I have LLM burnout
#7It sounds kind of like being stuck working with coworkers who--while not overtly hostile--need constant hand-holding and repeat the same kinds of mistakes every day and can't even be genuinely sorry about it.
Just because we work with computers doesn't mean we don't take, er, social-damage. Or perhaps parasocial damage, in this case.
Re: I think I have LLM burnout
#8Tell the llm to answer like a cavemen, if llm talk like cavemen, the answers become shorter and more compressed. https://github.com/JuliusBrussee/caveman It's for getting it to output shorter answers, but also could help with your burnout.
I surprisingly had good results when I told the LLM to only communicate in ASCII memes. It did a fantastic job of summarizing the situation using relevant memes, and the humor was enough to keep things fresh. As silly as it sounds, it's worth trying when you're in that LLM burnout corner.
Re: I think I have LLM burnout
#9> 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?
Re: I think I have LLM burnout
#10I 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…
I've just been carefully reading the code. It is easy to slip into just accepting what comes out to speed things up, but reading the code is important.
I save myself by skimming things like tests, templates, some UI. Anything cosmetic. But I have to read the majority of code that ends up on my back end systems.