If I'm playing a quick pattern like this and holding down some bass note, depending on where the pattern starts, the middle two notes will become "synchronized" and play/get recorded at the same time. In my example, the top 4 notes work fine, but shifting down by one note causes the bug. I also switched between holding the bass not and not for demonstration. I assure you my fingers aren't doing anything different, I messed around with this for a while.
edit: got a better recording: https://webpiano.jcurcioconsulting.com/play/b4qautCGQpQjA6wq...
2nd edit: I thought this had to do with the "groupings" of keys but even the middle 4 that are grouped together show this behavior: https://webpiano.jcurcioconsulting.com/play/5XuIskeJNQQaiC7h...
The Claude the industry needs is one that responds to that prompt with questions about scope and intent, and challenges its only-suitable-for-tutorials design ideas rather than obediently delivering a "90% finished product".
10 years ago, this basically marks the difference between hiring some dude on Fiverr for $400 and an actual engineer or agency who might help you figure out what the heck you're trying to do and point you in some sane direction towards it.
I appreciate this article for sharing what kind of experience people can expect from Claude right now, but it mostly demonstrates that code assistants remain most useful in the hands of experts who are careful what to ask for, and largely misleading and slop-amplifying for people who don't.
( p.s. Tell claude that when quickly pressing keys with a mouse that there is audible clipping. This doesn't seem to happen when using the keyboard. )
If I come back to it to look to add polish (and fix mobile) that'll be a prompt I'll throw at it as well.
I actually just put together a write up showing my prompts and explaining what was generated after each, if you're interested at all https://jcurcioconsulting.com/posts/how-i-used-claude-code-t...
Thanks for the detailed debug output! This confirms what we suspected, the message is being accepted by Twilio but it might be filtered by T-Mobile before reaching your handset.
Can you try sending "Error Detected" one more time just to confirm it's consistently filtered (not a one-time glitch)?
If it fails again, then:
1. The immediate problem: "Error Detected" is likely triggering T-Mobile's spam filter. Try a more specific message like "[YourApp] Error in payment processor at 3:42 PM", generic error messages get filtered heavily. Let me know if that gets through.
2. Our misleading status: You're right - showing "delivered: true" when it just means "accepted by carrier" is confusing. We're working on:
- Clearer status terminology ("accepted" vs "delivered")
- Webhook integration to track actual handset delivery
- Guidance on avoiding carrier filtering
Again, Thank you so much for testing this out.Tried changing to "Hey Jeremy1026: Error in payment processor at 3:42 PM", same status with no delivery to my phone number, ID: jz44a46jjpx7vjpzsa9c0soc.
I used to work with Twilio pretty heavily at a SaaS, I left as they started to crack down on SMS. One of my last projects was developing an in-app front-end to submit the regulatory paperwork to get higher delivery rates for SMS. I know it was a huge pain, sounds like it still is.