Fun article. I for one wholeheartedly want more "How not to" articles on the web. It was one of my big frustrations while working as a physics researcher. No publishes what they've tried that didn't work!
Learning from your own mistakes is good. But learning from someone elses mistakes so you don't have to make them yourself is even better!
I decided to write my own music player and call it AMP with a few goals in mind: minimal feature-set, no C++ dependencies, proper system integration to make it feel like a native app, and of course, write it in Zig (including the shaders!). I also wanted to roll my own UI
If these are “a few goals”, I feel like an unaccomplished slacker.
I literally couldn’t hit the plan limits no matter how hard I tried, so after a few non-stop days of prompting, a good chunk of AMP was vibecoded..
🫣
That said I think it’s still possible to create a healthy relationship with LLMs as long as you look at them as a fancy IDE feature. A lot of times they are just running long sed or regex commands that are a no-brainer act for humans when done by hand but still consumes a good time. For now and hopefully forever I think I’ll be going the old school way. Never rush your hobbies!
IMHO, the author learned the wrong lesson from this experience. They underestimated the sheer scope of the project they wanted to tackle. A project like this needs months of thinking before a single line of code gets written. If you view prompting as a kind of customer–developer conversation about what you want, you can’t expect even the best developers to deliver anything but slop after just a few days of talking.
I disagree that this requires months of planning before code is written. For a personal project, writing code immediately and constantly iterating and learning is a totally reasonable approach - this is usually how my personal projects end up going and it keeps the process fun.
I understand your confusion now. My months of thinking are not meant as month long planing sessions 9 to 5. What I think I tried to communicate is: Each of the goals on the list needs proper research if you are not not an expert in the specific topic. I'm not saying you need to be an expert, but you need at least to know what you don't know. Once you did it for each of topics you have some kind of huge puzzle mess, where 2/3rd of the puzzles pieces don't even fit anywhere.
The best way to learn is typically to sketch out code by hand, and see how the pieces fit together. Otherwise, it's like cooking without tasting your ingredients.
I hope my previous comment didn’t come off as offensive or as a critique of your work.
still figuring out how to replace harfbuzz.
Awesome! This is exactly what I meant by months of thinking. You probably figured out that you need text shaping and researched the topic. Maybe you’ll end up writing a toy shaper in Zig to understand it more deeply. But at the end of your “getting into text shaping” process, you won’t have any deliverable besides your new knowledge and maybe a decision to use library X because of trade-offs Y and Z. Now repeat that process for every subtopic of each of your goals, and you get months of thinking.
Only marginally related to the post, but @alichraghi and co cooked on the Zig SPIR-V backend.
I've been using it for coursework targeting WebGL and my experience has been very pleasant.
There is a pre-windows version of WinAMP... several actually, as MacAMP shipped first.
But more relevant, AMP was the name of the audio playback engine itself, which was built first, and it is still owned by an active company. Seems like this is likely to attract a trademark dispute.
The LLM turn and the turn away is interesting. Here the return to full meatbrain mode was enforced by bad outside circumstances. I wrote a little about how I think about this friction.
Kinda surprised when I got to the bit about going all in on network connected code generation when one of the main motivations for the project was not wanting to be dependent on network connected music services. It seems the OP was brought back to reality when the Claude account was banned. Congratulations on undoing the LLM code and building what you set out to build in the end.
vincent-uden | 14 hours ago
Fun article. I for one wholeheartedly want more "How not to" articles on the web. It was one of my big frustrations while working as a physics researcher. No publishes what they've tried that didn't work!
Learning from your own mistakes is good. But learning from someone elses mistakes so you don't have to make them yourself is even better!
kalkin | 9 hours ago
If these are “a few goals”, I feel like an unaccomplished slacker.
🫣
IMHO, the author learned the wrong lesson from this experience. They underestimated the sheer scope of the project they wanted to tackle. A project like this needs months of thinking before a single line of code gets written. If you view prompting as a kind of customer–developer conversation about what you want, you can’t expect even the best developers to deliver anything but slop after just a few days of talking.
whjms | 8 hours ago
I disagree that this requires months of planning before code is written. For a personal project, writing code immediately and constantly iterating and learning is a totally reasonable approach - this is usually how my personal projects end up going and it keeps the process fun.
kalkin | 4 hours ago
I see the confusion. I didn't mean literally "no single line of code". I meant more like no production code.
orib | 8 hours ago
Waterfall is usually not the best methodology.
kalkin | 7 hours ago
At no point i mention any kind of methodology.
orib | 7 hours ago
You describe a methodology ("months of up front planning, before you start work"), even if you don't name it.
kalkin | 7 hours ago
You are misquoting me. Please read what i actually wrote.
Fingel | 6 hours ago
Just thinking? Not writing anything down? Months of it? Interesting process, especially if you don't consider it planning.
kalkin | 4 hours ago
Isn't taking notes part of a thought process?
Depends on the project.
orib | 7 hours ago
"A project like this needs months of thinking before a single line of code gets written."
Sorry, you're right, you didn't necessarily state all of that thinking was spent planning, that's on me.
kalkin | 6 hours ago
I understand your confusion now. My months of thinking are not meant as month long planing sessions 9 to 5. What I think I tried to communicate is: Each of the goals on the list needs proper research if you are not not an expert in the specific topic. I'm not saying you need to be an expert, but you need at least to know what you don't know. Once you did it for each of topics you have some kind of huge puzzle mess, where 2/3rd of the puzzles pieces don't even fit anywhere.
orib | 6 hours ago
The best way to learn is typically to sketch out code by hand, and see how the pieces fit together. Otherwise, it's like cooking without tasting your ingredients.
kalkin | 4 hours ago
I fully agree with you, because you said sketch out. You are not writing production code, so IMHO it's thinking. Am I being strange?
[OP] alichraghi | 7 hours ago
Yes, perhaps a bit far from those goals. still figuring out how to replace harfbuzz. There are libraries like Hamza that I want to try.
kalkin | 4 hours ago
I hope my previous comment didn’t come off as offensive or as a critique of your work.
Awesome! This is exactly what I meant by months of thinking. You probably figured out that you need text shaping and researched the topic. Maybe you’ll end up writing a toy shaper in Zig to understand it more deeply. But at the end of your “getting into text shaping” process, you won’t have any deliverable besides your new knowledge and maybe a decision to use library X because of trade-offs Y and Z. Now repeat that process for every subtopic of each of your goals, and you get months of thinking.
Shorden | 5 hours ago
Only marginally related to the post, but @alichraghi and co cooked on the Zig SPIR-V backend. I've been using it for coursework targeting WebGL and my experience has been very pleasant.
hjvt | 14 hours ago
AMP is one letter away from a different music player, AIMP
5d22b | 8 hours ago
To me the name looks as if it were meant to be some hypothetical pre-Windows version of WinAMP. :-)
abeyer | 5 hours ago
There is a pre-windows version of WinAMP... several actually, as MacAMP shipped first.
But more relevant, AMP was the name of the audio playback engine itself, which was built first, and it is still owned by an active company. Seems like this is likely to attract a trademark dispute.
faassen | an hour ago
The LLM turn and the turn away is interesting. Here the return to full meatbrain mode was enforced by bad outside circumstances. I wrote a little about how I think about this friction.
wezm | an hour ago
Kinda surprised when I got to the bit about going all in on network connected code generation when one of the main motivations for the project was not wanting to be dependent on network connected music services. It seems the OP was brought back to reality when the Claude account was banned. Congratulations on undoing the LLM code and building what you set out to build in the end.