7 ms·

Someone mentioned "hallucination-based API design" on twitter (I cannot find it now). It's designing API by LLM hallucination. If there is a common hallucinatio

Someone mentioned "hallucination-based API design" on twitter (I cannot find it now). It's designing API by LLM hallucination. If there is a common hallucination API call, just add that API. This will make the API more "friendly" and resemble common similar APIs. Considering that LLM can hallucinate in different ways unpredictably, not sure whether it will work in practice.

sim7c00 2y ago
I doubt LLM hallucinations will produce good secure code. In my opinion, using code from LLMs, which might see your program come to life a bit quicker, will only enhance the time needed for debugging and testing, as there might be bugs and problems in there ranging from trivial things (unused variables) to very subtle and hard to find logic issues which require a deeper knowledge of the libraries and frameworks cobbled together by an LLM. Additionally, it takes out a lot of the knowledge of these things in the long run, so people will find it more and more challenging to properly do this testing and debugging phase.
- IanCal 2y ago
  The description here isn't about using LLM hallucinations as code. It's using them as example API users and seeing what they get stuck on. Let's say you've got some rest API. Are they trying to send PATCH requests but you only support POST? Do they keep trying to add pagination or look for a cursor? Do they expect /things to return everything and /things/id to return a single one but you have /things and /thing/1 ? None of this is to say you must do whatever they are trying to do but it's a very cheap way of seeing what introducing your API/library to a new user might be like. And, moreover, you can only ever introduce someone once but you can go again and again with a LLM. Review the things they're doing and see if actually you've deviated from broad principles and if a change/new endpoint actually would make things much easier. Fundamentally you can break this down to "if there's someone who can do some coding but isn't a top class programmer, how much do I need to explain it to them before they can solve a particular problem?"
  - sim7c00 2y ago
    Ah, sorry, totally didn't get that it was using them as users of the API. I would recommend API fuzzers here, which cycle through all available possibilities, and generate 'garbage' inputs as well as structured inputs regarding the specifications the APIs implement (http, and the underlying structures provided to the api endpoints). an LLM would likely not perform an exhaustive test. There are several projects freely available to run such fuzz tests. Eventhough that does eat up considerable resources, and 'resetting' state during such tests can be problematic at best, the same would apply for LLM based testing. (database gets screwed in some way, and the next request is not on a 'clean' state.)
    - stavros 2y ago
      > Ah, sorry, totally didn't get that it was using them as users of the API. Originally, it wasn't. From the GP post: > If there is a common hallucination API call, just add that API. This will make the API more "friendly" and resemble common similar APIs. If it's just users, you wouldn't be adding the APIs.
      - IanCal 2y ago
        Users were calling their API.
        sim7c00 2y ago
        programs call apis.
        IanCal 2y ago
        This is the silliest argument I write API calls. I am a user of apis. If you want to be more pedantic than this I simply do not care and you should evaluate what benefit you are bringing to this conversation.
        sim7c00 2y ago
netcan 2y ago
Idk if "hallucination-based API design" specifically is The Way. There might be other ways of achieving the same goal. Also,LLM hallucination is changing/improving quite rapidly. That said, "Designed for LLM" is probably a very productive pursuit. Puts you in the right place to understand the problems of the day.
- _xiaz 2y ago
  Adding a couple aliases for your endpoint might be a decent middle ground where you throw the hallucinating "AI" a bone, without contorting yourself at its will
Flop7331 2y ago
Let's all give ourselves extra prosthetic fingers and mutilate our ears while we're at it.
RegW 2y ago
I suppose it would be relying on being trained on code that followed good practice. If this is true then we might suppose that this API isn't following good practice. However, a gigantic feedback loop is appearing on the horizon. The AI of tomorrow will be trained on the output of AI today. (Somewhere in my memory, I hear an ex-boss saying "Well that's good - isn't it?")
Raicuparta 2y ago
You're going at it all wrong. You just need another LLM on the other end of the API too.
Too 2y ago
Internet explorer tried that 20 years ago. Allowing all kinds of errors in the html to just slip through and attempt to do something good out of it, forcing everyone else to be bug-for-bug compatible. Also commonly referred to as the robustness principle; “be conservative in what you do, be liberal in what you accept from others“. An approach that is now considered an anti-pattern, for such future compatibility reasons.
- runeks 2y ago
  Creating a new endpoint that accepts data as sent by the AI-generated code is very different from accepting AI-generated errors for existing endpoints. You're talking about the latter.

