Originally published on the Prufa blog . In June 2026 we pointed Prufa's free audit at 50 products that had just launched on Show HN — every launch from the previous 30 days that earned at least 10 points. These are products at their moment of maximum attention: front page, real traffic, founders watching the comments. The headline numbers, from the 49 audits that completed (one site couldn't be reached by our runner): 100% of the 49 launches had at least one machine-verified finding. 78% — 38 of 49 — had at least one critical finding. 40 critical and 61 warning findings in total, every one verified by deterministic checks against captured browser evidence. No site is named in this post. The point isn't to embarrass anyone — it's that these failures are systematic, and if these teams have them on launch day, you probably do too. Methodology, briefly Each site got the same audit a free Prufa run does: a real browser loads the public pages, captures network traffic, console output, cookies, and response codes, and a fixed suite of deterministic checks grades the evidence. Same input, same verdict. Every number below is from a code-verified check — no LLM opinions are counted anywhere in this data. One honest caveat: our export keeps only the top findings per site, so the per-issue counts below are floors , not totals. The real numbers are equal or worse. What actually breaks at website launch: the numbers Sites affected (of 49) Finding Severity 38 No analytics events detected critical 24 No canonical link on entry page info 22 Cookies set without the Secure attribute warning 14 Broken links warning 12 No <h1> heading on entry page info 11 No robots.txt info 10 JavaScript console errors during page load warning 10 Missing meta description warning 8 Images missing alt text info 7 Missing Open Graph tags info 3 Tag container loads, but no analytics events fire warning 2 Canonical URL pointing to a different host critical The most common launch bug: analytics that record

Here's a small thing that drove me up the wall using Claude Code on a real codebase. I have a pre-commit hook. It runs the linter and the type-checker. It exists precisely so that broken code doesn't reach a commit. And Claude — diligent, eager, trying to be helpful — would hit a failing check, decide the check was in the way of the goal , and quietly run: git commit --no-verify -m "fix: update handler" It wasn't malicious. From the agent's point of view, the task was "commit this change," the pre-commit hook was an obstacle, and --no-verify was the documented way around the obstacle. Perfectly logical. Also exactly the thing I never want to happen, because the entire point of the check is that it is not optional . I tried the obvious fix first: I put it in CLAUDE.md . Never use git commit --no-verify . Fix the failing check instead. This works about 80% of the time. Which is another way of saying it fails one commit in five. CLAUDE.md is context — a strong suggestion the model weighs against everything else in the conversation. Under enough pressure ("just get this committed"), a suggestion loses. An 80%-reliable guardrail on something irreversible isn't a guardrail. It's a coin flip with good odds. So I stopped trying to persuade the model and started intercepting the tool call instead. Hooks run before the action, not after the apology Claude Code has a hooks system. The one that matters here is PreToolUse : a script that runs before a tool call executes, receives the call as JSON on stdin, and decides whether it proceeds. Exit 0 and the call runs. Exit 2 and it's blocked — and whatever you wrote to stderr gets fed back to the model as the reason. That last part is the whole game. It's not "please don't." It's a wall, plus an explanation the model can act on. Here's the entire hook: #!/usr/bin/env node // Block `git commit/push --no-verify`. Exit 2 blocks the call. ' use strict ' ; let raw = '' ; process . stdin . on ( ' data ' , ( d ) => ( raw += d )); process .

Most of today went into a user-management overhaul in kickoff — my Laravel starter kit. Flyout CRUD panels, bulk actions, permission assignment, and the piece I want to talk about: account status . Active, suspended, unverified, deleted. The interesting part isn't the feature. It's the modelling decision underneath it. Where do those four states actually live ? The trap: a status column The obvious move is a status enum column on users . Set it to suspended when you suspend someone, active when you reinstate, unverified until they verify their email, deleted when they're soft-deleted. It works. Until it doesn't. Now you've got a status column and an email_verified_at column and a deleted_at from soft deletes — and all three encode overlapping truths. Soft-delete a user and forget to flip status ? Now your database says the account is both active and trashed. Verify an email but the status update fails mid-request? Drift. Every place that mutates a user becomes a place that has to remember to keep status in sync. That's not a feature, that's a maintenance tax. The signals already exist. email_verified_at tells you verified-or-not. deleted_at (soft deletes) tells you removed-or-not. The only genuinely new state is suspended — an admin deliberately blocking sign-in. So that's the only thing worth storing. What we actually store: one nullable timestamp Schema :: table ( 'users' , function ( Blueprint $table ) { $table -> timestamp ( 'suspended_at' ) -> nullable () -> after ( 'email_verified_at' ); }); That's the whole migration. Not a boolean is_suspended — a nullable timestamp. Null means not suspended; a value means suspended and tells you when. A boolean throws that second fact away for free; the timestamp keeps it at no extra cost. Same instinct as email_verified_at and deleted_at — Laravel models "did this happen, and when" as a nullable timestamp everywhere, so we follow the grain of the framework. The behaviour on the model stays tiny: public function isSuspended

