It's generally and simply an encoding of what amounts to binary machine code which you translate via assembly code acting as a deterministic compiler from assembly to machine code if you are doing it manually.
LLMs aren't a deterministic process and human languages aren't as clear as machine code and assembly.
I remember! You created a control card, with tab stops and other controls, wrapped it around a control drum, and then had an easy time punching your source FORTRAN!
I just looked and found my old control drum, in the back of my junk drawer. But I can't find an old punch card machine in there, most have lost it somehow.
I've never programmed before good compilers existed, but I still know some assembly. For what I currently do it's used rarely, but it's still quite valuable on occasion. I don't see any reason LLM-assisted programming wouldn't be like that; for sure the various C compilers sure seem like they're trying just as hard to produce results you don't want.
If I transported you to the 1960s and gave you a wizard that could punch cards for you with a chance of making a mistake, would you still bother to learn how to operate a punch card?
What would you do if the wizard gets stuck? Coarse the wizard into making the black box work through somebody else's direct perspective on the problem?
It's more like a restaurant. You give an order and a little while later, a finished dish appears.
The difference between a Chipotle and a Michelin starred establishment is that Chipotle is just assembling a mass produced good. A Michelin chef knows their ingredients inside and out; knows the science of how those ingredients work; knows varied techniques to extract flavors, create textures, etc.
Anyone can work in a Chipotle; few can achieve a Michelin star.
Is this a serious question? If you are handling sensitive information how do you confirm your application is secure and won't leak or expose information to people who shouldn't know it?
Exactly.... -> Unit tests. Integration tests. UI tests. This is how code should be verified no matter the author. Just today I told my team we should not be reading every line of LLM code. Understand the pattern. Read the interesting / complex parts. Read the tests.
But unit and integration tests generally only catch the things you can think of. That leaves a lot of unexplored space in which things can go wrong.
Separately, but related - if you offload writing of the tests and writing of the code, how does anybody know what they have other than green tests and coverage numbers?
I have been seeing this problem building over the last year. LLM generated logic being tested by massive LLM generated tests.
Everyone just goes overboard with the tests since you can easily just tell the LLM to expand on the suite. So you end up with a massive test suite that looks very thorough and is less likely to be scrutinized.
if you are asking me how you *guarantee* there is not a single possible exploit in your code, you can't do that. But you can do your best and learn about common pitfalls and be reasonably competent. Just because you can't do the former doesn't mean the latter is useless.
If you mean things like Shizuku or local adb connection through Termux, it's quite an awkward process to set up even for someone like me who's been building Android apps since 2011. Like, you can do if you really really need it, but most people won't bother. You have to do it again after every reboot, too.
People who want your money always want to have really great UX. I remember how painless buying lottery tickets online was, it was the smoothest checkout experience in all of online shopping I have ever done.
Sorry about that. I'm new here and English isn't my first language, so I leaned on tools to help me phrase things and it ended up looking like a bot. Lesson learned-I'll stick to my own words from now on. The point is real though. I've actually been building a multi-agent system and that separation between coder and reviewer is a game changer for catching bugs that look fine on the surface. Anyway, won't happen again.
