Show HN: We're tired of LangChain and you are too, so we built Mirascope
github.com
github.com
re: scope:
I think anything one layer above the base provider API is definitely in scope. A lot of these APIs are autogenerated (e.g. stainless), so I see a lot of value in building language-specific tools (starting with Python, likely JS/TS next) to improve developer experience at this single step up layer (e.g. tools, structured outputs, state across calls, streaming, etc.).
I care deeply about cutting the amount of time people have to spend on things that ultimately aren't the value adding aspects of their work (like maintaining an internal tool), and I think the (coming soon) future of AI-native applications will need this more than ever. Essentially anything that could be considered boiler-plate or unnecessary repeated code is something I want to improve without removing/reducing control and transparency -- I want to build useful abstractions that aren't obstructions.
I also thing it's important to do this through a provider-agnostic interface given how frequently a new "king" pops up.
re: long-term vision:
more support for various providers/models + tools and agentic flows are definitely top of mind here, but to be honest I'm not fully certain what this AI-native future looks like, so I'm keeping an open mind about where to direct efforts. I'm hopeful usage and feedback from building in the open will help further guide this process.
How will this framework handle tuning the prompts in a task specific way?
There's nothing stopping you from tuning the prompt in your prompt template to a specific task, and if you want to further tune to a specific model, that will still work, so I'm a bit confused and would love to better understand
The interaction flow and the model being used for that flow should be a dynamic construct, not a static one.
Lets say you have 10 different ways you could perturb a prompt and some of those are pathological, meaning extra punctuation or the lack of a newline gives non sensical outputs. How would I "rewrite" my application to account for that when changing a model?
Given that new models are coming out so quickly, what affordances does your framework have in targeting the same application at a different stack of models?
1. How necessary is it to engineer a prompt for a specific model vs. build with the expectation that models will get better and better and require less and less engineering.
If the former is the most important, then there's nothing really to do here. The tool you're using should make it easy to use any provider you want with minimal effort / change, but the model/provider-specific prompt engineering will still be up to you. This would be best supported through a second layer of abstraction that sits on top of something like Mirascope. For example, a tool for automatically re-engineering a prompt for a specific model. Or perhaps versioning tooling to make it easy to take a snapshot of a prompt that's been engineered for a specific model and compare it to another snapshot for another prompt/model.
If the latter is true, then the most important aspect here is to make using and swapping between any and all providers extremely easy. I think we've done a good job of making this possible with Mirascope without taking away the control necessary for the former.
2. Static vs. Dynamic constructs.
We spent a lot of time supporting both static and dynamic flows. For dynamic flows (i.e. dynamic configuration), the configuration object is tied to the model on purpose. For example, if you want to write your own custom messages array (perhaps to take advantage of a model-specific feature), you can do this at the expense of losing provider-agnostic support.
I think these things are really important to think about and keep in mind as we continue to develop, but I think they are issues to be handled separately from (or in addition to) purely improving the ergonomics of calling LLM APIs.