But the real savings? Repetitive code. I suck at it, I always make typos and it’s draining.
It’s hard to say without being immersed in the codebase you work on, but wouldn’t making your code DRY (when possible) take care of a lot of the repetition without needing to write a bunch of incredibly similar code (be it by hand or with an LLM)?
I haven’t used a LLM to help code in a while (yes I’ve tried), but I found them useful for repetitive configs, like asset files. Also sometimes it makes sense to just have 5 slightly different lines of code in a row instead of a new function.
In general though, reasonable use of DRY is a good idea. There will still be repetitive parts though where a LLM autocompleter lets you just hit tab 5 times.
No, it’s all different - like a normal use case is “write me a stored procedure to optionally update all fields on a row on this table” or “given the following json response, build a class to parse it into”
We have a ridiculous database and multiple new api’s to integrate with every year, so this comes up a lot
It’s hard to say without being immersed in the codebase you work on, but wouldn’t making your code DRY (when possible) take care of a lot of the repetition without needing to write a bunch of incredibly similar code (be it by hand or with an LLM)?
I haven’t used a LLM to help code in a while (yes I’ve tried), but I found them useful for repetitive configs, like asset files. Also sometimes it makes sense to just have 5 slightly different lines of code in a row instead of a new function.
In general though, reasonable use of DRY is a good idea. There will still be repetitive parts though where a LLM autocompleter lets you just hit tab 5 times.
No, it’s all different - like a normal use case is “write me a stored procedure to optionally update all fields on a row on this table” or “given the following json response, build a class to parse it into”
We have a ridiculous database and multiple new api’s to integrate with every year, so this comes up a lot