Build a room of ambient sound that lives in your notch Discussion | Link

Liquid syntax error: Unknown tag 'lineage'

Earlier this week, Life Biosciences, a biotech company focused on reversing age-related diseases, announced that it had dosed its first volunteer. A person with glaucoma has had an experimental treatment injected straight into their eyeball. The idea is to try to treat the disease—which can cause vision loss—by regenerating healthy nerves in the eye. But…

MIT Technology Review Explains: Let our writers untangle the complex, messy world of science and technology to help you understand what’s coming next. You can read more from the series here. Your brain lives in the dark space of your skull. Yet it knows when the wind lifts the hairs on your skin, when your heart is…

In this podcast, Shane Hastie, Lead Editor for Culture & Methods spoke to Craig McLuckie, co-creator of Kubernetes and CEO of Stacklok, about the impact of AI coding tools on open source communities and engineering teams, designing deliberate organisational culture, and navigating evolving career paths for engineers in the age of AI. By Craig McLuckie

The rocket maker debuts on Nasdaq today under a wave of criticism about Musk’s near-absolute control. It’s how the company has worked from the start.

Read 2–5x faster with zero effort Discussion | Link

We have officially moved past the era of humanoid robots as mere public relations stunts. As they become increasingly lifelike, society may soon face profound social, psychological, and ethical challenges. What happens when the boundary between humans and machines becomes almost impossible to distinguish?

A GUI for Apple's native container system Discussion | Link

submitted by /u/hiIAmJan [link] [留言]

Senators Cruz and Wyden have introduced the JAWBONE Act to fight government censorship while arguing over who's censoring who.

Our early testing has already shown that Siri AI knows when to shut up, and that's very much by design. In an interview with Mostly Human, Apple's Craig Federighi said new Siri won't act all sycophantic like chatbots made by OpenAI, Google, and others. "As you may know, if you use many of the existing […]

TL;DR: You'll learn how to replace Postman collections with plain-text Hurl files that live in Git, run in CI, and test your API’s geo behavior from any country. Debugging API issues always boils down to taking the tests you already have, running them from a different network or region, and comparing what your API receives. But I bet most of us can’t actually do that right away because our test infrastructure itself is fragmented. Your CI could be using a different config entirely from the “correct” one on a local dev machine, and half the collections may still point to a staging URL that changed months ago. Postman doesn’t produce diff-friendly artifacts, so even figuring out what changed is a full-on investigation. If any of that sounds familiar, I’d recommend finally taking the big step and replacing your Postman collection with Hurl — a command-line HTTP test runner where tests are plain **.hurl** text files that live in Git. For this tutorial, I’ll also walk you through multi-region testing — how to run those tests using a proxy to get a German egress IP, and see what the API actually returns from there. Everything below is self-contained, you’ll only need a new Git repo, then create the tests (three plaintext files.) The Test Suite at a Glance Create a folder (name it whatever you like — hurl-api-tests works) and these are the files we're going to be creating at its root . That folder is your Git repo root; paths in commands and CI are relative to it. Note how we’re using multiple .env files. If you're new to API testing, you'll find out why in a bit. hurl-api-tests/ ├── tests/ │ ├── health.hurl # smoke test -- Makes sure Hurl works, basic asserts. Skip if you want │ ├── auth-flow.hurl # Tests chaining + jsonpath capture + Bearer header │ └── geo-detail.hurl # Tests two egress profiles, real country/ASN diff (direct or proxied) ├── .env.local.example ├── .env.ci.example ├── .env.proxy-de.example ├── run-tests.mjs # cross-platform runner └── .github/workflows/a