I’ve been thinking a lot lately about the relationship between my environment and my personal growth lately. Small ways, like how people perceive your choice of city–a founder told me they think of New York as a “lifestyle city” for example, at least if you’re in tech. Big ways, like who your neighbors will be–a lot of my friends have talked about moving there not just for fun, but because it’s where their customers are. Of course, pg was writing about this in 2008 and SF and New York are very different cities now than they were back then, but not so different that his framework isn’t useful.

From TechCrunch:

In a shocking twist, Google DeepMind is now hiring Windsurf CEO Varun Mohan, co-founder Douglas Chen, and some of the startup’s top researchers. A Google spokesperson confirmed the hiring of Windsurf’s leaders in a statement to TechCrunch.

I know a lot of the Windsurf folks, so this news makes me both a little excited for them but also a little scared. Time (or leaks) will tell if this $2.4 billion acqui-hire plays out well for the team.

Update: I’m late to this. From The Information via Twitter:

• Employees with vested shares will receive cash – Employees who joined less than 12 months ago are not vested and won’t get payouts under current terms – Windsurf negotiated to keep $100M+ on its balance sheet; company will shift focus to enterprise customers
• Remaining company will now be employee owned

This is similar in structure to the Scale deal, employees who joined later on not only get less, they get next to nothing. I’m still lost as to what this exit means. Was it that Windsurf ran out of options? That Microsoft accessing their IP was too big of a no-go?

Despite the proliferation of AI agents in B2B, it’s still very difficult to actually make or use them as a consumer. I don’t really want to use MCP locally to power all of this, so I’ve just been throwing relay.app at everything to do structured research and interpretation.

If you don’t know Warp, it’s a pretty nice terminal app that I’ve been using for a number of years; I mostly use it because it lets me copy entire command responses and other quality of life stuff like that. I really enjoy it and have recommended to everyone I talk to.

One of the things it’s never gotten me to do though is pay for it; I mostly just expect my terminal to be my terminal. I’ve seen a couple of angles they’ve taken: the enterprise route with some of their collaborative team features was the first one, and as AI started up everywhere, trying to directly integrate LLMs into your terminal.

It certainly sounds like they’re trying to go well down the latter route with their 2.0 launch:

The products on the market today...bolt agents onto code editors through chat panels and bury them in CLI apps. What’s needed is a product native to the agentic workflow; one primarily designed for prompting, multi-threading, agent management, and human-agent collaboration across real-world codebases and infrastructure. [...] With Warp 2.0, the ADE ["Agentic Development Environment"], this is all fixed: it’s amazing at coding and really any development task you can think of. You tell it what to build, how to build it, and it gets to work, looping you in when needed.

To be honest though, I’m not seeing the vision. I mean, I like the new design of the terminal, but what’s going to compel me to use their AI inputs over, say, Claude Code? (I’m also not gonna really comment on the SWE-bench scores because I don’t really find them to represent how much they actually help me.) I’m seeing some possible answers in the post, but none are really interesting to me yet.

One contender is multitasking (“multithreading”). Cursor/Windsurf still don’t really support having multiple chats yet, which annoys me. But far from being “buried” in a CLI app, claude can just be run in multiple tabs to the exact same effect. And every (local) solution so far is always working off the same copy of your code. So sure, like the demo shows, you can be writing some code in one tab, doing code review in another, and reading logs in a third. But it’s still awkwardly aware that I can’t test two bugs at the same time, or really, multitask anything that requires running code locally.¹

The knowledge angle is similarly lacking for me. At anywhere I’ve worked, I already have Notion, Slack, Google Drive, as well as AGENTS.md, CLAUDE.md and Cursor rules. It feels redundant to be creating another central team store. I think shared MCP could be interesting, but right now I’d be too scared of accidental credential leakage, so maybe one day that’ll be interesting.

So really what it’s doing is just giving me another coding wrapper. I don’t think that’s a bad thing! I think there are many fantastic wrappers out there, but I really don’t think it’s fair to call the status quo “bolted on,” “buried,” or inferior compared to the vision they describe. There’s really just two things that would compel me to use it over my current spate of AI coding tools short of unique models: a better harness (which is a tough, tough hill to climb in a world with CLI coding tools built in tight connection with the underlying models), or a radically better way to manage and steer the agents. I’m excited to see if they can deliver on these.

This is now a real alternative to eslint.

I’m a huge fan of snapshot testing, especially in JavaScript/TypeScript where types often lie, ane especially in backend. This article was a good reminder to me why I think it’s such a powerful tool in the arsenal.

At Pallet I found these to be an essential part of allowing our eslint rules to change. Essentially bulk suppressions allow you to keep a file tracking everywhere the code violates existing lint rules because the code predates the new lint rules. This is cleaner than using // eslint-diable everywhere and prevent normalizing disabling lint rules all the time, since all the disables are separate.

Yes, ideally, when you introduce a new rule (like no-floating-promises, a literal savior of sanity in the cruel world of JavaScript race conditions), it would be way better to go and fix all the instances. But that can change behaviors you don’t always expect. Or, more plainly, it’s just a lot of work to be able to take advantage of a new rule. So rather than try to go strive for perfection in your code base you can make things better, right now, and eventually get everything into compliance (if ever).

This capability has existed for a long time in the patch package eslint-bulk, but seeing it native in eslint means it’ll be less finicky to work with (the package above takes a bit of finesse to work correctly since it overrides eslint’s suppression system).

