A lot of people start using the Replit agent and believe that because it’s a no-code solution, there is no learning curve. This is not true. The fact of the matter is that the agent will implement your solution based on its understanding of your primary needs. As such, one of the things you absolutely need to learn is what the solution framework can and cannot do.
If you find yourself $100 deep into trying to force your application to do a particular thing, it is possible that the framework the agent used at the beginning, when you initially gave it your prompt, has reached its limits. A good way to see if this is true is to start a new Repl and try to create that feature in the same framework, where the agent doesn’t have a bunch of context to confuse it. Another thing you can do is look up the framework online to see if what you want to implement is even possible within that framework.
Let me give you an example, and this is the real reason for this post: if your application needs multiple users, do not let the agent implement Streamlit into your solution. It took me so long to figure this out, and I had to go deep into the Streamlit community to learn what was happening. It required me to change my initial prompt to prioritize users first and then build the statistical functionality after the initial prototype was created.
Basically, the most important features matter, and you need to figure out what those are and put them at the forefront of your initial prompt, leaving the less important features to be implemented afterward. On top of the framework the agent chose, it’s also a good idea to research different frameworks and see what their strengths and weaknesses are. That way, you can dictate to the agent from the beginning what framework to avoid and what framework to implement your solution on.
I second this. My system broke down after 3 weeks, it moved from next.js to express even though it was already using express, and back and forth and now its completely unbootable. I need to figure out what the hell it did and its completely bricked. I’m tired so I’m stepping away for a week and I will either start from scratch with a totally different prompting approach, which might be faster, or try to fix the mess and try to recover 3 weeks of good progress over some stupid server changes.
Here’s one thing that I found absolutely amazing and might actually help you at this point in time: did you know you can run three or four different replits at the same time? This means instead of trying to build your solution in one agent session, why not stretch it across three? That way, the mistakes you make in one can be learned from, and you can immediately try again with another one and another one.
You’d be surprised how far the initial prompt can take you if it’s formatted properly, backed by a lot of experience with other field versions of the same project. It might feel like you’re going back in time and have sunk a lot of effort into one particular solution, but the effort isn’t really lost when you start over with all that knowledge. You might find that it’s the only way to really take it across the finish line.
Yes I got the system to import and load 800,000 unique diamonds and we have a search an sorting system that would pull diamonds based on various attributtes, it was making good progress but I just hit a wall. Are you saying fork the repl before trying too many major changes? I’m trying to plan my rebuild after I take a break but I’m working on a good plan and fallbacks for when we can no longer reverse changes.
You know, I never thought about forking the repl. That’s a good idea. What I was really saying was to launch three variations of the solution you’re trying to build, based on three different interpretations of what it could look like, and develop them simultaneously.
For instance, I wanted to create a prompt builder. So, I did one version where the user logs in, emphasizing that the system will have users who can save, edit, and share their prompts. Then, I have another version that focuses on how I want AI to actually help users build their prompts and the different stages involved in putting together a prompt, combining all of that to make an output. Finally, I have one that deals with using a database to store different variables and then combines all of those variables in a seamless way, reinterpreting them into a new prompt.
So, you basically get the idea. You envision three different versions of the same solution and build them together to see how they interact. Then, you can start one where you bring them all together into one major solution once you have a good grasp of how you want it to look, how you want it to behave, and the different problems each might present.
I’m just saying, don’t be limited by trying to get it right in one repl from the start. Realize that repls are cheap and disposable, and you can create as many of them as you want to develop a solution. That way, you don’t get stuck becoming attached to one and then spend a lot of money trying to fix it.
Yeah we are having to get creative to work around the limitations, this might not be an issue in 6-12 months but for now that’s what we probably have to do. I didn’t think about forking in time so now I’m stuck fixing my system, but if I get it working again I will pause, fork and then bang away on the other version, its like a forced full system checkpoint, the checkpoints only work within the chats so its dangerous if you end up ending it and make a mistake.
I have an update, after combing through things I figured out it was using express for some of the backend and next.js for the front end which caused issues when I asked it to build an analytics platform that tracks clicks, views and other actions on the site, it was a disaster. I went through iterating and did not realize I was digging a bigger and bigger hole and eventually could not revert. I am in the process of removing all the features, removing express and moving the paths to next.js and going to keep using that, I will let you know if it works out, I was able to get the front end to come back up for a few, so there is still some hope.
Yes and they run simultaneously too… Oh to be clear its also multiple projects … So I’m building the same app but across multiple projects … The simplest explanation of the benefit of doing this is that one of the 3 has a greater chance of getting to the finish line lol … But on a serious note very slight changes in the prompt will cause the agent to do very different things in the implementation and it will give you lots of ideas and insights
I like this method though, if you are willing to burn some cash it would really allow some risk free iteration and you can then transfer some of that code over if it works to the other project, not a bad strategy. To update on my problem, I managed to get some of the code working again and the server is half back up, some backend stuff I still being fixed but there is hope. I will share more later this week, wife and I are going out tonight and honestly I need the break lol.
@hypler Absolutely take the break! Also I don’t even consider it burning cash, because I end up finishing the solution in under $20 most times and that’s across all iterations. Before I used to do this it would cost me $50 to $100 to get something half decent that would break at the finish line and I’ll have to scrap it anyway. It only seems like burning cash on the surface lol
Are you using a vector database? What kind of embeddings are you using? 800,000 seems like a reasonable number data elements. We’re not talking multiple petabytes are we. And are you doing some kind of recommendation engine?
nothing link that at all, financial tracking for a family trust… needed multiple users with roles and no possibility of a data leak, streamlit was the wrong choice for that application, i learned that after.
One of the downsides of Streamlit I am now experiencing is that is horrible at SEO. Simple things like google analytics tags are not possible. I love the easy and vast visualizations but tough to use in a SEO facing world.
… But on a serious note very slight changes in the prompt will cause the agent to do very different things in the implementation and it will give you lots of ideas and insights