Comment by captainclam

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

The phrase I've found useful is Yegge's "Crystalized Cognition" https://steve-yegge.medium.com/software-survival-3-0-97a2a62...

Claude can 100% build you your own basecamp quickly, but there is a lot of good thinking that has gone into a product. Edge cases. Integrations. Clarity of thinking and ways to extend it. Agents love standing on the shoulders of good crystalized cognition (grep, curl etc), but I think that extends even beyond base CLI tools.

Which is not to say that "cheapest alternative" won't be much more important than it is now, but the tools that will succeed are the ones that solve clear problems with accessible CLI/tool-call like interfaces and take significant load off the agent running, while doing it efficiently and cost effectively so they are clearly better than building it yourself.

To be fair, there will be a ton of margin collapse and that will be unachievable by a lot of current orgs / structures.

Why waste tokens and ops team time and developer bug chasing time when you can get a signed contract with guaranteed uptime and support, and have those people be building something you can sell instead?

It's all opportunity cost.

Edit: throw in mandated security audits and maintenance for SOC2 compliance or whatever else you're on too, depending on the industry you're in.

People don’t actually want to build software. There will still be a market for hosted software that feels like magic. The next shape and UX is still getting fleshed out.

Also: the coded apps that AIs build are unmaintainable without a tech background. They may work for exactly their proposed happy-path and that may be great. But over time I can’t see how it’s possible these apps get maintained.

In the current/legacy market, people accept bugs in software because software was expensive and the alternatives are often few for that same reason.

Tomorrow's software will need to be _perfect_, or else it won't differentiate from "Claude, build a basecamp-style project management tool for my team".

Why would you build an app at all? Why wouldn't Claude just be the app itself? You ask it to set up your UI in the web app and you just use Claude for your entire workflow.

We're only a few persistent widgets and a better persistent storage story away from this possibility.