Our Engineer Stu lets LLMs write his code, but he will die on the hill that AI prose is inherently garbage. His new article shows why, and how it's tied to the way LLMs are trained and the way they work. Even when you hand one plenty of examples of the voice you want it to imitate, it will fail to sound convincing. Check out his failed experiment here... If it's going to be read by a human, it should be written by a human. revelry.co/insights/artifici…

Our engineering Slack got quiet, so we pulled the data. Messages have cratered since 2023. Engineers are asking the chatbot instead of each other, and all that knowledge is dying in private chat sessions. Stuart Page on the AI silo: revelry.co/insights/artifici…

Do you ever find that, if you think an article has been AI generated, your motivation to finish reading it craters?

The Most Common Bug in Phoenix Apps (And How to Fix It) Ever deployed a Phoenix app, only to see scary error logs weeks later that seem completely unrelated to anything you changed? If you've worked with Phoenix, you've probably seen a wall of text in your logs that starts with this: "Could not check origin for Phoenix.Socket transport..." Here's what's really happening and how to fix it properly. THE PROBLEM Phoenix protects against Cross-site WebSocket Hijacking (CSWSH) by checking the Origin header during WebSocket handshakes. This is similar to CSRF protection but for WebSockets. When the origin doesn't match your configured domain, Phoenix rejects the connection and logs that verbose error message. WHY IT KEEPS HAPPENING Here's the pattern we see over and over: • You spend weeks or months building an app and testing it on a temporary domain • You launch your app with a shiny new production domain • Everything works perfectly •Two weeks later: error logs everywhere • But... nothing actually broke in your code? The culprit: Someone bookmarked your old staging domain or clicked a link from your hosting provider's admin panel. Their browser is trying to connect from the wrong domain, and Phoenix is (correctly) blocking it. THE REAL FIX The error message suggests updating check_origin configuration, but that's not what you want. You don't want to allow connections from multiple domains - you want to redirect users to the correct domain. Solution: Add a simple redirect plug to your browser pipeline. The plug should: • Check if the request hostname matches your endpoint configuration • Only run in production • Only redirect GET requests from browsers (not API routes) • Preserve the full path and query string WHY THIS APPROACH WORKS Instead of allowing connections from multiple domains (which weakens your security), you ensure all users are accessing your site through the correct URL. This means: ✓ Your WebSocket connections always pass origin checks ✓ Your security posture stays strong ✓ No more mysterious error logs ✓ Users get seamlessly redirected to the right place WHEN YOU NEED MORE If you're building: • A separate client-side application using Phoenix sockets • Multi-tenant apps with multiple subdomains You'll need a more sophisticated approach, but the redirect-to-canonical-domain pattern solves it for most Phoenix apps. Have you run into this issue? What's your approach to handling domain redirects in Phoenix?

Token consumption for JSON can be painful, but the ability for LLMs to use it for structured data seems to be better than other formats. What have you found to be the best data formats for you when talking to LLMs?

SECURITY ALERT: We’ve been notified of scammers impersonating Revelry Labs recruiters. We will NEVER ask for sensitive info, money, or equipment purchases. Legit messages come from @revelry.co emails. Unsure about a message? Contact careers@revelry.co