Repl.it: A Fast Start with a Frustrating Finish – My Mixed Experience with Three Projects

I have completed three major projects using Repl.it, all based on familiar environments. My experience has been mixed. On one hand, the platform is excellent for quickly gaining first impressions and rapidly achieving results. On the other hand, working with Repl.it becomes frustrating, tedious, and expensive as soon as errors start appearing.

A major issue is the lack of a stable context for the application. The system makes changes—often unnoticed—at points in the code that only become apparent much later. When fixing these errors, I discovered that entirely different sections of the code had been unexpectedly removed or restructured, rendering the application unusable.

Undoing these changes is only partially helpful since it’s difficult to pinpoint when and where key parts of the program logic were altered. This becomes even more problematic when using the assistant, as it seemingly resets with each interaction.

A potential solution would be introducing a persistent context that remains intact throughout development. Ideally, this would not only be stable but also adaptive—allowing new functions to be added without unintentionally altering existing logic.

At least two of my three projects were thoroughly prepared and well-documented, both in execution and technical design. Yet, I have rarely encountered a platform that initially provides such positive feedback, only to cause hours of frustration later over simple details—like handling URL names.

Ultimately, this is just my personal experience, and I’m still unsure how to improve the process. Perhaps I’m making mistakes myself.

14 Likes

Yes, very fair. I agree with you that managing the context limitations of the system are a key ‘pain point’, especially when projects move beyond the initial prototype stage. I had some success with that by implementing a changelog and having the agent read from and write to the changelog at the start/end of conversations. I wrote a post about it here on the forums if you’re interested. But, a) it doesn’t fundamentally address the limitation you are describing; it just moves the high watermark a bit higher, and b) I am sure you are already familiar with that, as you seem to be a much more experienced maker of software than myself! (I am a complete amateur).

Really hoping the memory/context situation will improve in subsequent updates. That would really unlock a whole new level of value for agentic coding! Cheers

5 Likes

i made a post about something i think could be done to fix this, Cursor and Windsurf have teh concept of .rule files which are perminant items you can add to the prompt. I think telling the agent to NOT make db changes, to NOT fix problems it finds along the way, and to JUST focus on instruction and features asked about would be good, and to always ASK what do to when a major bug or regression in system has occured. Currently, when it’s trying to fix things it often goes into a loop and messes everything up!

I have also started making my git markers before starting new functionality. It would be nice to do this too, as the current checkpoints are only after the system has done something. I want to be able to do it BEFORE it does something, especially important if you’ve made manual changes since the last agent checkpoint. You’re pretty much stuck to revert then.

I think with some small enhancement the system could be made to be much better.

4 Likes

Agree, I have found without the context changes are made that weren’t asked for and “break” the app. I have started over several times because of these issues. My tricks are, save on Github often, after any major changes are requested I check all the functionality before going on to the next thing (a pain and time consuming but saves time in the long run). Also, make sure to roll back quickly if they are making changes that break things.

3 Likes

Identical experience here. You get 80% done with a few prompts. Then, the last 20% takes $200 worth of AI credits and 5 days of complete aggravation.

Almost not worth it. Almost.

9 Likes

Hey I am curious if you care to share more about the project. Especially the most frustrating one. I would love to see what types of problems you are facing and maybe I am able to help troubleshoot!

Thank you for the feedback, especially the point that one must also take responsibility. For example, I find the idea of having assistants read log files very good. That is certainly something that could be implemented by the manufacturer themselves, just like these rule files. Yesterday, I was somewhat frustrated because practically all the work from yesterday was in vain. It is theoretically correct that one should test the entire system after every small change. Fundamentally, such an approach is certainly correct, but it would be nice if modern software didn’t have to operate this way. Due to the fact that an app actually generates many static HTML files, there were problems yesterday. And while I was working on solving another problem with the app, it practically destroyed all the HTML components underneath over a long period, and I didn’t notice it directly. Of course, this can somehow be processed again, but it is not easy. Among other things, because the automatic versioning in Repl.it works, but if you can’t even assign a name, you only have 70 different points to revert to. That is not particularly efficient.

I admit that I am somewhat frustrated and influenced by this experience. I must say that I don’t think Repl.it’s business model suits me. Ultimately, the more frequently the system encounters even very minor HTML errors, the more endpoints it creates—causing me to lose money while the company profits. I don’t believe it’s a good business model if poorer software results in higher earnings. I actually find the basic idea behind Repl.it very sensible, and it is probably not intended that way, but it certainly feels like it.

4 Likes

That reassures me that you experience the same way!
I thought it was just me and that I was too stupid to get the last 20% of my projects done. The euphoria is immense at the beginning when the core functions work, but as soon as you go into more detail and want to correct individual errors, the agent and assistant get bogged down

