This site isn't vibe coded — here's what I'd call it instead

Sun, 02 Aug 2026 00:00:00 GMT

Someone asked me recently whether this site was “vibe coded.” Fair question — AI helped write a lot of the code. But I don’t think that’s the right term, and the distinction is worth making.

What “vibe coding” actually means

When Andrej Karpathy introduced the phrase, he wasn’t describing every project built with AI. He was describing a particular way of working: prompt the model, accept whatever it generates, and keep moving without really reviewing or understanding the output. If something breaks, paste the error back in and let the AI have another go.

The defining feature isn’t that AI wrote the code. It’s that nobody really checked it.

That’s a perfectly reasonable approach for a quick prototype or a weekend experiment. But if you’re building something you’re going to publish for other people to use, the bar is higher. A public-facing website still needs someone to review the output, test it, question assumptions, and understand how it will behave once it’s out in the real world.

Over time, “vibe coding” has been used more broadly to describe almost any AI-assisted coding workflow. I think that misses the important distinction. The interesting question isn’t whether AI was involved — it’s whether someone was still applying judgement throughout the process.

What building this site actually looked like

AI wrote a lot of the code. It also got plenty of things wrong.

Some problems only showed up once I tested the site properly. Others meant reading documentation, comparing framework changes, or adding tooling so the same mistake couldn’t happen again. None of those were solved by blindly asking the AI to “fix it.” They were solved by understanding the problem first, deciding on the right approach, and then using AI as another tool in the process.

That’s the difference I think gets lost.

AI can generate code incredibly quickly, and it’s becoming increasingly capable. Regardless of whether the code came from me or from an AI, it’s still my responsibility to verify it’s the right solution before it ships.

So what do I call it?

There isn’t a universally accepted term yet.

The one that makes the most sense to me is AI-assisted development.

AI can write code, explain unfamiliar concepts, help investigate problems, and speed up repetitive work. But reviewing the output, testing it, deciding what to trust, and understanding why something should be built a certain way still matters.

The label itself isn’t really the point, though.

Whether you use AI a little or a lot doesn’t tell me much about how software was built. What matters is whether you’re willing to question the output, verify it, and take responsibility for the final result.

That’s the difference between using AI as a shortcut and using it as a tool.

DMARC just had its first real rewrite since 2015 — here's what DMARCbis actually changes

Thu, 23 Jul 2026 12:00:00 GMT

In May 2026 the IETF published RFC 9989, RFC 9990 and RFC 9991 — three documents that, between them, replace RFC 7489, the spec DMARC has run on since 2015. Unofficially this is being called “DMARCbis,” and if you manage DNS for a domain that sends mail — which, if you’re reading this, you probably do — it’s worth twenty minutes to understand what actually changed, because some of it changes how you should be writing your DMARC record today.

I went looking into this while tightening up the DNS hygiene on this site’s own domain (praneeth.me runs on Cloudflare, DNSSEC on, the whole checklist), and ended up down a rabbit hole that’s more interesting than “here’s a new DNS tag.” So: what changed, why it changed, and one gotcha that most of the coverage I’ve read doesn’t mention.

Why this update matters more than it sounds

The detail that actually matters isn’t in the technical changes — it’s in the paperwork. RFC 7489 was published via the IETF’s Independent Submission Stream, tagged “Informational.” That’s a real distinction: it means DMARC, despite running a meaningful chunk of the world’s anti-phishing infrastructure for a decade, was never formally endorsed by the IETF. It was a widely-adopted spec that happened to live outside the standards process.

RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) fix that. All three are Proposed Standards on the IETF Standards Track, the product of years of work by the IETF’s DMARC Working Group that picked up pace once the related ARC protocol was published (as Experimental RFC 8617) in 2019. It’s a bureaucratic upgrade more than a technical one — but it’s also the excuse the working group used to clean up a decade of accumulated cruft in the spec, which is where the actual changes come in.

What changed

Organisational domain discovery got a real algorithm. The old spec leaned on the Public Suffix List — a community-maintained, not-quite-authoritative text file — to work out which domain “owns” a DMARC policy. DMARCbis replaces that with a DNS Tree Walk: receivers query DNS hierarchically upward from the From: address looking for a _dmarc record, with built-in limits so a malicious domain can’t force a receiver into an unbounded chain of lookups — however many labels the From: domain has, the walk never issues more than eight queries. Less reliance on an external list nobody formally governs.

A handful of tags are gone, a few are new.

Tag	Status	What happened to it
`pct`	Removed	Percentage-based partial enforcement is gone entirely
`rf`, `ri`	Removed	Report format and interval are no longer sender-configurable
`t`	New	A boolean testing flag, replacing what `pct` used to do
`psd`	New	Lets a domain declare itself a public suffix domain (RFC 9091’s experiment, standardised)
`np`	New	Sets policy specifically for non-existent subdomains

SPF’s role got clarified, not changed. RFC 7489 already keyed DMARC’s SPF check to the MAIL FROM: identity, but its wording left room for receivers to also count a standalone HELO/EHLO SPF pass toward DMARC. The new text closes that reading: DMARC “relies solely on SPF validation of the MAIL FROM identity.” Bounce handling is unaffected — an empty MAIL FROM is still evaluated as postmaster@ the HELO domain, exactly as RFC 7208 has always defined it.

