Teach Wasp AI to use Wasp starter templates (or parts of them) about wasp HOT 8 OPEN

Mention of it here: #1420 (comment) .

from wasp.

suggestion (as a follow up to the other thread) : Maybe the way to go would be to expose some specific endpoints and create an ecosystem for users to pre-build components on the basis of a (compatible - strict) given scheme, after testing the pre-builds, could go into a structured prompt that inserts them into the architecture leaving the ai to deal with only the moving parts. IMHO the best use for the AI is to change the interface and generate images, whereas we should leave anything development as modular as possible so to leverage form the existing wasp framework?
In the same vein, as much as I don't feel I can go and fiddle with the Haskell core and recompile just to change anything in the wasp-cli/ai app, because I will break stuff more than do anything useful. But I would feel better about creating independent components as a user, that can then be reused in the wasp ecosystem, through the AI high-level orchestration, and iterative look and feel changes?
Let me know if it makes any sense. :)

from wasp.

@cocobeach I think I get what you mean! We would ideally have an ecosystem of "building blocks" that then AI could use to build the codebase.
That sounds great! And we have something in plan for providing those building blocks, we call it full stack modules, it is on the roadmap but will take a bit of time to get there, and that would be a good foundation for this I think.
What is the hardest part here is that this would require refactoring our Wasp AI to be somewhat smarter -> well, to be more like other code agents, in the sense that it has some more freedom. Right now, we are keeping it quite guided, which gives it it he ability to generate apps so quickly and cheaply that actually work, but which means it lacks in flexibility to produce more complex stuff.
So this combo of building blocks + more flexible code agent (AI) certainly sounds like the direction to go. We might also want to look into leveraging some existing code agents / AI for this hm (Aider is always first on my mind).

from wasp.

@cocobeach I think I get what you mean! We would ideally have an ecosystem of "building blocks" that then AI could use to build the codebase. That sounds great! And we have something in plan for providing those building blocks, we call it full stack modules, it is on the roadmap but will take a bit of time to get there, and that would be a good foundation for this I think. What is the hardest part here is that this would require refactoring our Wasp AI to be somewhat smarter -> well, to be more like other code agents, in the sense that it has some more freedom. Right now, we are keeping it quite guided, which gives it it he ability to generate apps so quickly and cheaply that actually work, but which means it lacks in flexibility to produce more complex stuff. So this combo of building blocks + more flexible code agent (AI) certainly sounds like the direction to go. We might also want to look into leveraging some existing code agents / AI for this hm (Aider is always first on my mind).

Well it's funny you should mention that, I have been looking at 2 frameworks lately, both quite promising and departing from the usual UI of the "devins".

1. Is SWE-Agent a quite serious Princeton package that works directly in your repo using the issues as initial prompts and preparing the commits: https://github.com/princeton-nlp/SWE-agent
2. A second one I have discovered lately, has a broader scope but you could potentially use its rich CLI to work with wasp quite seamlessly: https://github.com/plandex-ai/plandex.

from wasp.

BTW I love the wasp studio for visualisation and it gave me an idea related to the building blocks above:

From what I understand creating an opensaas, as an example of top level wasp-app, gives the ability to create from within the opensaas application a nested wasp:new application, correct?
So what would look almost natural is that the top level created opensaas would actually be the interface where you orchestrate said building blocks and generated nested apps ( that could be tested and fine tuned by user in the very saas and potentially to be downloaded by the user after making a stripe payment.
In a use case where you generate bespoke saas for your customer, we can almost automate the building of their apps with blocks and use stripe for a systematic pricing block by block on an "on demand basis" (like ticking boxes in a data frame with all the building blocks "a la carte" or "pre-made bouquets" of various blocks working together for existing use cases), the top level app becoming the ecosystem of your building blocks, like a marketplace. This could make you cross-monetise your ecosystem as opposed to the usual opensource code dilemma community vs paying while you work for free.
Your framework becoming easily monetizable for all sectors potentially, could boom faster.

from wasp.