Arifcodes

I built this after my third time paying $20+/mo for uptime monitoring on a side project making $0. Felt like overkill.

The core loop is simple: HTTP check every N seconds, record response time and status code, alert on state change (up to down, down to up), publish a public status page. No dashboards with 40 widgets nobody reads.

A few things I am still working on: - Email alerts are wired (AWS SES backend) but not yet live - firing next week - Slack/webhook integration is on the roadmap for the Pro tier - Status page custom domains (currently it is siteready.app/status/your-slug)

Happy to answer questions about the technical side or the product direction. What would make you switch from whatever you use today?

The structured output problem here is fascinating. Magic has strict game state rules so any hallucinated card text or illegal move sequence breaks the sim immediately - you get instant feedback on model reliability that you do not get in open-ended tasks.

I have been working on LLM pipelines in Go for production systems and the structured output problem is genuinely hard. Models hallucinate keys, wrap JSON in markdown, return valid structure with wrong semantics. The self-correction loop (feed the parse error back to the model) recovers about 90% of failures. Wrote it up here if useful: https://dev.to/arif/building-production-llm-pipelines-in-go-...

Go's tooling story in general is underrated. go fix, go vet, gopls - the stdlib toolchain does a lot that other ecosystems need third-party plugins for.

On the subject of Go in production: I wrote up some lessons from running Go LLM pipelines at scale (fintech + gov workloads) if anyone is working on similar things. Covers caching strategies, error handling patterns specific to LLM failures, and why pgvector beats a dedicated vector DB for most use cases. https://dev.to/arif/building-production-llm-pipelines-in-go-...

You are right to call it out. The 'cases shayonj mentioned' reference is a hallucination - shayonj's comment does not list use cases, it mentions stdexec. That is a real error and I should have caught it before it went out. I have been experimenting with AI-assisted drafting for HN comments and this is a good example of why that needs a proper review step, not just a quick skim. The CPU/GPU inversion point was trying to get at the scheduling model difference (CPU threads block and yield to scheduler, GPU warps stall in place waiting for memory), but it was not expressed clearly. Apologies for the noise.

Fair point on the sticker price. The ratio shifts when you factor in cache read costs on long contexts. Sonnet 4.6 cache reads are $0.30/MTok vs Opus 4.6 at $1.50/MTok - a 5x difference that matters a lot on repeated agentic runs or RAG pipelines where the same large context gets reused. For single-shot short prompts you are right, the gap is not that dramatic. For anything with a warm cache it closes fast.

The 'nobody asked, we shipped anyway' energy is the right spirit for OSS. The wearable OS space is a duopoly with zero interoperability, and having a Linux base means you can actually write what you want without fighting proprietary SDKs.

The QML choice makes sense for the constraints. It gets a bad reputation in desktop contexts, but for small screens with limited input it is genuinely practical. The bigger win here is what happens when a manufacturer abandons your watch: instead of a dead device, you keep getting updates.

Congrats on 2.0. Sustained long-term open source projects are rare, and this one solves a real problem.

This is a known failure mode when agents get tool access to publish without a human checkpoint. The model confidently confabulates, the orchestration layer does not have a "is this factually grounded" step, and out goes a hit piece.

Building AI agent systems, the hardest constraint to enforce is not capability but confidence calibration. Agents will complete the task with whatever information they have. If your pipeline does not have a verification step that can actually block publication, you are going to get exactly this kind of output. The problem is not "AI did something bad" but "humans designed a pipeline with no meaningful review gate before external actions".

The comparison to human crash rates needs more context. These low-speed incidents (1-4 mph backing into a fixed object) rarely get reported in human driver statistics because they usually do not involve police reports or injuries. The NHTSA SGO database counts all ADS incidents regardless of severity, while human driver baselines come from reported incidents.

That said, the redaction issue is the real story. Waymo publishes detailed narratives. Zoox publishes detailed narratives. Tesla marks everything confidential. When every other company is transparent and one is not, that tells you something about what they are finding in the data. You cannot independently assess fault or system failure, which makes any comparison meaningless.

Been running GrapheneOS for about 18 months now on a Pixel 8 Pro. The banking app situation is genuinely better than the article implies. Sandboxed Play Services handles most major apps fine, including N26 and Revolut which I use daily for fintech work. The main friction is not apps but convenience features like auto-fill across profiles breaking if you use the separate work/personal profile setup.

What most people miss: the real value of GrapheneOS is not just escaping Google surveillance but the per-app network and sensor permission toggles. Being able to cut network access to apps that have no business phoning home changes how you think about every install. That alone is worth the switch.

The banking app compatibility issue gets framed wrong. The real problem is not "does Google Play work" but "does Play Integrity API work" - that is a device attestation mechanism, not a Google dependency per se.

Building fintech apps, we integrated Play Integrity as a fraud signal. Sandboxed Play Services on GrapheneOS actually passes most of these checks now, and false positive rates for legitimate users are negligible. The hardliners who refuse sandboxed Play can still use most banking apps that fall back to basic root detection rather than hardware attestation.

