Bolt.new and bolt.diy cooperating on piano learning app

bolt.diy [bolt.diy] Project Showcases
1

What I built

It’s holiday time. My five-year-old wanted to learn playing the digital piano she found in her mom’s childhood box.

Of course, she can’t read any notes – nor do I :grimacing:

I recalled the colored keyboards from my childhood, so I though: Why not build an app that translates music sheets into color codes?

screenshot-playalong
screenshot-playalong2318×1686 247 KB

Live app on netlify: https://piano-buddy.netlify.app/
Repo GitHub - mrsimpson/pianobuddy: An app for children to learn play piano

How I did it

  • Started with bolt.new (the commercial version)
  • Then loaded the repo using the git import into bolt.diy for smaller changes / refactorings
  • LLM-Provider: Mostly Claude Haiku

Lessons learned

  • Agentic features of the commercial bolt.new are amazing. It just excels starting from scratch (templates, we discussed this often enough), but also picking and installing proper packages, inspecting imported packages interfaces for coding to them. bolt.diy cannot really help here (yet)
  • bolt.diy can really perform well if it doesn’t have to invent, but basically restructure.
  • The development flow with both tools (generating code, but then how to run it in my IDE locally) sucks. Also with the commercial bolt.new. I think this is where we should actually be able to excel, but import/sync/git flow is really poor (e. g. uploading a folder does not respect the .gitignore, loading from git requires a remote push). I think we should make this a priority.
  • Most LLMs code better and structure code more elegantly than I usually do it. That’s sick.
  • One thing to watch out for is that often, redundant functions are generated in different files. Neither app likes to clean up. Also in this sense, they are incredibly human… This creates hard-to-spot issues
  • CSS gives them a lot of trouble. Flexing and positioning across multiple single file components wasn’t too successful. Also in this aspect: incredibly human :grimacing:

What’s next to evaluate

  • have bolt.diy implement unit- and end-to-end-tests
  • have bolt.diy build a cicd
5 Likes
2

Awesome! Been wanting to teach my kids piano, so I might give this thing a try out.

1 Like
3

For those almost-grey-haired developers who believe their profession is at risk, let me share some hope. The lion’s share of the six hours, I spent with

  • understanding what I actually want (and I’m not even talking about having others understand what they want and then understand that myself)
  • finding a library which does the heavy lifting of visualizing the sheet (the incredible open sheet music display
  • Understanding music notation (pitch, relative duration, multiple parts and stages) and musicxml as format. Claude was a good assistance here as well!
  • Responsive layout of the music sheet, as osmd has an explicit render step where it occupies the container available.
  • But the way bolt.new / Claude implemented the colored play-along messed up a lot of things. It didn’t understand how to flex (i required multiple lines) which introduced many problems. In order to solve them, I needed to understand almost the whole code base. Which is not really tiny, so by simply relying on the LLM is not possible. Latest at debugging, all the complexity comes back to you. I might experiment with introducing how I want code organized right at the beginning, so it’s not like “somebody else’s code” (which follows best practices, but not mine ;))
  • Fixing typescript build issues and linting. Obviously, there’s no agent yet that handles this.

My conclusion: It’s great to be a software developer, but as a programmer (who translates human language into computer languages), you’re probably not going to be able to compete on mainstream technologies.

1 Like