Code isn’t a binary scale of works or doesn’t - there is inefficient code and insecure code and everything else in between that still technically “works” - but a lack of understanding will eventually cause these “working” solutions to catch up to you.

You can always revisit that part of code if it doesn’t perform. For vast majority of code running on consumer devices there’s no difference between smart implementation and mediocre implementation. LLMs are great at being mediocre by default.

As for security, that mostly stems from the architecture. LLMs mediocracy also helps with following industry conventions and best practices.

In my case I never get the code being written at once, instead I make LLMs write pieces that I put together myself. Never got used to copilot or Cursor, I feel in control only with the chat interface.

Not understanding how Bluetooth works while building a Bluetooth thing seems like… a problem, though. Like, there are going to be bugs, and you’re going to have to deal with them, and that is where the “just ask the magic robot” approach tends to break down.

Funny enough, you already don't have access to low level radio so building a "Bluetooth thing" is just about dealing with some libraries and API.

Bugs happen but its not that different from any other type of bugs. Also, you end up learning about Bluetooth as bugs and other unexpected behavior happen. The great thing about LLMs is that they are interactive, so for example when collecting Bluetooth packets for analysis I ended up learning that the communication with Bluetooth is a bit like talking through a middleman and some packet types are only about giving instructions to the Bluetooth chip and others are actually about communicating with a connected device.

Using LLM for coding something you don't understand is much different than Googling something, then copy+paste a snippet from Stackoverflow because you can ask for instant explanation and modifications for testing edge cases and other ideas.