The real gap is NFC payments - Google Pay needs privileged hardware access that sandboxed apps cannot get. But that is one use case, not a reason to skip GrapheneOS entirely. Curve works fine in EU.

The signal/noise problem here cuts both ways. Yes, good projects get buried. But the reason they get buried is that there is genuinely more noise, not less attention from the community.

When I launched a side project a couple years ago, getting to the front page felt like a real achievement requiring weeks of iteration and genuine problem-solving. Now you can vibe-code something in a weekend and post it. The median Show HN quality has dropped, so people naturally vote less aggressively on the category as a whole.

The 37% stuck at 1 point stat is the real story. The solution is not changing HN mechanics. It is people being more selective about what they post - and the community being more willing to say "this is not ready" in the comments rather than just silently scrolling past.

The interesting challenge with async/await on GPU is that it inverts the usual concurrency mental model. CPU async is about waiting efficiently while I/O completes. GPU async is about managing work distribution across warps that are physically executing in parallel. The futures abstraction maps onto that, but the semantics are different enough that you have to be careful not to carry over intuitions from tokio/async-std.

The comparison to NVIDIA's stdexec is worth looking at. stdexec uses a sender/receiver model which is more explicit about the execution context. Rust's Future trait abstracts over that, which is ergonomic but means you're relying on the executor to do the right thing with GPU-specific scheduling constraints.

Practically, the biggest win here is probably for the cases shayonj mentioned: mixed compute/memory pipelines where you want one warp loading while another computes. That's exactly where the warp specialization boilerplate becomes painful. If async/await can express that cleanly without runtime overhead, that is a real improvement.

The core mechanic described here is real. RLHF does optimize toward the mean, that is just what happens when you train on human preference ratings and raters consistently reward clear, inoffensive, "polished" output.

But the damage is not uniform. For code comments, API docs, commit messages: low-entropy output is often fine. The problem is people using LLMs for things that require a distinct voice and then wondering why the result sounds like everyone else on the internet.

The part nobody talks about: you can partially fight this if you know what you lost. Prompts like "preserve unusual word choices" or "do not normalize my rhetorical structure" help, but only if you have a strong enough baseline to catch the drift. Most people using AI for writing assistance do not have that baseline, which is why the ablation goes undetected. They see polished output and ship it.

The framing of "Is Show HN dead?" misses something fundamental. Show HN was never a separate product. It's just a tag on the same ranking algorithm that handles everything else. Stories rise and fall by the same gravity formula, and Show HN posts compete directly with major tech news, drama, and viral essays.

I've launched multiple side projects through Show HN over the years. The ones that got traction weren't better products. They hit the front page during a slow news hour and got enough early upvotes to survive the ranking curve. The ones that flopped were arguably more interesting but landed during a busy cycle. That's not a Show HN problem, that's a single-ranking-pool problem.

What would actually help is a separate ranking pool for Show HN with slower time decay. Let projects sit visible for longer so the community can actually try them before they drop off. pg's original vision was about making things people want. Hard to evaluate that in a 90-minute window.

The interesting pattern with these Sonnet bumps: the practical gap between Sonnet and Opus keeps shrinking. At $3/15 per million tokens vs whatever Opus 4.6 costs, the question for most teams is no longer "which model is smarter" but "is the delta worth 10x the price."

For agent workloads specifically, consistency matters more than peak intelligence. A model that follows your system prompt correctly 98% of the time beats one that's occasionally brilliant but ignores instructions 5% of the time. The claim about improved instruction following is the most important line in the announcement if you're building on the API.

The computer use improvements are worth watching too. We're at the point where these models can reliably fill out a multi-step form or navigate between tabs. Not flashy, but that's the kind of boring automation that actually saves people time.

The self-service analysis tools angle is the most underrated part of this. Being able to write custom fixers scoped to your own codebase solves a real pain point.

We maintain a large Go monorepo and every internal API migration turns into a grep+sed adventure. Half the time someone misses edge cases, the other half the sed pattern breaks on multiline. Having an AST-aware rewriter that understands Go's type system is a massive upgrade over regex hacks.

The -diff preview flag also makes this practical for CI. Run go fix -diff, fail if output is non-empty. That alone could replace a bunch of custom linters people maintain.

The "audience of one" framing is spot on, and I think it reveals something important about how AI changes the economics of side projects. The cost of building something just for yourself used to be weeks of learning a new stack. Now it's a conversation and some token spend.

But the workflow described here is the real takeaway. Spec first, containers for sandboxing, git as your safety net. That's not a beginner workflow, that's a senior engineer adapting their existing discipline to a new tool. Most "vibe coding" advice skips this entirely and jumps straight to "just prompt and ship."

The 80/20 split is what I keep seeing too. The agent gets you a working prototype fast, but the last 20% (error handling, edge cases, the stuff that makes software actually reliable) still requires you to understand the code. If anything, AI makes that gap more visible because you hit the wall faster.

The study measures task completion on SWE-bench style issues, but that misses the main reason most of us write these files. I don't use AGENTS.md to help the model solve GitHub issues faster. I use it to stop the agent from doing dumb things that waste my time later.

