I also notice the exhaustion. That's probably why they vibe. The code is so verbose and appears so fast, that they just give up on even looking at it.
Of course, that means that the possibility for error and inefficiency goes way up. I keep finding duplicate code, that snuck in. I didn't notice, as it was exactly the same function, but in a different file. Then you fix a bug in file #1 and go nearly crazy because it doesn't get fixed everywhere.
Yo, I feel ya! That code fatigue hits hard, right? 🤯 But for real, how do you keep track of all those sneaky duplicates? Got any tips for spotting them before they drive you up the wall? 🕵️♂️💻 #CodeLife #DevStruggles
It's better when you write tests first.
My copilot-instructions file says "**TESTS ARE SACROSANCT.** NEVER modify them without explicit permission from the developer."
Then the tests give me more confidence in the generated code, though I still need to manually intervene at times.
The thing is, everyone hates writing tests.
The other thing is, if you're careful, you can write tests faster with LLMs.
unit tests, sure, integration tests are a lot more fiddly. and tests that are several units down the line in a composition of units tends to get pretty funny as well, that place between unit and integration, formally doesn't have a name but you often still find bugs after the small tests pass but then you built those into more things and oh there's a bug back here.
i'm extremely skeptical that there is a broad use case for LLMs in software engineering. the two most useful things, that even also still fail to actually grasp the semantics, is writing commit comments. even there i find it doesn't work more than 2 times out of three.
handy for people working in a company where strict formalised procedures are tediously demanding, and the superiors accept the half assed LLM generated commit comment, but they don't satisfy me, and the LLM doesn't get what i did half the time, i mean. if i end up having to spend more time watching the thing doesn't make mistakes the drain on one's capacity for attention makes it a dud. i did it in less time, but then i needed to go and touch grass for the next two days, with a vodka and tonic in my hands lol.
Yeah, I totally burnt out, after a few days, and just now got back into the driver's seat.
Felt like my brain got fried.
This gets into different schools of unit test development.
Personally, I ascribe more to the Detroit school, which holds that test isolation refers to isolation _from other tests_. I try to write tests that treat the system under test like a black box. All I care about are the inputs and outputs of the system's public API. When you don't test all the internal units, you catch more of those tricky bugs that show up at the boundaries between different units.
The larger you make the "unit", though, the harder it is for LLMs to write effective tests.
The tests are written faster, but I've twice scrapped the unit tests it wrote because they were rather useless tests.
Yeah you have to give the LLM _very_ careful instructions to make sure it writes useful tests.
I always have it write up a test plan, then I edit that manually before turning it loose.
