DEV Community: Conor Dobbs

Anthropic Is Now the Most Valuable AI Startup. Here's the Developer's Read.

Conor Dobbs — Thu, 11 Jun 2026 21:34:21 +0000

on may 28 anthropic announced a $65 billion series h round at a post-money valuation of about $965 billion, which makes it, on paper, the most valuable ai startup in the world. the round was led by altimeter capital, dragoneer, greenoaks and sequoia, on top of earlier hyperscaler commitments that included around $15 billion with $5 billion of it from amazon. the headline everyone ran with is that anthropic passed openai. that part is true, but the comparison is messier than the headline, and the more interesting story is what is generating the number.

i build small dev tools and write comparison content, and a lot of what i ship runs on top of anthropic's models. so when the company that makes the tools i depend on nearly touches a trillion dollars, i do not read it as a sports score. i read it as a question about whether the thing i am betting on is durable, and what i should do differently because of it. here is the honest version of both.

the number, with the caveats intact

the $965 billion figure is consistent across cnbc, axios, morningstar, al jazeera and euronews, so i trust it. what i would not do is state the gap over openai as a precise fact, because the sources do not agree on openai's number. axios pegged openai's most recent valuation at $730 billion. other outlets put it closer to $850 billion off a record round earlier in the year. either way anthropic is ahead right now, but "ahead by $115 billion" and "ahead by $235 billion" are different sentences, and anyone quoting one as gospel is rounding away the uncertainty. the safe claim is the one i will make: as of late may 2026, anthropic is the most valuably-priced private ai company, and it got there fast. the reporting has it roughly tripling from a $380 billion mark in february.

the part that matters more to me is the revenue. anthropic crossed a $47 billion run-rate earlier in may. that is the line that turns a valuation from a vibe into something with a floor under it. you can argue about whether $965 billion is the right multiple on $47 billion of run-rate revenue, and reasonable people are arguing exactly that. but a $47 billion run-rate is not a story about hype. it is a story about a lot of people paying for something every month.

what is generating it, from where i sit

the reporting attributes a large share of that demand to coding. i cannot give you anthropic's internal revenue breakdown, and i am not going to pretend i can. what i can tell you is what i see at my own small scale, because it lines up. the work that has moved from "interesting demo" to "i pay for this and would be annoyed to lose it" is almost all coding work. claude code sitting in a terminal, reading a real repo, making edits across files, running the tests, is the first version of this category that survived contact with my actual day. the chat-window version was a toy. the agent-in-the-repo version is a tool.

their cfo, krishna rao, framed the raise as helping them "serve the historic demand we are experiencing" and "bring claude to more of the places where work happens." that is corporate-speak, but the second half is the real strategy. the value is not the chat box. it is claude showing up inside the editor, the ci pipeline, the terminal, the places work already happens, so you do not context-switch to use it. that is also, not coincidentally, where the willingness to pay lives. people will expense a tool that closes prs. they will not expense a clever paragraph.

the part the headline skips: this is a platform-dependence story

a valuation headline never says this part out loud. when one company's models become the substrate under a lot of small businesses, including mine, the small businesses are now exposed to that company's roadmap, pricing, and priorities. i felt this directly a few weeks ago when microsoft pulled internal claude code licenses and moved staff to its own tooling. one large customer's procurement decision rippled out as news for everyone building adjacent to the same stack. a $965 billion valuation does not insulate you from that. if anything it raises the stakes, because the pressure to monetize a number that large eventually reaches your invoice.

i am not bearish. i keep building on this stack because right now it is the best version of the tool for the work i do. but i hold it the way you should hold any dependency you do not control. i keep my prompts and my workflows portable enough that the value lives in how i work, not in one vendor's api shape. i pay attention to the providers moving toward open models and cli-first interfaces, because optionality is cheap to maintain and expensive to acquire after you need it. and i treat the model as a component, not a religion.

what i would do with this news

if you are a developer reading the valuation headline, the useful takeaway is not "anthropic won." it is that the coding-agent category is now large enough to fund a near-trillion-dollar company, which means it is not a fad and it is worth getting genuinely good at. the gap i see in practice is not access to the model. everyone has that. the gap is the operating knowledge: how to configure claude code so it reads your codebase instead of guessing, how to structure a claude.md so the agent behaves consistently, when to reach for subagents, how to wire mcp and skills without drowning the context window, and how to review what it produces so you are not shipping the plausible-looking bugs it is happy to write.

that operating knowledge is the actual moat for an individual developer in this cycle, far more than which model is briefly on top. the valuation will move again next quarter. the skill of driving the tool well compounds.

if you want the concrete version of that, the config patterns, the claude.md rules, the subagent and mcp setups, and the review habits, i collected the ones i use into the claude code cookbooks. and if you like these teardowns, i write more of them at tools.thesoundmethod.me.

Resend vs Postmark vs SendGrid — three production accounts later

Conor Dobbs — Sun, 07 Jun 2026 17:20:02 +0000

This post links to Resend and Postmark as affiliate links. I pay for both. I'd recommend the same tools if the affiliate program didn't exist.

I run production accounts on Resend, Postmark, and SendGrid. SendGrid carries a legacy SaaS, Postmark handles a side project's transactional flow, Resend powers everything new. 18 months in parallel. Here's the comparison.

Short version

new projects in 2026: Resend. better DX, modern API, no surprise pricing, the team answers support tickets.

high-reliability transactional with paranoid deliverability tracking: Postmark. best-in-class deliverability and monitoring.

legacy stuff already on it, or you need SMS/voice in the same provider: SendGrid (under Twilio). wouldn't start there in 2026.

Where Resend wins

Modern API. the SDK is small, idiomatic, the docs match reality. send an email with their Node SDK in 3 lines. same for Python, Ruby, Go. no XML, no enterprise-tier gating on basic features.

Domain verification that works. add a domain, paste DNS records, click verify. 5 minutes. Postmark's flow is similar. SendGrid's is a maze of "click here to start the journey..." dashboards.

React Email integration. if your app is React, write your templates in React too. <Button href={...}>Confirm</Button> beats any email template language I've used.

Audiences (mailing lists) built-in. no separate marketing email product to pay for. useful for indie SaaS that needs transactional plus an occasional newsletter.

Reasonable pricing. free tier (3k emails/month). Pro starts at $20/mo for 50k emails. basic features aren't behind enterprise tiers.

Where Postmark wins

Deliverability. Postmark built a reputation as the transactional-only provider that ruthlessly excludes marketing email. that focus shows up as best-in-class inbox placement. their team will email you when your bounce rate spikes.

Bounce and complaint handling. Postmark's dashboard surfaces these where you'll see them. Resend's is decent. SendGrid's is buried.

Detailed activity logs. customer says "I didn't get the email," Postmark finds that exact send in seconds and shows what happened (delivered, bounced, opened, clicked). Resend has this now too. SendGrid charges for Add-Ons to get the same.

Webhook reliability. Postmark's webhooks retry, have a proper status dashboard, don't quietly drop events.

Where SendGrid still wins

SMS + Voice in one provider. Twilio owns SendGrid. if your product needs SMS notifications plus email plus voice, one billing entity matters.

Enterprise compliance. selling to a customer who requires SOC 2 plus GDPR plus ISO 27001 plus HIPAA BAA plus dedicated IPs plus the rest of the compliance kitchen: SendGrid has every certification. Resend is getting there. Postmark has most.

Pre-built marketing campaign tooling. SendGrid's marketing campaign builder is more mature than Resend Broadcasts. not ConvertKit-class, but workable if you want email plus marketing under one roof.

Cost reality

typical SaaS sending 10k emails/month:

Resend: $20/mo (Pro tier, includes audiences)
Postmark: $15/mo (10k transactional plan)
SendGrid: $20/mo (Essentials, watch the add-on charges for activity feed, dedicated IP, etc.)

at 100k emails/month: Resend $35, Postmark $50, SendGrid $90+. Resend wins on price at scale.

The deliverability question

deliverability is mostly about YOUR domain reputation, content, and list hygiene. the provider matters less than people think. all three will land in the inbox if you do the basics right (SPF, DKIM, DMARC, low complaint rate, opted-in recipients).