3 Likes

After seeing a bunch of similar frustration, I decided to share my workflow with pretty high success rate.

Hope you find it helpful :

3 Likes

Hello, thank you for your contribution. I believe this is the right approach. I have also taken someone else’s advice into account and ultimately had the assistant describe the entire software project to me again. I will save this description as a log file and update it regularly.

The idea of working with different Repl agents to keep things from getting too complex also makes a lot of sense to me. I am quite concerned that merging functions from two Repl agents, which rely solely on the codebase, could result in a complete mess. Especially when it comes to HTML templates, they tend to either be reset to zero or reduced to the smallest common denominator – which can be very minimal.

Thanks again for your feedback!

2 Likes

I agree completely it is almost unbearable to really use for any production / real life solution as it handles errors by making changes not requested based on earlier coding issues.

3 Likes

Almost is very Fair.

I’m $250 in and it broke the server at the end and I have been pulling my hair out fixing the removal of next.js per its recommendation and now express issues. Now nothing works so that’s nice. I’m almost done with the whole platform its just not ready.

2 Likes

So, after the first three updates following your initial prompt, I would recommend that every future update be split into two types. The first is a major update that requires significant additions to the webpage database or the application’s logic structure. The second is a simple update that only requires changes to the structure of a single page or function.

For the second type of change, you should exclusively use the assistant to handle it, only involving the agent when the assistant cannot complete the change due to extensive contextual tracking. I have found that this often happens to me because I try to make too big of a change in a single prompt.

The second technique I recommend you employ immediately is checking the progress window anytime you’re going to make a change. The agent will inform you of all the pages it will modify, and the assistant will do the same. Check these changes, pages, and functions they are updating before committing to a particular update. There have been many times when I caught errors before they appeared just by checking these logs. In the case of the agent, I was able to quickly undo a change and try again with a slight variation of the request based on the error I noticed in its logic.

I think these two strategies will help you a great deal. Essentially, they make the beginning of your project not as fast and easy, but they cap the complexity and frustration you will feel as the project progresses. You give up the easy start for a slightly more challenging beginning that maintains the same level of difficulty all the way to the end. As a result, you avoid the infuriating and almost impossible drag across the finish line.

Another thing that has saved me a lot of time is having conversations with the assistant about the changes that were just made. If I don’t understand why the agent is making a particular change to a page or function, I will copy that into the assistant and ask it to explain the logic behind the change to me. If I don’t agree with the logic, then I will not commit that change.

Also, those conversations with the assistant are free, so you can have as many as you like. It’s better to measure and work through the logic five times for every commit than to commit and start building on faulty logic, only to run into errors later when you have no idea where the issue started.

Finally, if you find yourself deep down the rabbit hole with errors that seem to be self-replicating and cascading out of control, bring ChatGPT into the loop. Copy over your errors and your code, and painstakingly work through them with ChatGPT to figure out what’s going on.

Ultimately, do not be afraid to start over from scratch. I cannot explain how many times I have reached $50 into creating an application where 40 of those dollars were spent trying to fix a single error. When I just gave up on the project and started over with a fresh initial prompt that took into consideration all the frustrations I had been dealing with, the agent implemented everything flawlessly on the first try. So basically, what took me $40 to unsuccessfully resolve was fixed in 25 cents.

I know this is very hard because once you invest a lot of time and money into a project, it’s hard to just give up on it. This is expected because of the sunk cost fallacy that affects all of us as human beings. But trust me, sometimes it’s better to just cut your losses and start over.

I hope this helps. Let me know if you’ve been doing any of these things already.

3 Likes

I am coming to the same conclusion, that I will scrap the code I have, start over knowing what I know and write a detailed plan on how I want my system to work. I got it working 60% functionally and pretty well, but I think I spiraled in the end and the time going in circles actually bothers me more than the money. I am going to take a week off and start over with a clear head, full weeks sleep and goals for each session and not make any changes tired or frustrated.

2 Likes

In the meantime you could start up test replit and just try to oneshot prompt the agent to make the feature that broke your solution as a stand alone app. Or something like this, so you can zoom in on it alone and how it should work.

2 Likes

Same here. It’s been challenging to go from 0-1 in Replit. The costs become too high and the delays make it unenjoyable

Same experience here, I‘ve decided that it is too early for something like ai code development so i‘ll be waiting some months until I try again. It definetly isn’t ready yet,
imho.

1 Like

Thank you so much for the wonderful help and ideas!!!

Especially the hint to start again.
I would try to have the current software described by the wizard and then make a new replit from it.
I hope I can find a good prompt for a documentation that provides the Replit agent with all the information next time.

2 Likes