Reporting got simpler and more private. Aggregate reports were already XML in practice; RFC 9990 makes that a MUST. The removed rf tag — which let senders request alternate failure-report formats — is gone, and with ri gone too, receivers now control their own reporting schedule rather than honouring a sender’s requested interval. RFC 9990 is also explicit that aggregate reports contain no identifying information about individual users — no personal mail addresses, no individual IPs, no message content — which matters given how many of them get forwarded to third-party analysis tools.

The tag actually worth your attention: `np=`

Of everything in DMARCbis, np= is the one with real security value — though the gap it fills is subtler than most of the coverage suggests.

Under the old spec, your sp= tag (or p=, if you never set one) applied to every subdomain — ones you’d created and ones you hadn’t alike. So billing.yourdomain.com and payroll.yourdomain.com were never actually policy-free: mail forged from them fell back to your organisational domain’s record like anything else. The real gap was granularity. A domain mid-rollout at p=none or sp=quarantine — the standard cautious path — was forced to be exactly that lenient about subdomains that don’t exist and can never send legitimate mail. Phishing infrastructure lived happily in that leniency window.

DMARCbis splits the two cases: sp= now covers only subdomains that exist, and np= covers the ones that don’t (if you don’t set it, non-existent subdomains fall back to sp, then p):

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:dmarc@example.com"

That’s the record where np= earns its keep: your real subdomains stay at quarantine while you finish rolling out, but mail claiming to come from a subdomain that doesn’t exist gets rejected outright, today. (Already at sp=reject? Then np=reject is harmless but redundant — the fallback gets you the same outcome.)

np=reject — the sensible setting for almost everyone: a non-existent subdomain sends zero legitimate mail by definition, making this the rare enforcement tag where skipping the usual gradual ramp is actually defensible
np=quarantine — routed to spam instead
np=none — monitor only, if you’d rather watch a reporting cycle first

The gotcha: `np=` and DNSSEC don’t always agree on what “non-existent” means

Here’s the part I haven’t seen covered much, and it’s directly relevant if you’re on Cloudflare, Route 53, Azure DNS or NS1 — which between them is a large share of everyone.

np= is defined against a DNS receiver detecting an NXDOMAIN response — the standard “this name doesn’t exist” answer. But a lot of DNSSEC-signed zones don’t actually return NXDOMAIN anymore. RFC 9824 defines “compact denial of existence,” a technique where the authoritative nameserver instead returns NOERROR, with a single NSEC record carrying an NXNAME bit to signal non-existence — cheaper to compute and smaller to transmit than the multi-record proof a traditional NXDOMAIN response needs under DNSSEC.

The problem: a DMARC implementation that strictly checks for NXDOMAIN (as the spec assumes) will see NOERROR from a compact-denial provider and conclude the subdomain exists — silently skipping your np= policy for every non-existent subdomain, on every domain hosted there.

And this isn’t a niche configuration. A December 2024 measurement of the top million domains found compact denial in use on roughly 44% of the ~73,000 domains with valid DNSSEC — it’s the default at Cloudflare (since 2016), NS1 (2019), AWS Route 53 (2020) and Azure DNS (2025). If your DNS is DNSSEC-signed on any of those, np=reject may not actually be doing anything until receivers catch up.

The fix has to happen on the receiving side: implementations need to also recognise the NXNAME bit on NSEC/NSEC3 records as proof of non-existence, not just a literal NXDOMAIN response code. Some already do. Plenty don’t yet. There’s no sender-side workaround — you can’t opt out of your DNS provider’s denial-of-existence method — so the honest answer right now is: treat np=reject as “probably helping,” not “definitely enforced,” until you’ve confirmed your receiving mail providers handle compact denial correctly. Worth re-checking every few months rather than setting and forgetting.

What I’d actually do with this

Drop pct from any record that still has it — DMARCbis receivers ignore it entirely, so a pct=25 you were relying on quietly becomes full enforcement as receivers update. If you still need a soft rollout, that’s what the new t=y flag is for.
Add np=reject even if the rest of your record is still mid-rollout — it only governs subdomains that don’t exist, which can’t send legitimate mail, so the usual none → quarantine → reject ramp buys you little here. If you’d rather be cautious anyway, one reporting cycle at np=none costs nothing — just don’t let it linger the way p=none tends to.
Don’t assume np=reject is airtight if your DNS runs on Cloudflare, Route 53, Azure DNS or NS1 with DNSSEC on — it’s a real layer of protection once receivers support NXNAME detection, but it’s not the hard guarantee the tag name implies today.
Ignore any coverage telling you to re-test your bounce handling — the null-MAIL FROM behaviour didn’t change. An empty MAIL FROM is still evaluated as postmaster@ the HELO domain, exactly as RFC 7208 always specified; what DMARCbis shut down was only the looser reading that a standalone HELO SPF pass could satisfy DMARC on its own.

None of this requires touching a record you’re happy with today — existing records keep parsing fine, since unknown tags have always been ignored by design and no surviving tag changed meaning. (The one caveat is pct, above.) But if you’re setting up DMARC fresh, or tightening an existing policy, it’s worth writing the record against the new spec rather than a decade-old one that just got formally retired.

praneeth.me