where the provider does matter: SHARED IP reputation. SendGrid's lowest tier shares an IP with thousands of senders, some of them spammers. if you're starting from zero domain reputation, that can hurt. Postmark gives you a dedicated transactional IP from day 1 on the lowest paid tier. Resend handles IP warmup automatically.

What I do

new projects: Resend. the DX wins.

legacy SaaS already on SendGrid: stay on SendGrid until migration ROI justifies the work.

any product where deliverability is the business (cold-email-as-service, time-sensitive notifications): Postmark.

More production-use comparisons at tools.thesoundmethod.me, written from real use, not vendor PR.

PostHog vs Plausible vs Fathom — which analytics tool to run for your SaaS in 2026

Conor Dobbs — Sun, 07 Jun 2026 01:20:02 +0000

This post contains affiliate links to PostHog, Plausible, and Fathom. I run PostHog in production for product analytics on a SaaS funnel. I evaluated Plausible and Fathom when I wanted lightweight, privacy-first traffic numbers for a couple of marketing sites.

I run PostHog in production to instrument a SaaS signup→activation funnel. I evaluated Plausible and Fathom when all I wanted was clean traffic numbers for a few static marketing sites. People treat these three as competitors. They're not — they answer different questions. Pick the wrong one and you either drown in a product-analytics suite you don't need, or you outgrow a pageview counter in a month.

Short version

You want to answer product questions — "where in the funnel do users drop, which feature drives retention, what does this cohort do" — and you're willing to instrument events: PostHog.

You want traffic questions answered — "how many people hit this page, where did they come from" — with a privacy-first script, no cookie banner, and a dashboard your marketing person can read: Plausible or Fathom.

Between the two simple ones: Plausible if you lean open-source / self-host-optional and want goals + funnels included; Fathom if you want the most polished hosted product and best-in-class uptime with zero ops.