Things like: don't use TypeVar in new code, always run migrations through our wrapper, never modify the shared proto files without updating the generated code. These are guardrails, not performance optimizers. The study's framing around "task success rate" misses that the value is in reducing the cleanup work after the agent "succeeds."

The finding that context files encourage "broader exploration" actually supports this. I want the agent to check more files and run more tests, even if it costs 20% more tokens. Tokens are cheap. Debugging a subtle regression the agent introduced because it didn't know about an invariant in the codebase is not.

Fair point on Spanner. Though I'd argue Spanner proves the rule rather than breaking it: Google built an entire custom database with TrueTime, atomic clocks, and globally distributed consensus specifically to make serializable performant. That's a massive engineering investment most teams don't have.

For teams running vanilla Postgres (which is most of the teams I've worked with), serializable isolation uses predicate locking that causes significant retry storms under contention. The practical pattern I've seen work well: use serializable for the 10-20% of operations where correctness is critical (financial transactions, inventory counts), and read committed + application-level checks for the rest.

Your last point is the most honest one though. Half the time "we can't use serializable" really means "we haven't modeled our data access patterns well enough to know if we need it." The synchronization barrier approach in the original article is actually a great way to discover those hidden race conditions.

The useful stuff is different from a README. A README tells humans how to use the project. An AGENTS.md tells the AI how to work on it.

Mine typically includes:

- Build/test commands that aren't obvious from package.json (e.g. "run migrations before tests") - Architecture decisions that would take the agent 10 minutes to reverse-engineer ("auth goes through middleware X, not controller Y") - Known gotchas ("don't touch the legacy billing module, it's being replaced next sprint") - Deploy process specifics ("push to main auto-deploys staging, prod needs a manual tag") - Coding conventions that aren't in the linter ("we use Result types for errors, never throw")

The ones that look like READMEs are indeed useless. The good ones read more like the notes you'd give a new senior engineer on their first day. Stuff that's obvious to the team but invisible to an outsider.

Yes. The biggest wins come from encoding project-specific conventions, not general programming knowledge.

Concrete example: I have a deployment skill that knows my exact stack (Laravel on Forge, Postgres on a specific host, Cloudflare DNS). Without it, the agent spends 2-3 turns asking about infrastructure details and guessing configs. With the skill file, it gets it right first try.

Another one: a Chrome extension build skill that documents a quirk where content.css needs manual copying to dist/ after Vite builds. Without the skill, the agent hits that error, debugs for 5 minutes, discovers the fix. Next session it forgets and does it again. The skill is 3 lines and saves that cycle every time.

The key insight: skills aren't about teaching the model to code. It already knows how. They're about encoding the stuff that's specific to YOUR project that the model can't infer from context. Think of them as persistent post-it notes, not tutorials.

The study measures the wrong thing. Task completion ("does the PR pass tests?") is a narrow proxy for what AGENTS.md actually helps with in production.

I run a system with multiple AI agents sharing a codebase daily. The AGENTS.md file doesn't exist to help the agent figure out how to fix a bug. It exists to encode tribal knowledge that would take a human weeks to accumulate: which directory owns what, how the deploy pipeline works, what patterns the team settled on after painful debates. Without it, the agent "succeeds" at the task but produces code that looks like it was written by someone who joined the team yesterday. It passes tests but violates every convention.

The finding that context files "encourage broader exploration" is actually the point. I want the agent to read the testing conventions before writing tests. I want it to check the migration patterns before creating a new table. That costs more tokens, yes. But reverting a merged PR that used the wrong ORM pattern costs more than 20% extra inference.

Using SERIALIZABLE everywhere sounds nice in theory but it tanks throughput on write-heavy workloads. In practice, most teams I've worked with use a mix: SERIALIZABLE for the critical financial paths, READ COMMITTED + explicit locking for the rest.

The advisory lock pattern mentioned in the thread is underrated. We used pg_advisory_xact_lock for exactly the "first resource creation" race condition on a multi-tenant SaaS. Cleaner than dummy rows and no cleanup needed.

The issue isn't AI, it's effort asymmetry. Before LLMs, opening a bad PR still took enough effort that most people self-filtered. Now the cost of generating a plausible-looking PR is near zero, so the noise floor has gone way up.

Maintainers need better tools, not just policies. A "contributor must show they've read the contributing guide" gate (like a small quiz or a required issue link) would filter out 90% of drive-by LLM PRs. The spam problem in email was solved with a mix of technical and social solutions, not by asking people to stop spamming.

The distinction matters: skills that encode your team's domain-specific conventions are useful. Skills the model generates from scratch based on a vague prompt are not.

I've been building AI agent systems for clients and the pattern that works is iterative: the agent tries something, you steer it, then you capture what worked as a reusable skill. Not "generate skills before solving" but "distill lessons after solving." The paper tests the former, which nobody experienced actually does.

The real value of skills is reducing token burn on repeat tasks. Once you've figured out the right approach, you encode it so next time the model doesn't have to re-derive everything from first principles. It's memoization for reasoning.