The awkwardness here actually works in favour of abolishing tips and replacing them with the pay being factored into higher prices.
No one wants to be the sucker - human nature is that people are generous if they think everyone else is generous, but if they feel that others are not ‘pulling their weight’ on generosity and are instead taking advantage, that’s the fastest way to dry up other people’s generosity. Right-wing media use this fact to undermine support for social welfare - e.g. if 0.001% of welfare payments are fraudulently taken, they set editorial policy that makes it seem like beneficiaries are rorting the system instead of being truly needy.
But when it comes to tipping, the dynamic actually works the other way - people feel generous by tipping, even though it is harmful long term. If a few people ahead of someone in the line don’t tip, should they be the sucker who does tip? And for the employee, you want them to be the advocate on the inside for forcing people to pay their share instead of taking advantage - by having the displayed price be the total upfront price that includes the compensation for employees, instead of an optional tip.
As an experiment / as a bit of a gag, I tried using Claude 3.7 Sonnet with Cline to write some simple cryptography code in Rust - use ECDHE to establish an ephemeral symmetric key, and then use AES256-GCM (with a counter in the nonce) to encrypt packets from client->server and server->client, using off-the-shelf RustCrypto libraries.
It got the interface right, but it got some details really wrong:
wrapping_add
to increment the 32 sequence number! For those who don’t know much Rust and/or much cryptography: the golden rule of using ciphers like GCM is that you must never ever re-use the same nonce for the same key (otherwise you leak the XOR of the two messages).wrapping_add
explicitly means when you get up to the maximum number (and remember, it’s only 32 bits, so there’s only about 4.3 billion numbers) it silently wraps back to 0. The secure implementation would be to explicitly fail if you go past the maximum size for the integer before attempting to encrypt / decrypt - and the smart choice would be to use at least 64 bits.To be fair, I didn’t really expect it to work well. Some kind of security auditor agent that does a pass over all the output might be able to find some of the issues, and pass it back to another agent to correct - which could make vibe coding more secure (to be proven).
But right now, I’d not put “vibe coded” output into production without someone going over it manually with a fine-toothed comb looking for security and stability issues.