This is one area I do use LLMs for, write small utils and test code, and very often in languages I very seldom even touch, such as C# and Rust. This to me seems to be the core idea of a tool that is awesome at translating!
Is it just me, or should they have just reverted instead of making _another_ change as a result of the first one?
ALSO, very very weird that they had not caught this seemingly obvious bug in proxy buffer size handling. This points to that the change nr 2, done in "reactive" mode to change nr 1 that broke shit, HAD NOT BEEN TESTED AT ALL! Which is the core reason they should never have deployed that, but rather revert to a known good state, then test BOTH changes combined.
If the reticulum code is worse than the meshtastic one, then it is truly atrocious. Been trying to get a specific board to simply "sleep" its radio using meshtastic, and nobody seems to know WHY it doesnt do it. The code is horrible spaghetti with lots of ifdefs. And nobody seems to know why things are the way they are in the code re: power handling. ChatGPT wrote me a brute force method that works, but its ugly and I dont want to maintain patches.
But it is fairly easy to hack on. I have no idea how to debug things without USB serial connected, though.
Sorry, can't really compare because I've never had to suffer looking at meshtastic source code. Quite tempted at this point to just throw the python implementation of reticulum at Claude and see if a validated port to C++ is possible.
Maybe a bit offtopic and not LoRa, but I've been looking at ESP32 and they include an ESPMesh for the WiFi radio with a promise of about 500 to 1000 meters range from what I read. It isn't the same range as LoRa, but it is "larger" bandwidth and for the price of 3 dollars per unit seems promising on urban areas to connect people. I'm trying it out now.
This pretty much sums up my vibe coding experience as well. I have been doing many small pet tool/util projects at work, and after a few thousand LoCs I am always very detached, and have a hard time to see if the LLM is off track or not. At this point I often try to get it to refactor the code aggressively, and especially finding duplicate things.
"Pilots did the heroic thing - they tried to take off instead at 160 MPH to minimize collateral damage (highway and warehouses at the end of the runway) and crash and die somewhere else"
No, they were most likely NOT trying to be heores, its simply the standard thing to do. An aircraft is supposed to be able to take off with one engine inop, and at this speed the expected behaviour is to continue takeoff because that is what has been deemed safest.
There is always a grey area where the decision could go either way, stop or lift off and in this case it looks to me that trying to stop might have been better. But that is literally impossible to diagnose during the few seconds they had.
I really would want a more clever solution for our heating: district heating that goes int our "legacy" high-temperature old radiators, and also a secondary system with under floor heating but with a limited temperature. The problem is the "secondary" system is much bigger and heats most of the house, but is more or less unable to change its temperature since its always "capped" at the max since its driven from a high-temperature system, the shunt can not lower the temperature, also its a dumb one. So we have bang-bang thermostats everywhere for the floors which works, but is not at all optimal.
reply