A request in Prototyper can be recognized correctly by Gemini and a great plan can be prepared. However, while writing the code, it can make unintended changes based on past conversations without being faithful to this plan. Since some of these changes are functional rather than design, they can be overlooked. People who do not understand coding may not understand whether the changes are correct or not by looking at the code. Therefore, it would be very good if he analyzed what changes he made in the code after he finished writing the code and wrote down what he did.
This is one step further: An agent can be created that analyzes the changes it makes in the code, evaluates whether it is faithful to the plan or the request, and automatically corrects them again if it has made unwanted changes. Or a system can be set up to ensure that the code is written in a way that is faithful to the request and the plan. Gemini in the Code area does a better job, especially when it comes to sticking to the prompt and plan. Prototyper should be like that.
One more suggestion: if a prompt is to be implemented with less influence from past conversations, there could be a button to stick to the prompt. Or how much to stick to the prompt and ignore past conversations could be proportionally adjustable for each prompt. I think these would help Firebase Studio to be more consistent.
I created airules.md but it seemed to work in Gemini in the Code section, not in Prototyper. Could it be that GEMINI.md works the same way only in the Code section? Were you able to determine if it works in Prototyper?
I haven’t validated whether GEMINI.md works in Prototyper, but from what I’ve read from the Google Firebase Studio team, it should. Try this: try prompter the prototyper to tell you about the GEMINI.md and ask what file determines it’s roles and responsibilities. It should correctly identify the GEMINI.md file as it’s mandate.
I wonder if these suggestions we write here are taken note of and evaluated by the Google team. If it is being evaluated, at least with a message or a like, we would feel that what we write is not wasted and this would encourage us to give more feedback.
Wishful thinking. It has been demonstrated for months on these forums that there is little community support for this project from Google as a whole. I have seen @kirupa@jamesor and @tianzi put in effort here, but clearly this isn’t satisfactory from our user perspective, as these three are likely already busy enough.
ya, it seems like this forum is more utilized as a place for people to have one off issues rather than actually provide community feedback and engagement.
I just encountered a repeated bug, usually when I’ve come across that in other products, I would submit something to the forum. But with Firebase Studio, I feel like the answer is always “we’re aware, we’re working on it” so it seems pointless to mention it. And since there is the Firebase Support ticket, it feels confusing if I should be putting things like that on here where it seems like it might slightly get seen and I could be a part of the community; or to just submit a ticket that feels like will float in the ether.
If people prefer to write their problems here instead of sending tickets, I think they should take this into consideration. We’re talking about Google, a huge company with hundreds of thousands of employees. I’m sure Google can assign many more people if they want to.
I hope that this place will become a place where more attention is paid, and problems are solved and updates are made more quickly.
We need to point these things out so that they see that there is such a need and do something accordingly. I think that if more people speak up, it will be considered more.
@bevren15airules.md and GEMINI.md both work with the App Prototyping agent, but remember to rebuild your env. See step 4. However, keep in mind that these two files are designed to work with Gemini in Firebase, not the App Prototyper agent. The reason that the App Prototyping agent behaves like it’s using these files is because it reads all the files in the workspace as its context.
The documentation is very helpful, but some of the troubleshooting steps are out of date. Here’s an example where “Reset” is mentioned in the documentation, but it doesn’t exist:
Thank you, @dms - it looks like Reset got changed to Restart. I can update the documentation. Definitely let us know if you find anything else out of date!
Thanks to your presence and your interest I am continuing with Firebase Studio to bring it to a better point. There are many mistakes and shortcomings but it is promising. As long as your presence is strong, it becomes bearable. I hope your presence in the Community grows even stronger and that Google pays more attention to Firebase Studio.
The few messages I wrote in the comments of this topic are actually things that should be opened as a topic in itself, but I am sure you have read them and I hope they will be taken into consideration. Thank you for your efforts. I’m glad you’re here.
Faithfulness is still an issue. My website was developed with 50% featurs properly working. When i try to add other independent feature the AI destroyed the previous UI and backend and features.
Until Prototyper is fixed, it seems to make the most sense to use Gemini CLI. Prototyper is much nicer and more fun to use, but it’s easier to revert an erroneous change in Gemini CLI and it doesn’t change anything unnecessary. So it is much more consistent. I hope these features will come to Prototyper. With AI evolving so fast, I hope Firebase Studio will quickly catch up.
