We have a bit of context about this in the readme: https://github.com/lastmile-ai/aiconfig#what-problem-it-solves https://github.com/lastmile-ai/aiconfig#what-p

We have a bit of context about this in the readme: https://github.com/lastmile-ai/aiconfig#what-problem-it-solves https://github.com/lastmile-ai/aiconfig#what-problem-it-solv.... The main issue with keeping it in code is that it tangles application code with prompts and model-specific logic. That makes it hard to evaluate the genAI parts of the application, and also iterating on the prompts is not as straightforward as opening up a playground. Having the config be the source of truth let's you connect it to your application code (and still source controlled), lets you evaluate the config as the AI artifact, and also lets you open the config in a playground to edit and iterate. For example, compare how much simpler openai function calling becomes with storing the stuff as a config: https://github.com/lastmile-ai/aiconfig/blob/main/cookbooks/Function-Calling-OpenAI/Function_Calling_with_OpenAI.ipynb https://github.com/lastmile-ai/aiconfig/blob/main/cookbooks/... vs using vanilla openai directly (https://github.com/openai/openai-node/blob/v4/examples/function-call-stream.ts https://github.com/openai/openai-node/blob/v4/examples/funct...)