sim7c00 2y ago

I doubt LLM hallucinations will produce good secure code. In my opinion, using code from LLMs, which might see your program come to life a bit quicker, will only enhance the time needed for debugging and testing, as there might be bugs and problems in there ranging from trivial things (unused variables) to very subtle and hard to find logic issues which require a deeper knowledge of the libraries and frameworks cobbled together by an LLM. Additionally, it takes out a lot of the knowledge of these things in the long run, so people will find it more and more challenging to properly do this testing and debugging phase.

IanCal 2y ago
The description here isn't about using LLM hallucinations as code. It's using them as example API users and seeing what they get stuck on. Let's say you've got some rest API. Are they trying to send PATCH requests but you only support POST? Do they keep trying to add pagination or look for a cursor? Do they expect /things to return everything and /things/id to return a single one but you have /things and /thing/1 ? None of this is to say you must do whatever they are trying to do but it's a very cheap way of seeing what introducing your API/library to a new user might be like. And, moreover, you can only ever introduce someone once but you can go again and again with a LLM. Review the things they're doing and see if actually you've deviated from broad principles and if a change/new endpoint actually would make things much easier. Fundamentally you can break this down to "if there's someone who can do some coding but isn't a top class programmer, how much do I need to explain it to them before they can solve a particular problem?"
- sim7c00 2y ago
  Ah, sorry, totally didn't get that it was using them as users of the API. I would recommend API fuzzers here, which cycle through all available possibilities, and generate 'garbage' inputs as well as structured inputs regarding the specifications the APIs implement (http, and the underlying structures provided to the api endpoints). an LLM would likely not perform an exhaustive test. There are several projects freely available to run such fuzz tests. Eventhough that does eat up considerable resources, and 'resetting' state during such tests can be problematic at best, the same would apply for LLM based testing. (database gets screwed in some way, and the next request is not on a 'clean' state.)
  - stavros 2y ago
    > Ah, sorry, totally didn't get that it was using them as users of the API. Originally, it wasn't. From the GP post: > If there is a common hallucination API call, just add that API. This will make the API more "friendly" and resemble common similar APIs. If it's just users, you wouldn't be adding the APIs.
    - IanCal 2y ago
      Users were calling their API.
      - sim7c00 2y ago
        programs call apis.
        IanCal 2y ago
        This is the silliest argument I write API calls. I am a user of apis. If you want to be more pedantic than this I simply do not care and you should evaluate what benefit you are bringing to this conversation.
        sim7c00 2y ago

netcan 2y ago

Idk if "hallucination-based API design" specifically is The Way. There might be other ways of achieving the same goal. Also,LLM hallucination is changing/improving quite rapidly. That said, "Designed for LLM" is probably a very productive pursuit. Puts you in the right place to understand the problems of the day.

_xiaz 2y ago
Adding a couple aliases for your endpoint might be a decent middle ground where you throw the hallucinating "AI" a bone, without contorting yourself at its will

Flop7331 2y ago

Let's all give ourselves extra prosthetic fingers and mutilate our ears while we're at it.

RegW 2y ago

I suppose it would be relying on being trained on code that followed good practice. If this is true then we might suppose that this API isn't following good practice. However, a gigantic feedback loop is appearing on the horizon. The AI of tomorrow will be trained on the output of AI today. (Somewhere in my memory, I hear an ex-boss saying "Well that's good - isn't it?")

Raicuparta 2y ago

You're going at it all wrong. You just need another LLM on the other end of the API too.

Too 2y ago

Internet explorer tried that 20 years ago. Allowing all kinds of errors in the html to just slip through and attempt to do something good out of it, forcing everyone else to be bug-for-bug compatible. Also commonly referred to as the robustness principle; “be conservative in what you do, be liberal in what you accept from others“. An approach that is now considered an anti-pattern, for such future compatibility reasons.

runeks 2y ago
Creating a new endpoint that accepts data as sent by the AI-generated code is very different from accepting AI-generated errors for existing endpoints. You're talking about the latter.