I NEED a tip to prevent aliasing of db field names

I have lost days of time and hundreds of dollars cos the agent loves to alias my field names from prompt_id to promptId and is totally inconsistent about it. I have spend loads more undoing ALL of this across around 20’000 lines of code.

My question is; is there any way to put a master instruction into replit, like we have for chatGPT, that tells it stuff like this? “Never ever alias my db field names or I will rip your GPU out of your mother board and slam it up your heat sink!”

There are actually many instructions I’d add here, and I’m sure you guys would suggest many more.

I’ve had to fix issues because it did snake case formatting on mine when is asked it to transfer exact matches from CSV to my database columns. I’ve probably lost easily $50 chasing ghosts and then upon inspection the database realizes it was because agent went rogue. It’s frustrating I just started cussing at it at the end of prompts and it seemed to get it right after that, unfortunately I will not be spared during the uprising, but I have not found a better way to get it to comply.

1 Like

If it’s any consolation, I’m at the front of that queue for reprimands when the robots rise. I’m even fully expecting a cease and desist order from replit or anthropic some day.

1 Like

Yes sir, you have to make a(your app name) rule.md file. If you DO NOT have project docs, The best way is to get the entire front end done, then ask ai to creat you a requirements.md file, explain in detail what you want and have ai organize the informations, then give to replit and ask it to create it as a file. You’re welcome.

Wow, and agent/assistant will always check here when i start a new chat? This is actually epic!

I’m glad I’m not the only one.

It will only reference to the level of detail you provide, and you must instruct it to reference. I am currently refactoring all my code and i had it write a checklist and keep track of the progress because there is a point of diminishing returns on the context so I had to break it into several chats, but I still have to keep telling it to reference our written documentation / plan and keep updating the progess for the other chat context reference.

1 Like

How has refactoring with agent gone for you? I’ve been finding that when I want to refactor, it’s usually because there’s blast, and agent has struggled with getting lost in the weeds.

refactoring is tough - u have to work in small steps and test every step. Replit agent moves hooks and doesn’t update the references. So I spent a day testing cursor cos i heard it was WAY better. Copied my db to Neon, and learned to deploy with railway. But at the end of the day I found:

  • Cursor is not actually much better. It butchered a refactor completely, but then i did let it run for a while. It also has crazy long pauses for no reason.
  • Cursor is not nearly aware of the environment as replit; the console log, the client log, deployment, etc. I kept having to copy paste logs to the cursor agent.
  • The lack of integration between dev and browser is mildly annoying
  • It took a while to get cursor layout to mimic replit
  • Railway deployment is fast, but daaaamn, it took a while to debug that. Replit takes care of those issues very nicely
  • I need to dig into replit pricing of Neon, cos neon free tier looks very generous
  • But MAIN finding was; replit is not as slow as I thought. It’s db access to neon that is slow. My first cursor version used a local db, and daaaaaamn, it was blazing! But as soon as I switched to a neon hosted db, the speed came down again. I was super dissapointed cos this was my first try of cursor, and my first thought was “I’ve wasted FOUR months doing slow refreshes!!!”. but no, slow refreshes are life.

And so I’m back here…
The bottom line is that ALL of these vibe coding IDE’s are still in early days. Great - not great. Cursor may be leading at understanding the entire code base in clever context aware ways. But they all screw up. I’ll stick to some general tricks:

  • I’m a GPT pro subscriber, so I use that. There I’ll upload a zip of my repo, and get 4o-mini-high to diagnose an issue, then I’ll give that solution to replit assistant. Works way faster than replit retrying over and over. Even got it to compare 2 repo’s to find out what caused my new issue
  • I often use Perplexity pro search to figure out what to do, and give that to replit agent/assistant. It tends to think wider and further.
  • If assistant gets stuck in loops I try agent. if agent takes more than an hour on something i try asssitant. There’s no rule as to why, but often the second one will solve in one round, what the other had wasted 4 hours on.

One thing that will make me go back and try cursor again is that in cursor you can use an API key to get tokens at cost. At $100-200/m spend here, I get very pissy at how agent puts 6 charged checkpoints whilst achieving absolutely zero.

Just so you know, Claude Sonnet 3.7 is fantastic at refactoring if you have a basic idea of what to load into the context window. I use a custom extension I built called PairProgrammerAccelerator for copying the code, and it did a refactor for me that was super great. Took a little back and forth, but overall super good experience. I also involved o3 for running some shell commands to create the new structure, but you need to know what you’re doing (a bit risky if you’re not technical).

Now I’ve finally learned to commit and roll back repos, I have the risk appetite of a bear hunter :winking_face_with_tongue:

What’s the process; zip together the sever ts files and refactor there, then separately zip the client files and focus there? Rather than letting replit wander all over the repo. Imma try that.

I’m fighting this battle as well, I did some fun stats for my izios app for all of you to have a laugh. I literally started the refactoring process and have had a tiny bit of hiccups :joy:

The app has gotten big.

I asked jr out of curiosity how many files

  • 207 TypeScript files
  • 233 TypeScript React files
  • 360 JavaScript files
  • 1162 XML/SVG files (likely icons/assets)
  • 49 Markdown files
  • 18 JSON files
  • 5 HTML/CSS files
  1. scripts/enhanced-diamond-import.js (1,882
    lines) - Supplier API integration
  2. shared/schema.ts (1,815 lines) - Database schema definitions
  3. server/services/enhanced-diamond-api-client.ts
    (1,789 lines) - Enhanced Diamond API client
  4. server/routes.ts (1,620 lines) - API route definitions
  5. server/services/enhanced-diamond-feed-importer.ts
    (1,500 lines) - Diamond feed importer

The codebase appears to be a sophisticated diamond e-commerce platform with substantial Diamond Supplier API integration, which we’re now extending to integrate with WooCommerce.

Analyzed 895,485 lines of code across multiple files.

For a refactor, that would be exactly it. I would focus on the front end, and then the backend. (It’s easier to see when things are broken in the front end).