I’m building a language learning application [1]. It uses spaced repetition, built upon FSRS, an open source algorithm.
I’ve spent the last three years tweaking away at this algorithm. There are so many little details that have had to come together to make it an enjoyable experience. For example, take the one problem of balancing multiple language: What is the best way to balance multiple languages? How should you switch between them, and how often? What happens if you are over performing in one language and underperforming in another? What happens if you have more reviews in one language than another that isn’t in line with your priorities? How do you deal with competing learning speeds and language priorities? Spiky review burdens? What happens when you change your language priorities?
This is probably the most trivial part of the algorithm, and it took years of trial and error and dozens of iterations to get it to feel right. It requires knowing about SRS, the FSRS algorithm, language learning principles, and even then tons of experimentation, trial and error, and hundreds of days of daily usage.
I’ve asked LLMs every step of the way what to do. I’ve probably taken <1% of the advice I was given. Just asking an LLM “build an SRS app that balances multiple languages” would produce a result, but one that would definitely be terrible to use, and probably would end up slowing you down, not speeding you up. Explaining to it any of the issues that you would come across when using it will likely suggest to changes that will only make things worse, based on the thousands of terrible ideas I’ve seen confidently produced.
The hard part of a product is not the idea, but the experience of using it. The valueable work is normally not in the big feature specs, but the hundreds of little paper cuts that have all been smoothed over. The time saved is not because you don’t have to code it, but is from not having to become an expert in several different fields.
[1] https://phrasing.app