Comment by apwell23
4 days ago
how many prompts did it take you to make this?
how did you make sure that each new prompt didn't break some previous functionality?
did you have a precise vision for it when you started or did you just go with whatever was being given to you?
Judging by the site, they don't have insightful answers to these questions. It's broken with weird artifacts, errors, and amateurish console printing in PROD.
https://i.ibb.co/xSCtRnFJ/Screenshot-2025-11-25-084709.png
https://i.ibb.co/7NTF7YPD/Screenshot-2025-11-25-084944.png
I definitely don't have insightful answers to these questions, just the ones I gave in the sibling comment an hour before yours. How could someone who uses LLMs be expected to know anything, or even be human?
Alas, I did not realize I was being held to the standard of having no bugs under any circumstance, and printing nothing to the console.
I have removed the amateurish log entries, I am pitiably sorry for any offense they may have caused. I will be sure to artisanally hand-write all my code from now on, to atone for the enormity of my sin.
It also doesn't seem to work right now.
Yeah, all of the above was a single bug in the plot allocation code, the exception that handled the transaction rollback had the wrong name. It's working again.
> how many prompts did it take you to make this?
Probably hundreds, I'd say.
> how did you make sure that each new prompt didn't break some previous functionality?
For the backend, I reviewed the code and steered it to better solutions a few times (fewer than I thought I'd need to!). For the frontend, I only tested and steered, because I don't know much about React at all.
This was impossible with previous models, I was really surprised that Codex didn't seem to completely break down after a few iterations!
> did you have a precise vision
I had a fairly precise vision, but the LLM made some good contributions. The UI aesthetic is mostly the LLM, as I'm not very good at that. The UX and functionality is almost entirely me.
did you not run into this problem described by ilya below
https://www.youtube.com/watch?v=aR20FWCCjAs&list=PLd7-bHaQwn...
this has been my experience purely vibecoding. i am surprised it works well for others.
btw the current production bug. how did you discover that and why it slip out. looks like site wasn't working at all when you posted that comment?
> did you not run into this problem described by ilya below
I used to run into a related issue, where fixing a bug would add more bugs, to the point where it would not be able to progress past a given codebase complexity. However, Codex is much better at not doing that. There are some cases where the model kept going back and forth between two bugs, but I discovered that that was because I had misunderstood the constraints and was telling the model to do something impossible.
> how did you discover that and why it slip out.
Sentry alerted me but I thought it was an edge case, and I didn't pay attention until hours later.
I use a spiral allocation algorithm to allocate plots, so new users are clustered around the center. Sometimes plots are emptied (when the user isn't active), so you can have gaps in the spiral, which the algorithm tries to fill, and it's meant to go to the next plot if the current one can't be assigned.
For one specific plot, however, conditions were such that the database was giving an integrity error. The exception handling code that was supposed to handle that didn't take into account that it needed to roll back before resuming, so the entire request failed, instead of resuming gracefully. Just adding an atomic() context manager fixed it.
> looks like site wasn't working at all when you posted that comment?
It was working for a few hundreds (thousands?) of visitors, then the allocation code hit the plot that caused the bug, and signup couldn't proceed after that.
3 replies →