Teach Wasp AI to use Wasp starter templates (or parts of them)

[Martinsos]

It would be a big deal if Wasp AI (Mage) could use the starting templates, for example using open-saas. Or parts of those. Right now, it has its own very basic starting template it uses and it relies on it. Using other templates would require a change in how Mage works, so this could be quite an undertaking, since this part is now quite hardcoded.

[Martinsos]

Mention of it here: https://github.com/wasp-lang/wasp/issues/1420#issuecomment-2040997956 .

[cocobeach]

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. :)

[Martinsos]

@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).

[cocobeach]

@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.

[cocobeach]

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.

[Martinsos]

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.

Ok this is a wild idea :D! I am not sure I am picking it up completely: you are suggesting we make a new Wasp app (potentially using open-saas) that is basically a visual editor where you can create Wasp apps by choosing building blocks and connecting them together? If so, yeah that makes sense! A visual builder for Wasp apps. This is something that could indeed be monetized likely, and makes sense as one of the steps to take in the (a bit further) future!

[cocobeach]

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.

Ok this is a wild idea :D! I am not sure I am picking it up completely: you are suggesting we make a new Wasp app (potentially using open-saas) that is basically a visual editor where you can create Wasp apps by choosing building blocks and connecting them together? If so, yeah that makes sense! A visual builder for Wasp apps. This is something that could indeed be monetized likely, and makes sense as one of the steps to take in the (a bit further) future!

Pretty much yes, why reinventing then wheel and build another interface when you app builds interfaces automatically and is already modular, second leg would be: why having the AI build a simple script with barely nothing in it, when it can start on the basis of an already existing SAAS? Let me know if you want me to alpha test something for you.

[cocobeach]

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.

Ok this is a wild idea :D! I am not sure I am picking it up completely: you are suggesting we make a new Wasp app (potentially using open-saas) that is basically a visual editor where you can create Wasp apps by choosing building blocks and connecting them together? If so, yeah that makes sense! A visual builder for Wasp apps. This is something that could indeed be monetized likely, and makes sense as one of the steps to take in the (a bit further) future!

Pretty much yes, why reinventing then wheel and build another interface when you app builds interfaces automatically and is already modular, second leg would be: why having the AI build a simple script with barely nothing in it, when it can start on the basis of an already existing SAAS? Let me know if you want me to alpha test something for you.

*I sent you a DM on discord to show you what I am doing and how we could tie up both things together.