A2A is an open protocol that […] empowers developers to build agents capable of connecting with any other agent built using the protocol and offers users the flexibility to combine agents from various providers. Critically, businesses benefit from a standardized method for managing their agents across diverse platforms and cloud environments. We believe this universal interoperability is essential for fully realizing the potential of collaborative AI agents.

I think it’d be nice if this worked, but I’m certainly skeptical right now. One of the big things about how agents are supposed to do better than a standard worfklow is that they can work with highly ambiguous APIs (a.k.a., no API), so whether working against that talent will help improve accuracy or stall adoption remains to be seen.

Put another way, it would be nice if we had a standard way to communicate, but we all know these systems don’t talk to each other well for a reason. This may well be just another standard if there isn’t significant resources behind its adoption, and that part I certainly can’t tell.

You’ve probably seen this phenomenon before, where it’s easier to cope with a subpar situation rather than fix it or pick an alternative? Region-beta paradox. I wish there was a better name.

There’s a lot of places this shows up in a software team:

• Using shitty software because it’s not worth switching off (looking at you, Jira).
• A teammate who everyone knows is painful to work with, but not so bad that anyone thinks to tell them.
• Not complaining about mildly bad situations, allowing them to fester over time.

Some solutions:

• Complain loudly. (Biggest red flag to me in an organization is when people praise each other for not complaining.)
• Trying new things, for their own sake. Make people feel like change is normal rather than bullshit.
• Valuing improvement. (This is a hard one, and I still haven’t mastered it. But I know it’s possible.)

This has been bothering me because I use Bartender pretty heavily. If you’ve ever been bothered by prompts that “X app is accesisng your screen” in Sonoma, this should work.

A small side rant: Apple, you’re training users to ignore warnings when they’re so naggy like this. Maybe this will cover your ass, but it’s certainly not good security.

Brendan is an old friend from my time at Backbone, and someone I really admire for the journey he’s taken through both design and engineering. So when I saw he posted a personal manifesto, I had to read it. This is my favorite line in this piece:

The best feedback I get isn’t praise. It’s momentum. When someone says, “Oh, this makes sense,” and they keep going.

Instead of simply blocking bots, Cloudflare’s new system lures them into a “maze” of realistic-looking but irrelevant pages, wasting the crawler’s computing resources. The approach is a notable shift from the standard block-and-defend strategy used by most website protection services. Cloudflare says blocking bots sometimes backfires because it alerts the crawler’s operators that they’ve been detected.

One question that’s been crossing my mind lately—what will this do? A couple years ago, we worried about model collapse, but if anything, it’s gone the other way now. Claude is trained on its own data, modulated by researchers, for example.

The effect may be that it just separates out the shops that can afford advanced scrapers and inefficient compute versus the ones that can’t, and the veterans (who have already built up their datasets) versus the newcomers.

So continues the training data arms race, I suppose.

If you know trigger.dev, this is essentially Cloudflare’s version of Trigger, a technology I haven’t personally used but really want to. These two products are runtimes similar to Temporal, but with much simpler ergonomics.

I haven’t given much thought to the differences between these platforms, to be honest. However, one thing stands out: Trigger aims to run your existing Node.js codebase in its serverless runtime, while Cloudflare Workflows integrates with the Cloudflare V8 isolate system, which has some incompatibilities and does not support external API calls like napi. (Inversely, this can be a blessing because the Cloudflare Workers is sooo much simpler.)

Additionally, Cloudflare Workers provide about 60% of the value of something like Trigger because Workers’ pricing is based on CPU time rather than wall time. This means if you spend 2 ms making a call and wait a minute for it to return, you’re only billed for 2 ms of compute. The reliability and observability aspects are where workflows win out.

I’ve seen a lot of traction from this library lately, and compared to the juggernauts like zod, it leverages some of the newer technologies available to the ecosystem:

//----
// examples/checkString.ts
//----
import typia, { tags } from "typia";
export const checkString = typia.createIs<string>();

//----
// examples/checkUUID.js
//----
import typia from "typia";
export const checkString = (() => {
  return (input) => "string" === typeof input;
})();

Zod would instead be using runtime types to generate static types, but here typia is creating runtime types from static types, using a TypeScript transformer.

Super neat, and I certainly did not realize how ready the TypeScript plugin ecosystem was for prime time until seeing this.

I’ll cut to the chase here:

To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage. By porting the current codebase, we expect to be able to preview a native implementation of tsc capable of command-line typechecking by mid-2025, with a feature-complete solution for project builds and a language service by the end of the year.

Given the current meme of rewriting core JavaScript tools in Rust, Zig or Go, this comes both as no surprise and yet still very unexpected (TypeScript defines trends as much as it bucks them). Almost every single non-JS tool has not bothered to rewrite the typechecker because there’s just so much complex and semi-undocumented behavior that it’s not worth doing. But if the TypeScript team is doing it, it’s another matter altogether; they’re on the hook for this keeping compatibility with existing behavior.

🍿🍿🍿

I’m still looking for a practical Gleam-based web framework to play around with, and it feels like Wisp is the most interesting one so far (made by the Gleam creator).

Why Gleam, over Elixir? Mostly because I think types make life a lot easier than pattern-matching, but that’s more of a stubborn opinion. I have no doubt that Elixir’s pattern-matching is “good enough” in dynamic-land, but given that most of my brain has been rewritten in TypeScript over the last 6 years, the adjustment to a truly dynamic language sounds a lot more daunting than just picking a statically-typed or incrementally-typed language.