What PostHog actually is (and why it's a different category)

PostHog is a product-analytics platform, not a traffic counter. The unit isn't a pageview — it's an event you define and capture (signup_completed, trace_created, checkout_started). On top of that event stream you get:

Funnels — define an ordered set of events and see conversion + drop-off between each step. This is the whole reason I run it: I can see exactly how many users go signup → email-verified → first-action → checkout, and where they fall out.
Session replay — watch real (anonymized) sessions to see why a step drops.
Feature flags + experiments — ship behind a flag, ramp it, A/B test, all in the same tool that measures the result.
Cohorts + retention — "users who did X in week 1, did they come back in week 4."
Self-host or cloud — open-source core; run it yourself or use PostHog Cloud.

The cost of all that power is instrumentation. PostHog only knows what you tell it to capture. You add a client or server SDK, fire events at the meaningful moments, and design your funnels. That's real work. If you just want "how many people visited the blog," PostHog is wildly over-spec'd and you'll resent the setup.

One real gotcha I hit: server-side captured events lose client context. If you fire events from your backend (e.g. a Cloudflare Worker), the $referrer and $ip PostHog sees are your edge's, not the visitor's — so attribution and "is this real vs test traffic" get muddy unless you also capture client-side or tag events with a source/is_test property. Plan your event schema before you wire it, not after.

Where Plausible wins

Privacy-first by design. No cookies, no persistent identifiers, GDPR/CCPA/PECR-friendly out of the box. No cookie-consent banner needed. The script is ~1KB.

Open source + self-host option. Plausible is fully open-source. Run their hosted version, or self-host on your own box if data residency matters to you or your client.

Goals and funnels included. You don't get product-analytics depth, but you do get conversion goals and basic funnels — more than a pure pageview counter, without the PostHog learning curve.

One clean dashboard. A single page anyone can read: top pages, top sources, countries, devices. No training required. Hand it to a non-technical co-founder and they get it immediately.

Fair pricing on pageviews. Priced by monthly pageviews, and the lower tiers are genuinely cheap for a marketing site.

Where Fathom wins

The most polished hosted experience. Fathom is laser-focused on being the best simple, privacy-first analytics product — and it shows. Fast dashboard, clean UX, sensible defaults.

Bypasses ad-blockers better. Fathom puts real effort into first-party/proxied script delivery so you lose fewer measurements to ad-blockers than a naively-installed third-party script.

Uptime + zero ops. Fully managed, strong reliability track record. You will never think about it. No self-host temptation, no maintenance.

Email reports + uptime monitoring. Scheduled email digests and built-in uptime monitoring are nice touches for solo founders who don't want to live in a dashboard.

Privacy as a first-class promise. Like Plausible: no cookies, no consent banner, GDPR-friendly. Marketed hard on privacy, and it holds up.

Where PostHog wins

It answers product questions, period. Funnels, retention, replays, flags, experiments — Plausible and Fathom simply don't do this. If your question is "why do users churn after onboarding," only PostHog (in this trio) can tell you.

Generous free tier. PostHog Cloud has a large monthly free event allowance, which covers most early-stage products before you pay anything. For a pre-revenue SaaS validating a funnel, this matters.

One tool instead of four. Analytics + session replay + feature flags + experiments + a CDP-lite in one platform. Stitching Plausible + LaunchDarkly + a replay tool together costs more and integrates worse.

Server-side + client-side capture. You can instrument a backend-heavy app (workers, queues, webhooks) where there's no browser at all — something a script-tag-only tool can't do.

The cost reality

Plausible: priced by monthly pageviews; entry tiers are inexpensive for a typical marketing site, and self-hosting is free-as-in-infrastructure if you want it.

Fathom: flat-ish hosted pricing by pageviews across unlimited sites on a plan — attractive if you run several marketing sites under one account.

PostHog: usage-based per event/recording with a large free monthly allowance. Cheap-to-free while you're small; you start paying as event volume grows, and a chatty event schema can run up the bill — so capture meaningful events, not everything.

The decision tree I actually use

Static marketing site, blog, landing page — I just need traffic + sources: Plausible or Fathom.

Several marketing sites I want under one clean account: Fathom.

I want open-source / the option to self-host the simple analytics: Plausible.

A SaaS product where I need to measure a signup→activation→paid funnel: PostHog.

I need feature flags / A/B tests measured against the same event stream: PostHog.

A backend-heavy app with events firing server-side: PostHog (the only one of the three that fits).

What I actually do

I run PostHog on the SaaS funnel because I need to see exactly where users drop between signup and activation — no pageview counter answers that. I reach for Plausible or Fathom on the plain marketing sites, where a privacy-first script and a one-page dashboard are the entire requirement and PostHog would be overkill. The mistake isn't picking the "wrong" tool — it's using one tool for both jobs. They're not substitutes.

Migrating from Go to Rust: The Tradeoffs Worth Knowing First

Conor Dobbs — Sat, 06 Jun 2026 21:20:04 +0000

A migration guide from the Rust consultancy corrode reached the front page of Hacker News this week (458 points, 461 comments). It walks through moving a Go service to Rust, and the thread split the way these threads always do: half the room wants to rewrite everything, the other half calls the rewrite a waste. Both camps miss the same point. The decision is rarely about the two languages in the abstract. It is about the one specific service sitting in front of you.

I run a site that compares developer tools, so I read a lot of "X vs Y" content. Most of it argues in the abstract and lands nowhere. This guide is worth your time because it grounds the comparison in what changes when you move real code, and it stays honest about the parts that get worse. Here is the grounded version, checked against a few independent sources.

What gets better

Error handling stops being a convention and becomes a type. Go returns a (value, error) tuple and trusts you to check it. The compiler will happily build a function that ignores the error, which is why teams bolt on linters like errcheck. Rust returns Result, and the compiler refuses to let you touch the value until you handle the failure path. The ? operator threads errors up the stack, and with a #[from] attribute it converts error types for you. The boilerplate you write by hand in Go is structural in Rust.

The nil pointer goes away. A nil dereference in Go is a runtime panic, and linters catch it probabilistically at best. Rust has no null. Absence is Option, and the compiler makes you open the box before you read what is inside. For a service that has paged someone at 3am over a nil map access, that property alone earns the evaluation.

Data races turn into compile errors. Go's -race detector is good, but it only finds races that happen to run while your tests run. Rust encodes thread-safety in the Send and Sync traits, so the compiler rejects unsafe sharing before the binary ever executes. The Go habit of a sync.Mutex guarding a map becomes Arc>> in Rust. More verbose, yes, and the verbosity is the safety.

The resource numbers are real, with one caveat. The corrode guide cites a 20-40% CPU improvement and a 30-50% memory reduction across production migrations, most of it from dropping the garbage collector and its P99 latency jitter. Read those as the consultancy's reported range, not a promise for your workload. The direction held across every independent comparison I checked.

What gets worse

Function coloring is the tax everyone underestimates. In Go you write a function and call it; goroutines never change a signature. In Rust, async fn and .await split your code in two, and synchronous code cannot call async code without an executor. Every source I read, including people glad they switched, named this as the single biggest day-to-day regression coming from Go. It is the thing Go developers miss most after the move.

Compile times go from instant to minutes. Go's near-instant build is part of how the language feels. A clean release build of a medium Rust service can take minutes, and the guide flatly calls that "a real downgrade." If your team's loop depends on fast rebuilds, measure it before you commit, not after.

The first service takes three to six times longer to ship. The borrow checker is a wall and you hit it in week one. The honest estimate, repeated across sources, is that developers new to Rust stay meaningfully less productive for three to six months. Budget formal training instead of learning while shipping, or the timeline slips in silence.

The ecosystem still has holes. Rust's crate registry is large, but Go owns a few backend-adjacent niches outright: Kubernetes operators, several cloud SDKs, particular database drivers. The guide warns that migrating teams often hand-roll one or two core libraries themselves. That is a real line item, not a footnote you can wave away.

The decision that counts

The useful sentence in the corrode guide is the one most rewrite-everything threads skip: not everything should be migrated. It recommends keeping Go for CLI utilities, Kubernetes tooling, and any service where team velocity matters more than absolute correctness guarantees.

So the calibration comes out clean. Migrate the service where a nil deref or a data race becomes a production incident and the latency floor is a contract: payment paths, stateful coordinators, anything carrying a tight P99 SLA. Keep Go for the glue: internal tools, operators, the service whose whole value is that a junior shipped it on Friday afternoon. The two languages are not competing for the same job. The migrations that go badly are the ones that pretend they are.

If you are weighing the move, run the smallest honest experiment you can. Pick one self-contained service, port it, and time the work end to end. Track the compile times, the review friction, and how long the borrow checker holds you up. The numbers you measure on your own code beat any blog post on the internet, this one included.

A migration is a bet on where your incidents come from. If your pages are nil derefs, data races, and GC pauses, Rust moves those failures from runtime to compile time, and that trade pays for itself. If your pages are missed deadlines and onboarding drag, Rust adds to the column you are trying to shrink. Name your failure mode first, then pick the language that kills it.

If you are setting up either side of this, I keep practical configuration kits for both: a Go Development Cookbook and a Rust Development Cookbook, each with CLAUDE.md rules, editor hooks, and project patterns wired in. They will not make the borrow checker friendlier, but they cut the first-day setup friction so you reach real code faster.

Sources

corrode, "Migrating from Go to Rust": https://corrode.dev/learn/migration-guides/go-to-rust/
JetBrains RustRover blog, "Rust vs Go: Which One to Choose": https://blog.jetbrains.com/rust/2025/06/12/rust-vs-go/
LogRocket, "Go vs Rust: When to use Rust and when to use Go": https://blog.logrocket.com/go-vs-rust-when-use-rust-when-use-go/

More from-real-use language and tooling tradeoff writeups at tools.thesoundmethod.me — decisions made from shipping, not benchmarks in isolation.

Microsoft pulled internal Claude Code licenses — what their engineers' preference tells you about picking AI tools

Conor Dobbs — Sat, 06 Jun 2026 17:20:02 +0000

This post contains affiliate links to Claude Max, Cursor, and Aider. I pay for all three out of pocket. The recommendations would be identical without the affiliate program.

If you read the headline as "Microsoft killed Claude Code," close that tab and breathe. Two-thirds of the takes circulating got the framing wrong. Here is what happened, why most readers are not affected, and the one signal in this story worth your attention if you are picking AI coding tools.

What happened

On May 14, 2026, The Verge's Tom Warren reported that Microsoft is canceling internal Claude Code licenses for thousands of developers in its Experiences and Devices group, the team that builds Windows, Microsoft 365, Outlook, Teams, and Surface. The cutoff is June 30, 2026. Affected engineers are being moved to GitHub Copilot CLI, Microsoft's own command-line AI coding tool.

Three details the headline does not carry:

This is internal Microsoft employee tooling, not a customer-facing 365 Copilot product change. External customers do not have Claude Code through a Microsoft subscription to lose.
Anthropic's models remain accessible at Microsoft. They stay reachable inside Microsoft Foundry and inside Microsoft 365 Copilot for specific tasks. The partnership is not ending. Microsoft is pulling the Claude Code interface, not the underlying model.
The official reason is "toolchain unification." The timing lines up with Microsoft's fiscal year-end, which means the unstated reason is cost.

For practically everyone reading this, your Claude Code subscription, your Cursor subscription, your Aider workflow, your Claude.ai chat habit are all unchanged. The story is internal company tooling drama at one company.

So why is it interesting

Because of who picked what before Microsoft started pulling licenses.

Microsoft gave Claude Code access to thousands of internal employees in December 2025. The rollout went beyond engineers; it included designers, PMs, and non-technical staff. Tom Warren's reporting summarized the result in one line: Claude Code "proved very popular inside Microsoft."

Many of those engineers preferred Claude Code over Microsoft's own GitHub Copilot CLI, which was launching into the same internal slot at roughly the same time. Microsoft's own product organization built Copilot CLI, shipped it to their own people, and watched them quietly pick the competitor's tool instead.

That is about as honest a comparison signal as you get in this market. Benchmarks are tunable. Marketing is paid. Vendor demos are scripted. But Microsoft engineers, on Microsoft hardware, picking the competing tool over the in-house one, with no incentive to embarrass their employer, with full IT support either way, is the kind of insider preference data point that is almost impossible to fake.

The followup decision is the second signal. Microsoft pulled the licenses anyway. Read that two ways at once: cost-cutting matters more than internal preference at a certain dollar volume, AND the leadership decision is "consolidate on the homegrown tool" even when the homegrown tool is the one being passed over. Both data points are worth carrying into your own tool-selection conversations.

What this means for how you pick

If you are picking an AI coding tool right now, the four real options are the same as they were last week. The insider-preference signal does not change the decision tree, it sharpens it.

Claude Max, $100/mo direct from Anthropic

Claude Code with a Max subscription is the cleanest path. Same model, same agentic terminal experience that Microsoft engineers liked, direct billing relationship with no bundle-deal politics in the middle. Best for anyone whose work is meaningfully autonomous (build feature X, run tests, fix failures, commit), or for anyone who would hit API ceilings on pay-per-use anyway.

Cursor Pro, $20/mo, Anthropic models via Cursor's relay

Cursor's $20/mo Pro plan gets you Anthropic models without paying Anthropic directly. The trade-off is editor experience. You are in Cursor's IDE (a VS Code fork) using their composer and tab-edit flow instead of Claude Code's terminal session. Different mental model. Better for inline editing in a codebase you know cold, weaker for autonomous "go figure out feature X" work.

Aider plus your own Anthropic API key

Aider with a bring-your-own API key has no subscription floor. Pay per token. For 2-3 focused hours per week, costs less than $20/mo. For full-time use, costs more than Max. Best for terminal natives who already live in tmux and do not want a separate IDE.

GitHub Copilot CLI plus Claude through Foundry

The path Microsoft is moving its own engineers onto. Worth taking seriously precisely because Microsoft, knowing its own people preferred the competitor, still made this call. Reasonable if your environment forces Microsoft-only tooling, or if your team is already deep on the Foundry / 365 stack. The Claude models stay available; you lose the Claude Code interface specifically.

The honest read on each

Max wins on DX and on the "what the people who got to choose actually chose" signal.

Cursor Pro wins on inline-editing experience. Composer is unmatched for "edit this, then that, then add a test."

Aider wins on flexibility and floor cost. Best for occasional use, terminal-native workflows, and the "open source matters for my client's IT department" case.

Copilot CLI plus Foundry wins on enterprise integration. Worth running for a week if you are tied to Microsoft tooling. The fact that engineers preferred the competitor on a free in-house deployment is information; it does not make the tool unusable.

What this signals about the AI editor market

Bundle deals are unstable when the marginal cost of the bundled thing is high. AI tokens cost real money per call. The "include AI in your suite" pitch works at low-touch use and breaks at power-user volume. Microsoft canceling internal Claude Code licenses for cost reasons, at a company that famously prints money, is the first big public datapoint that AI coding tools have a budget problem even at the largest possible org scale.

Anthropic will keep building direct-relationship moats: Max tiers, Claude.ai, Claude Code, the MCP ecosystem. Microsoft will keep pulling AI-coding spend into its own Copilot lineup and pricing it inside the 365 wrapper. The middle tier (Cursor, Continue, Aider, the IDE-relay pattern) stays interesting because it is neutral on the billing question and lets you switch models without switching editors.

What to do this week

If you are a Microsoft employee in the affected group, the migration plan is set for you. If you are anyone else, no action is required this week. Your subscriptions work. Your model access is intact.

If you are picking a tool, weight the insider-preference signal honestly. Microsoft's own engineers preferred Claude Code over Microsoft's own Copilot CLI when both were free and supported. That is the strongest comparison data point you will get this year.

For a deeper decision tree across Cursor, Claude Code, and Aider with concrete task-type recommendations, that one is at tools.thesoundmethod.me/posts/cursor-vs-claude-code-vs-aider.html. If you are staying on Claude Code, the Claude Code cookbooks bundle the patterns I use day to day.

Sources

Canonical: tools.thesoundmethod.me

LLM Smells: The Tells in AI Writing, and the Costlier Ones in AI Code

Conor Dobbs — Sat, 06 Jun 2026 01:20:02 +0000

there is a piece by shrijal shrestha called "various llm smells" that put words to something i think a lot of us have been feeling but not naming. the argument is simple: ai-assisted work leaves a residue. once you have seen enough of it, you can spot it instantly, the same way you can hear autotune. he calls it ai-smell, and his point is that it shows up across very different tasks. writing has its tells. websites have their tells. and now that the tools are everywhere, the tells are everywhere too.

i build comparison content and small dev tools, and i run a content pipeline that posts to real communities, so this is not an abstract aesthetics debate for me. i have a humanizer step in my own stack whose entire job is to strip these tells out before anything goes public, because the tells are not free. so i want to take shrestha's observation seriously, extend it to the place it costs real money, and tell you what i actually do about it.

the writing tells

the prose smells he points at are the ones you already half-noticed. the constant punchline cadence, where every few sentences lands a quotable little zinger. the run of three short sentences in a row for fake emphasis. the "x is the y of z" metaphor that sounds clever and says nothing. and the rhetorical move where a sentence sets up a contrast it does not earn. none of these are wrong on their own. a human writer uses all of them. the smell is the density. the model reaches for them constantly because they are cheap and they pattern-match to "good writing," and the result reads like someone doing an impression of insight.

the design tells are the same story in a different medium. the jetbrains mono font on a marketing page. every step in a list styled identically. uniform card components, the same button treatment, the little blinking-dot "live" badge that every ai-scaffolded landing page now ships with. shrestha is careful to say he is not against using these tools, and neither am i. the point is recognition, not purity.

here is why it matters beyond taste. i have watched what these tells do in the wild. communities flag them. moderators and automated filters treat the cadence as low-effort spam, sometimes correctly. readers discount the content the moment they clock it. that is the whole reason my pipeline runs every draft through a humanizer before it touches reddit or anywhere else. the smell is a signal, and the signal people read is "nobody actually cared about this." in a feed that is already drowning in generated text, that signal gets you ignored at best and removed at worst.

the same smell in code, where it gets expensive

prose smell is annoying. code smell is a bill. and ai-generated code has its own recognizable residue once you have reviewed enough of it.

you learn the patterns fast. the redundant defensive checks for conditions that cannot happen. the dead variable that gets assigned and never read. the function that reimplements something already three files over, because the model could not see the rest of your codebase and had no reason to look. the comment that restates the line below it in english. the solution that solves the problem exactly as stated, which is the problem, because the stated problem is usually a little different from the real one. the model does not know your table has fifty million rows or that the endpoint gets hammered ten thousand times a second. it answers the prompt, not the system.

the difference from prose is that here the cost is measured, not felt. veracode ran 80 curated tasks across more than 100 models in their 2025 genai code security report and found that 45% of the generated code introduced a security flaw, against a human baseline closer to 25-30% on the same kind of testing. it gets worse by language and category. java-generated code failed security checks more than 70% of the time. cross-site scripting came in at an 86% failure rate, log injection at 88%. these are not exotic bugs. they are the boring cwe entries that have been on every checklist for fifteen years, and the model ships them while sounding completely confident.

there is a quieter cost too. a 2026 study on ai-generated pull requests found measurably more code and measurably less reuse than human prs, which is technical debt arriving silently because the surface looks fine. the code reads plausible, passes a glance, and quietly duplicates logic you already had. you do not notice until the third copy drifts out of sync.

why you cannot smell-check ai with more ai

the obvious move is to point a second model at the first model's output and call it review. it half works and it hides a trap. when the generator and the reviewer reason from the same artifact, they fail in correlated ways. the reviewer checks the code against the code, not against what you actually meant. and models are sycophantic, so a reviewer model will often agree with a confident wrong answer rather than push back. you end up with two ai's nodding at each other while the cwe-89 sql injection sails through.

so the review has to be anchored to something the model did not write. that means a few unglamorous habits. write the intent down as an executable spec or a test before you accept the code, so there is an external thing to check against. review for architecture and reuse, not just syntax, because syntax is exactly what the model gets right and structure is what it gets wrong. and run the security tooling you would run on any code, because "an ai wrote it" is not a clean bill of health, it is the opposite.

the through-line from shrestha's piece holds in both worlds. the smell is a tell that the work was generated and not yet owned. in prose you fix it by actually rewriting in your own voice. in code you fix it by actually reviewing against your own intent. the tool is fine. the residue is the part you are still responsible for.

if you want the concrete version of the code half, the test patterns, the review checklist, and how to anchor an ai's output to a spec instead of trusting it, i pulled them together in the claude code testing cookbook. and if you like these teardowns, i write more of them at tools.thesoundmethod.me.

sources

shrijal shrestha, "various llm smells": https://shvbsle.in/various-llm-smells/
veracode 2025 genai code security report (45% of ai-generated code contained a security flaw; java >70%): https://www.veracode.com/blog/genai-code-security-report/
"more code, less reuse: investigating code quality and reviewer sentiment towards ai-generated pull requests" (arxiv 2601.21276): https://arxiv.org/pdf/2601.21276

Learn SQL Once, Use It for 30 Years: Why the Skill Doesn't Expire

Conor Dobbs — Fri, 05 Jun 2026 21:20:03 +0000

A post titled "Learn SQL Once, Use It for 30 Years" hit the front page of r/programming this week (307 points, 48 comments). The claim sounds like the kind of thing a database vendor would put on a billboard, so I went looking for the part that holds up. It turns out the longevity is not marketing. It is a property of how the language was designed, and it is the reason SQL is one of the few skills on a developer's resume that does not quietly expire.

I run a site that compares developer tools, which means I spend a lot of time watching technologies rise, peak, and get replaced. Most of what you learn in this field has a half-life measured in single-digit years. The framework you mastered in 2019 is legacy by 2024. SQL is the strange exception, and the reasons are worth understanding before you decide where to spend your next month of learning.

Where the staying power comes from

SQL did not start as a language. It started as a math paper. In 1970, Edgar Codd published "A Relational Model of Data for Large Shared Data Banks," which proposed organizing data into tables of rows and columns with formal rules for combining them. IBM built a query language on top of that model in the mid-1970s, called it SEQUEL, and later renamed it SQL after a trademark conflict. The important detail is the order: the model came first, the language second. SQL is a surface over a mathematical foundation that has not needed to change.

That foundation is why the skill compounds instead of decaying. When you learn SQL, you are not memorizing one vendor's API. You are learning the relational model, and the model is the same whether the data sits in Postgres, MySQL, SQLite, Oracle, or SQL Server. A join is a join everywhere. Move from one database to another and the syntax shifts at the edges, but the way you think about the problem carries over intact. Compare that to a frontend framework, where moving stacks means relearning how to think, not just how to type.

Declarative is the whole trick

The second reason SQL lasts is that it is declarative. You describe the result you want, and the database figures out how to get it. You write SELECT name FROM users WHERE active = true, and you never specify whether the engine should scan the whole table, walk an index, or load the rows in some particular order. That decision belongs to the query planner.

This is a bigger deal than it looks. Because you only ever stated the what and never the how, the database is free to change the how underneath you without breaking your query. Hardware gets faster, planners get smarter, storage engines get rewritten, and the exact same SQL you wrote a decade ago keeps working and often runs faster than it did the day you shipped it. Imperative code does not get this gift. Code that spells out every step is frozen to the assumptions it was written under. SQL ages in the opposite direction, because the contract is the result, not the procedure.

A standard that refused to fragment

The third reason is boring and load-bearing: SQL got standardized early and stayed standardized. ANSI adopted it as a formal standard in 1986 (X3.135-1986), and ISO published a technically identical version in 1987 (ISO 9075). That standard has been revised steadily ever since, through the version maintained today as ISO/IEC 9075. New capabilities like window functions, common table expressions, and JSON support arrived as additions, not as a reinvention that orphaned what came before.

The payoff is that the core you learn is portable across vendors and stable across decades. A GROUP BY from 1995 still means the same thing. Most languages and frameworks cannot make that promise, because they were never standardized by anyone and their "spec" is whatever the maintainers shipped last release.

The honest caveats

The 30-year claim is real, but it is not a free pass, and the honest framing matters more than the slogan. SQL is portable at the core and divergent at the edges. Every database has its own dialect for the parts the standard left open: how you page results, how you handle dates, how you do upserts, how you write a recursive query. The mental model transfers cleanly. The exact string sometimes does not, and a query tuned for one engine's planner can behave differently on another. "Learn once" buys you the concepts everywhere; it does not buy you zero friction when you switch vendors.

There is a second caveat the headline skips. SQL being durable does not make it the right tool for every shape of data. Heavily nested documents, graph traversals many hops deep, and append-only event streams at extreme volume each have stores built for them that will beat a relational database at their specific job. The relational model earns its keep across a huge share of real applications, which is exactly why the skill pays off, but "use it for 30 years" is a statement about SQL's longevity, not a claim that it is the only data tool you will ever need.

What this means for where you spend your time

Put the three properties together and the conclusion is hard to argue with. SQL rests on a model that has not changed in fifty years, it is declarative so it gets faster without you rewriting it, and it is standardized so the core travels across every vendor you will ever touch. The skill does not depreciate the way almost everything else in this field does. An hour spent getting good at joins, indexes, and query planning pays out for the rest of your career, while an hour spent on this quarter's hot framework starts losing value the moment you close the tab.

If you build on a typical web stack, you are already sitting on top of SQL whether you write it directly or hide it behind an ORM, and the developers who can drop down to the query when the ORM gets in the way are the ones who debug the slow page instead of guessing at it. For wiring a database cleanly into a Node or Go service, I keep practical setup kits for both: a Full-Stack TypeScript Cookbook and a Go Development Cookbook, each with CLAUDE.md rules, editor hooks, and project patterns already wired in so the database layer is one less thing to assemble from scratch.

The practical move is unglamorous. Pick the database you already run, open a real query against real data, and learn what the planner does with it using EXPLAIN. That single habit, repeated, is how the 30-year skill accrues. Frameworks will keep cycling through underneath you. The relational model that Codd wrote down in 1970 will still be there, doing the same job, waiting for the next person who took the time to learn it once.

I write more of these durable-skill and from-real-use engineering pieces at tools.thesoundmethod.me.

Is MCP Dead? When the Model Context Protocol Earns Its Complexity

Conor Dobbs — Fri, 05 Jun 2026 17:20:03 +0000

a post titled "mcp is dead" hit the front page of hacker news last week with 311 points and almost 300 comments. that is the kind of headline that makes you click and then makes you roll your eyes, because nothing in this space dies on a six-month timeline. so i read the argument, pulled the numbers, and checked what the people building these protocols are saying. the short version: mcp is not dead. the idea that you should wire every tool you own into an mcp server is the thing that is dying, and that distinction matters if you are deciding what to build this year.

what people are angry about

the model context protocol, for anyone who skipped the hype, is a standard anthropic shipped in november 2024 so language models can talk to external tools and data through one consistent interface. think of it as a common plug. the pitch was good. you write one server, any compatible model can use it.

the complaint is about what that plug costs you. every tool an mcp server exposes ships its full definition into the model's context window on connect. the name, the parameter schema, the response format, all of it. the quandri writeup that started the latest round measured it: four servers connected, 77 tools, and 21,077 tokens gone before the model reads a single word from you. that is 10.5% of a 200k context window spent on definitions you mostly will not call. the linear server alone ate around 12,807 tokens for 42 tools when the author only ever used two of them.

then there is speed. the same teardown clocked mcp calls at roughly 3x slower per call and 9.4x slower on the first call once you count server initialization. add the failure modes anyone who has run these knows by heart: a server that will not start, mid-session auth that expires, a tool that dies halfway through a task and takes the run down with it.

this is not a fringe gripe. in march, perplexity's cto denis yarats said at their ask 2026 event that the company is moving away from mcp internally toward plain apis and command-line tools, citing the same context-window waste and clunky auth. that got picked up everywhere because it is a real signal from a team running agents at scale, not a hot take.

the part the headline skips

here is what gets lost when "mcp is dead" goes viral. anthropic, the company that created mcp, published its own engineering post on the same problem, and their framing is the opposite of a funeral. they call mcp the de-facto standard with thousands of community servers, and then they show you how to stop it from burning your context.

their fix is code execution. instead of the model picking from a wall of tool definitions and passing every intermediate result back through itself, you present mcp servers as code apis the model writes against. it discovers tools by exploring a filesystem and loads only the definitions the current task needs. their worked example takes a job from 150,000 tokens down to 2,000 tokens. that is a 98.7% cut, and it comes from filtering data before it ever reaches the model rather than streaming a two-hour meeting transcript through the context twice.

so the protocol is not the problem. loading everything eagerly is the problem. mcp is growing up, not dying.

what i would reach for

i build comparison content and small tools for a living, and i run agents against my own stack all day, so this is a practical question for me and not a debate-club one. the rule i have landed on is boring and it holds up.

reach for a cli first. if a service has a decent command-line tool, the model already half-knows it from man pages and stack overflow, it costs zero tokens in definitions, and you get one interface that humans and agents share. reach for skills next when you have a multi-step workflow worth documenting, because the instructions load only when the task calls for them. reach for a plain api call when you need something specific and fast.

mcp earns its place in a narrower set of cases than the 2024 hype suggested, and those cases are real:

the service has no cli and lives entirely behind a web ui
your users are not developers and a terminal is a non-starter
you need server-side guardrails, like query validation that refuses a DROP TABLE against a shared production database before it ever runs
you need real bidirectional communication rather than request and response

that database case is the one i would not give up. a cli cannot enforce access control that lives on the server. an mcp server can. when the blast radius is a shared prod database, the protocol overhead buys you safety, and that is a fair trade.

why this matters if you are building

the lesson is not "pick a side." it is that the interface between a model and your tools is a design decision with a measurable cost, and most teams were treating it as a default. if 10 to 50 percent of your context is gone before the work starts, your agent is dumber and slower for no reason, and you are paying for it on every call.

so audit what you connect. count the tools you expose against the tools you call. if you are running mcp, look at whether code execution or progressive loading cuts your token bill the way anthropic's numbers suggest it can. if a cli already exists, ask whether you need the server at all. and if you are going to build an mcp server, build it for the cases where it wins, with the access control and the bidirectional bits that justify it, instead of wrapping a rest api you could have called directly.

that last point is where most of the pain comes from. people build mcp servers because mcp is the thing you are supposed to build, not because the use case needed one. a well-scoped server that does one job with real guardrails is worth keeping. a server that exists to check a box is the 12,807 tokens you will resent later.

mcp is not dead. the reflex to connect everything through it is. build the server when the job calls for it, and reach for the cheaper interface the rest of the time.

if you want the patterns for building mcp servers that earn their keep, the structure, the tool design, the guardrails, i collected them in the mcp server cookbook. and if you are weighing protocols and tools more broadly, i write these teardowns over at tools.thesoundmethod.me.

sources

quandri engineering blog, "mcp is dead": https://www.quandri.io/engineering-blog/mcp-is-dead
anthropic engineering, "code execution with mcp": https://www.anthropic.com/engineering/code-execution-with-mcp
perplexity cto denis yarats moving from mcp to apis and clis, reported march 2026

Durable Workflows on Postgres: What "You Don't Need Temporal" Actually Buys You

Conor Dobbs — Fri, 05 Jun 2026 01:20:02 +0000

A DBOS blog post titled "Postgres is all you need for durable execution" reached the Hacker News front page this week (306 points, 132 comments). The thread split the way these threads always do. One half read it as relief: no more standing up a separate workflow service only to make a multi-step job survive a crash. The other half read it as a warning: you are about to put orchestration load on the same database that already runs your app. Both reactions are correct, and which one applies to you depends on a question the headline skips.

I run a site that compares developer tools, so I read a lot of "X vs Y." Durable execution is one of the categories where the architecture choice matters far more than the brand on the box. Here is the grounded version, checked against DBOS's own docs, an independent write-up from Supabase, and the source libraries themselves.

What durable execution solves

Picture a function that runs five steps and crashes on step four. Steps one through three already happened, step four half-happened, and a naive retry runs all five again. If step two charged a customer, you charged them twice. Durable execution fixes this with checkpointing. Each step records its result before the next one starts, so a crash-and-restart resumes from the last completed step instead of the top. The promise is that a workflow finishes exactly once even if the machine running it dies in the middle. Payment capture, order fulfillment, any multi-step process where a double-run costs real money is the use case that makes this worth the effort.

How the Postgres approach works

The traditional model, used by systems like Temporal, runs a separate orchestrator. A central service holds the workflow state and hands tasks out to workers over the network. DBOS's argument is that the database can play that role directly, so you skip the extra service entirely.

Mechanically, the workers checkpoint each step straight to Postgres as they go, rather than reporting back to an orchestrator. State lives in ordinary tables. When a server crashes, another server reads the latest checkpoint and resumes the workflow from its last completed step. Duplicate work gets caught the way Postgres catches any duplicate: with integrity constraints. If two workers grab the same workflow, the second one fails the constraint on checkpoint and backs off.

The exactly-once claim is the part worth understanding, because it is where the database earns its keep. DBOS runs a step and writes its checkpoint inside the same Postgres transaction. The work and the record of the work commit together or not at all, which closes the gap where a step succeeds but the system forgets it did. Systems that keep workflow state in a separate service typically settle for at-least-once delivery and ask you to make every step idempotent yourself.

Two smaller properties fall out of putting everything in one database. Queues become a SELECT ... FOR UPDATE SKIP LOCKED off a table, so workers cooperatively pull jobs without a separate broker. And observability is plain SQL: "how many workflows are stuck on step three" is a query you already know how to write, not a dashboard you have to buy.

What you give up

None of this is free, and the honest framing matters more than the pitch. Putting workflow state in your primary database means your workflow load and your application load share one Postgres instance. For modest volumes that is a feature, because it is one fewer system to run, back up, and reason about. At high throughput it becomes a coupling you have to plan around, since a workflow spike now competes with user queries for the same connections and I/O.

There is a subtler caveat too. The exactly-once guarantee is exactly-once for the database write, not for the outside world. A step that calls a third-party API and crashes after the call but before its checkpoint commits can still fire that call twice on recovery. The transaction protects the part Postgres owns; anything reaching past the database still wants an idempotency key. That is true of every durable execution system, and it is the line item people skip when they read "exactly once."

Temporal earns its complexity at the other end of the curve. It is language-agnostic by design, it separates orchestration from your data store so the two scale independently, and it carries years of production mileage at serious scale. The price is real: you rearchitect your code around a worker and a client, you run or pay for the Temporal service, and you operate one more piece of infrastructure. DBOS asks for none of that, in exchange for living inside the database you already have.

The decision that counts

So the calibration comes out clean, the way it does for most infrastructure choices. If you already run Postgres, your workflow volume is bounded by your application's volume, and you want the smallest number of moving parts, the database-backed approach removes an entire service from your diagram and hands you transactional exactly-once for free. That description covers a large share of real applications.

Reach for a dedicated orchestrator when the workflow load is genuinely independent of your app, like fan-outs that dwarf your user traffic or pipelines that need to scale on their own schedule, or when you need polyglot workers and a managed control plane more than you need fewer systems. The mistake in both directions is identical: picking the architecture for the logo instead of for where your load really comes from.

The libraries that implement the Postgres approach, DBOS among them, ship for TypeScript, Go, Python, and Java, so you can adopt durable execution without leaving your existing stack. If you are wiring it into a Node or Go service, I keep practical setup kits for both: a Full-Stack TypeScript Cookbook and a Go Development Cookbook, each with CLAUDE.md rules, editor hooks, and project patterns already wired in. They will not write your workflows for you, but they cut the first-day setup so you reach the interesting part faster.

Durable execution used to mean adopting a platform. The Postgres approach reframes it as a library decision, which is a much smaller bet and a much easier one to reverse. Start with the one workflow that currently ruins your day when it half-completes, make it durable, and watch what a crash does to it now. The behavior you see on your own code settles the architecture argument faster than any blog post, this one included.

Sources

DBOS, "Postgres Is All You Need for Durable Execution": https://www.dbos.dev/blog/postgres-is-all-you-need-for-durable-execution
DBOS Architecture (official docs): https://docs.dbos.dev/architecture
Supabase, "Running Durable Workflows in Postgres using DBOS": https://supabase.com/blog/durable-workflows-in-postgres-dbos

I build small reliability tools on exactly this kind of Postgres-first plumbing (cron dead-man's-switch monitoring, request tracing). More writeups and the tools at tools.thesoundmethod.me.

Defender zero-days CVE-2026-41091 and 45498 — what defenders should do today (May 2026)

Conor Dobbs — Thu, 04 Jun 2026 21:20:02 +0000

Microsoft published two Defender vulnerabilities on May 19, 2026 that are being actively exploited in the wild, and CISA has already pushed both into the Known Exploited Vulnerabilities catalog. If you run Windows endpoints, this is a same-week update item, not a "schedule it for the next maintenance window" item. The patches exist, the abuse is happening, and the BOD 22-01 deadline for federal civilian agencies is June 3, 2026.

what follows: what happened, who needs to act, and what to do today before someone else makes the decision for you.

What's being exploited

CVE-2026-41091 is an Elevation of Privilege bug in Microsoft Defender's scanning logic, rated Important. The root cause is improper link resolution before file access. An authenticated local attacker plants symbolic links or NTFS junctions that point at attacker-controlled paths, then triggers Defender to follow them. Defender operates with SYSTEM privileges during scan operations, so the file actions Defender performs on those crafted targets execute as SYSTEM. Net result: a non-admin local user gets full SYSTEM on the host.

The attacker needs an authenticated session already. That sounds like a high bar until you remember that initial-access malware lands at user-level, then chains a local privilege escalation to get persistence and lateral-movement capability. CVE-2026-41091 is the second-stage tool intrusion sets are looking for. The Hacker News and BleepingComputer both confirm the in-the-wild abuse is happening.

CVE-2026-45498 is a Denial of Service in the Microsoft Defender Antimalware Platform itself. Attackers can trigger a platform-level crash that takes Defender's protection capabilities offline. The exploitation pattern here is the obvious one: kill the EDR/AV before deploying the actual payload, get a clean window for follow-on actions, restore Defender or leave it broken depending on how careful the operator is. CISA's KEV listing tells you this is being chained operationally, not a theoretical concern.

Both vulnerabilities affect core Defender components on all supported Windows releases. Server SKUs, client SKUs, enterprise plus home editions. If Defender is the security control on the box, the box is in scope.

Who needs to care this week

You care if:

You operate Windows endpoints with Defender as the primary AV/EDR
You're a SOC analyst monitoring Defender telemetry
You manage a federal civilian agency endpoint fleet (BOD 22-01 deadline June 3, 2026)
Your incident response runbook assumes Defender is the canary that flags initial compromise

You can probably defer if:

Your endpoint protection is CrowdStrike Falcon / SentinelOne / Sophos, or any third-party EDR that has displaced Defender entirely. Defender may still be present but inactive
You're on a Mac or Linux fleet
Your Windows hosts are air-gapped and the threat model genuinely doesn't include authenticated local users

For everyone else, this is patch-this-week material.

What defenders should do today

Verify your Defender platform version. The fixed versions are 1.1.26040.8 (Antimalware Client) and 4.18.26040.7 (Antimalware Platform). PowerShell: Get-MpComputerStatus | Select-Object AntivirusSignatureVersion, AMEngineVersion, AMProductVersion. If your AMProductVersion is below 4.18.26040.7, you are exposed.
Push the update via your normal channel. Microsoft Defender updates ship through Windows Update + the Defender platform update mechanism (separate from the OS patch cycle). Most enterprises have this on auto-update, but plenty have it gated behind change windows. If yours is gated, this is the cycle where you unblock it.
Audit symlink/junction creation in user-writable paths. CVE-2026-41091 hinges on attacker-planted links. If you can detect or block user-mode symbolic link creation outside known-good paths, you have a compensating control while the update rolls out. Sysmon Event ID 11 (FileCreate) on *.lnk, *.junction, or any rapid CreateSymbolicLink API calls from non-admin processes is the telemetry to grep for.
Hunt for Defender service interruptions. CVE-2026-45498 manifests as Defender crashing. Event ID 5007 in the Windows Defender operational log, plus any unexpected stop of MsMpEng.exe. If you're seeing Defender crashes that pre-date the patch on hosts you care about, that's potentially active exploitation already, not noise.
Tighten EDR fallback. If your only AV is Defender and CVE-2026-45498 takes it offline, you have a blind window. Even a basic Sysmon + log forwarding + alert pipeline is meaningful insurance for the next two weeks while the patch rolls.
Watch CISA KEV updates. Both CVEs are now KEV-listed. CISA's pattern is to update advisories as they get better exploit telemetry. If a related CVE chain shows up (it usually does within 30-60 days of an EoP zero-day), you want to know.

What this signals about the Defender ecosystem

Defender being the primary AV on Windows means a vulnerability in Defender is a vulnerability in the Windows security boundary itself. There's no "swap to a different AV temporarily" option for most fleets; the swap takes weeks and breaks existing detections. So when Defender ships an exploitable bug, the practical response is "patch fast and accept the blast-radius window."

The April advisory cycle also had Defender zero-days, with three actively-exploited items and at least two unpatched at the time of disclosure (per The Hacker News reporting). The May cycle adding two more puts the count at 5 actively-exploited Defender zero-days inside 60 days. That's a pattern, not noise. Either the offensive research community is focusing on Defender specifically (likely given its ubiquity), or Microsoft's internal hardening process for Defender has gaps adversaries have learned to find faster than the patch cycle.

For SOC teams: the practical implication is that "Defender is healthy" isn't sufficient assurance anymore. The platform itself is now a credible attack surface, not the thing watching for attacks. Add Defender-version telemetry to your daily health check the same way you'd track signature freshness.

For CISOs: the next Q4 endpoint-protection decision should weight "what's our exposure if our primary AV is itself the EoP vector" much more heavily than it did a year ago. That doesn't necessarily mean rip and replace, but it might mean a secondary EDR layer.

What's worth not panicking about

This isn't a wormable RCE. There's no internet-facing component. Both CVEs require an authenticated local foothold to start. The blast radius is bounded by your initial-access hygiene, which is what it has always been. Patch normally, hunt for the symptoms, and move on.

If your fleet is genuinely current on Defender platform versions, you were probably patched within the auto-update window already. The PowerShell command above is the 30-second check.

Resources

If you want the deeper toolset for Defender-aware incident response, including the queries, hunt rules, and playbooks I use, those live in the Claude Code cookbooks, which include a cybersec cookbook covering EDR/AV chains. For comparison reviews of the endpoint-protection stack alternatives (Defender vs CrowdStrike vs SentinelOne), check tools.thesoundmethod.me.

Sources

Canonical: tools.thesoundmethod.me

Cloudflare vs Vercel for a SaaS in 2026 — which one I actually picked

Conor Dobbs — Thu, 04 Jun 2026 17:20:02 +0000

Heads up: this post contains affiliate links to the two platforms it compares. I link both. I pay for both. The recommendation is the same one I'd give a friend over coffee. If the affiliate rate changed tomorrow the article wouldn't.

i run production workloads on both Cloudflare and Vercel. currently I have a SaaS on Cloudflare (Workers + D1 + Pages) and a marketing/landing-page stack on Vercel (Next.js 15 App Router). here's what shipping both taught me.

The short version

for a new SaaS in 2026, my default is Cloudflare Workers + D1 + Pages. the reasons aren't what the marketing pages emphasize.

for a content-heavy site that needs SSR, image optimization, and a fast deploy cycle, my default is Vercel. their developer experience for Next.js is unmatched.

Where Cloudflare wins

Cost predictability. Workers has a known per-request price. D1 reads and writes have known per-operation pricing. R2 has zero egress fees. you can build a SaaS that handles 100k requests a day and predict the bill within a few dollars. Vercel bills can spike in a single deploy if a function loop misbehaves. I've watched both happen.

Global by default. Workers run at the edge in 300+ locations without configuration. Vercel's edge functions exist but cost more and have stricter runtime limits.

Zero-egress storage. R2 is S3-compatible without the egress bill. for any product that serves user-uploaded files, this is a >10x cost difference vs putting them in S3 behind Vercel.

The integrated stack means less glue. Workers, D1, KV, R2, Queues, Durable Objects, Email Routing. all in one dashboard, billed together. Vercel has integrations with external services but you're still managing 5 dashboards.

Where Vercel wins

Next.js DX. Vercel built Next.js. the deploy story is one git push and everything works. App Router, server components, ISR, image optimization, font subsetting, configured optimally without you knowing. Cloudflare Pages can host Next but the integration is less seamless.

Preview deployments per pull request. better than Cloudflare's equivalent. the preview URL is shareable, the env is automatically a non-prod copy, the GitHub PR comment integration is useful.

Build toolchain. build logs are readable. build failures are debuggable. cache hits are reported clearly. Cloudflare's build experience has improved, but Vercel still leads.

If your stack is React-and-React-only. Vercel's optimizations assume Next.js or Remix. if you write SvelteKit or Astro on Vercel, you're paying full price for tooling you don't use.

The pricing reality

for a SaaS with ~100k requests/day, ~1GB egress, light DB use:

Cloudflare: free tier covers most of this. Workers Paid plan ($5/mo) gets unlimited script invocations and bound resources. add ~$5-15/mo for D1 + R2 storage. realistic monthly: $10-25.
Vercel: Hobby tier won't work for commercial use (their AUP). Pro starts at $20/seat/mo. add per-execution function pricing, ISR cache, image optimization. realistic monthly: $30-100+ depending on traffic.

the 3-5x cost difference at this scale is real, and it widens with scale (Vercel's per-execution and bandwidth pricing gets ugly).

Workers vs Vercel Functions specifically

Cloudflare Workers run on V8 isolates. they cold-start in <5ms. their runtime is limited to web APIs plus Workers-specific bindings. no Node-built-in modules unless you opt in via nodejs_compat.

Vercel Functions run on AWS Lambda + Node.js 20. they cold-start in 200-1500ms depending on bundle size. full Node ecosystem available.

writing a thin API: Workers wins on latency and cost. using a Node library that doesn't work on V8 isolates (some ORMs, native modules, anything that touches fs): Vercel.

How I'd actually pick

pick Cloudflare if any of these are true:

you're cost-sensitive (early-stage, indie hacker, side-project scaling up)
you serve user-uploaded files (R2 zero egress matters)
you need global low-latency from day 1
your backend can be written in TypeScript without Node-specific deps

pick Vercel if any of these:

you're building a Next.js app and want the smoothest DX
your team is React-experienced and doesn't want to learn Workers patterns
you need preview deployments per PR with shareable URLs
you're willing to pay for DX

What I do

i use both. the SaaS backend lives on Cloudflare (cost + global + the D1+R2 integration is too good to pass up). the marketing landing pages, blog, and dev portfolio live on Vercel (Next.js + Vercel is the smoothest deploy story I've used).

i treat them as complementary, not competitive. the mistake people make is picking one for everything because they read an "X vs Y" article and went all-in.

If you want more of these, I write production-use comparisons at tools.thesoundmethod.me — no vendor PR, just what I'd tell a friend.

Claude Code's hidden config: what the docs don't tell you (and what to ignore)

Conor Dobbs — Thu, 04 Jun 2026 01:20:02 +0000

A developer recently sat down and read through Claude Code's source, then wrote up everything they found that the official docs gloss over. It hit the front page of Hacker News with a few hundred points, and the comment section did the thing every "I read the source" post does. Half the room was delighted, the other half pointed out that "undocumented" and "you should rely on this" are not the same sentence.

Both reactions are right. There genuinely is a layer of Claude Code configuration that most people never touch, and most of it is documented. It's just buried, or split across the settings page and the hooks reference where you'd never connect the two. A smaller slice is reverse-engineered from the source and should be treated as exactly that: interesting, not load-bearing. Here's the honest version of what's worth knowing, and where the line sits.

The config layers nobody reads past

Almost everyone configuring Claude Code stops at three things: a CLAUDE.md file with project instructions, maybe a permission allowlist so it stops asking before every npm command, and the model picker. That's the 90% case and it's fine.

The official settings documentation goes a fair bit deeper than that, and this is the part people miss. Every environment variable you can set on the command line can also live in settings.json under the env key. That means you can roll a setting out to a whole team by committing it to the project's .claude/settings.json instead of asking everyone to export it in their shell. Permissions are the other underused piece. They don't override across scopes the way most config does. They merge. Your user-level rules, your project rules, and any managed settings all stack. That's why a permission you "removed" sometimes still applies: it's set somewhere else in the stack.

If you've ever wondered why your teammate's Claude Code behaves differently from yours on the same repo, this is usually the answer. It's not the model. It's three settings files merging in an order nobody mapped out.

Hooks are where the real power is, and the real footguns

Hooks are the feature that separates people who think Claude Code is a chat box from people who've turned it into a build system. They run your code at specific lifecycle points: before a tool runs, after an edit, when the session starts, when Claude is waiting on you.

The official hooks reference now documents several hook types, and this is genuinely worth internalizing. A command hook runs a shell command. A prompt hook sends a single-turn question to a model and gets back a yes/no JSON decision, which is useful when "should this be allowed" is a judgment call rather than a regex. An agent hook spawns a subagent that can read files with Grep and Glob before it decides. That progression from regex, to a quick model call, to a full agent is the part the docs do explain, and it's the part most people don't know exists.

The reverse-engineering write-up goes a step further and claims hooks can return richer JSON to steer behavior mid-run: a PreToolUse hook handing back a permissionDecision to force allow or deny, an additionalContext field to inject text, or updatedInput to rewrite a command before it executes. Some of this maps cleanly onto documented behavior. Some of it, like background async hooks or a once flag that fires a hook a single time and then removes itself, is the author's reading of internal fields. Treat that tier as a lead to verify, not a config you ship to production. The whole reason the docs draw a line is that internal field names change between releases without warning, and a hook that silently stops firing is worse than no hook at all.

There's also a security dimension here that's easy to skip past. HTTP hooks can interpolate environment variables into request headers, and the settings now let you restrict which variable names a hook is allowed to read. If you're wiring Claude Code into anything that touches a real secret, that allowlist is not optional. It's the difference between a hook that sends an auth token to one endpoint and a hook that can read your whole environment.

Why this matters more than it looks

I spend a lot of time in the weeds of tools like this, comparing what a product claims it does against what it actually does when you run it, and Claude Code is a near-perfect case study in a pattern I see constantly: the gap between the deck and the deployment. The marketing surface is "it writes code." The actual product is a configurable runtime with a permissions model, a lifecycle hook system, and a settings hierarchy that merges across three scopes. Most of the value is in that second description, and almost none of it is in the onboarding.

The "I read the source" genre exists because of that gap. When the documented surface is smaller than the real one, somebody eventually goes spelunking and writes up what they find. That's healthy. But the takeaway isn't "go set the undocumented flags." It's "the documented-but-buried 80% is already more than you're using." Get your permission rules merging the way you intend. Move your team's env config into the committed settings file. Replace one brittle regex hook with a prompt hook. That's a week of real workflow improvement before you ever need to touch anything reverse-engineered.

If you want the version that doesn't require reading either the source or a 3,000-word teardown, that's exactly the kind of thing I keep collecting: the configs, hook patterns, and CLAUDE.md setups that actually move the needle, written down so you can paste them in and move on. There's a running set of Claude Code recipes and a tools directory over at tools.thesoundmethod.me if that's useful to you.

The short version: Claude Code is more configurable than its docs make it look, the best wins are in the documented-but-overlooked layer, and "undocumented" is a reason to verify, not a reason to trust. Read the official references first. Save the source-diving for when you've already outgrown them.

Sources

"I read the Claude Code source code" (buildingbetter.tech): https://buildingbetter.tech/p/i-read-the-claude-code-source-code
Claude Code settings reference (official): https://docs.claude.com/en/docs/claude-code/settings
Claude Code hooks reference (official): https://docs.claude.com/en/docs/claude-code/hooks

DEV Community: Conor Dobbs

Anthropic Is Now the Most Valuable AI Startup. Here's the Developer's Read.

the number, with the caveats intact

what is generating it, from where i sit

the part the headline skips: this is a platform-dependence story

what i would do with this news

Resend vs Postmark vs SendGrid — three production accounts later

Short version

Where Resend wins

Where Postmark wins

Where SendGrid still wins

Cost reality

The deliverability question

What I do

PostHog vs Plausible vs Fathom — which analytics tool to run for your SaaS in 2026

Short version

What PostHog actually is (and why it's a different category)

Where Plausible wins

Where Fathom wins

Where PostHog wins

The cost reality

The decision tree I actually use

What I actually do

Links

Migrating from Go to Rust: The Tradeoffs Worth Knowing First

What gets better

What gets worse

The decision that counts

Sources

Microsoft pulled internal Claude Code licenses — what their engineers' preference tells you about picking AI tools

What happened

So why is it interesting

What this means for how you pick

Claude Max, $100/mo direct from Anthropic

Cursor Pro, $20/mo, Anthropic models via Cursor's relay

Aider plus your own Anthropic API key

GitHub Copilot CLI plus Claude through Foundry

The honest read on each

What this signals about the AI editor market

What to do this week

Sources

LLM Smells: The Tells in AI Writing, and the Costlier Ones in AI Code

the writing tells

the same smell in code, where it gets expensive

why you cannot smell-check ai with more ai

sources

Learn SQL Once, Use It for 30 Years: Why the Skill Doesn't Expire

Where the staying power comes from

Declarative is the whole trick

A standard that refused to fragment

The honest caveats

What this means for where you spend your time

Is MCP Dead? When the Model Context Protocol Earns Its Complexity

what people are angry about

the part the headline skips

what i would reach for

why this matters if you are building

sources

Durable Workflows on Postgres: What "You Don't Need Temporal" Actually Buys You

What durable execution solves

How the Postgres approach works

What you give up

The decision that counts

Sources

Defender zero-days CVE-2026-41091 and 45498 — what defenders should do today (May 2026)

What's being exploited

Who needs to care this week

What defenders should do today

What this signals about the Defender ecosystem

What's worth not panicking about

Resources

Sources

Cloudflare vs Vercel for a SaaS in 2026 — which one I actually picked

The short version

Where Cloudflare wins

Where Vercel wins

The pricing reality

Workers vs Vercel Functions specifically

How I'd actually pick

What I do