They don't make them like this anymore

tl;dr: CascadiaJS is a rare developer conference that does not make you feel like you’re in a sponsor funnel. Go if you can. It was also a refreshing reminder that yes, AI has changed a lot of things, but it still require somewhat of a engineer’s mindset to make the stuff actually work.

It's not very often I get to be “just” an attendee. Having worked devrel in various permutations at Sanity for eight years, most developer conferences come with a booth to run, a sponsor badge, a workshop or a talk to give. So now that I've moved to California, I finally got to take a short flight to Seattle for CascadiaJS. One of those conferences I kept hearing good things about and had wanted to go to for a while.

It lived up to expectations.

Events always come with a vibe. Go to the big ones and you often feel like you're being treated as a potential email for a sponsor's list, and it takes all the extroverted energy you can muster to strike up a conversation with a fellow attendee. CascadiaJS feels more like a company offsite (in a good way). You might not know everyone, but you can be pretty confident a good conversation is one hello away. And if you've been around, you probably already know a few faces from the Internet there already.

I was curious what kind of conversations I'd have at a non-Bay-Area tech conference in 2026. Surely every talk and every chat would be about AI, right? RIGHT?

Turns out, yes. A little. But not in the way I expected.

#What the room felt like

I came braced for one of two things. The hype, everyone breathless, agents everywhere, ship your job to a swarm. Tokenmaxxing. Or the backlash in a room of holdouts rolling their eyes. I found neither.

What I found instead was quieter and more honest. No one I talked to were questioning AI for coding anymore. But the confidence that some of the talks projected wasn’t really in the hallway. We’re all still poking at it, trying to figure out how to make all of this stuff best work for us (and not the other way around).

Almost everyone I talked to is somewhere in the middle of figuring it out, and nobody seemed sure. A PM at a big hardware company, building a lot with AI, feeling empowered. A developer at a major news publisher thinking hard about engagement and subscriptions now that Google is quietly taking their traffic. Agency folks now meeting heightened expectations to ship faster. Folks trying to get into the industry again or for the first time. All in, but feeling their way.

I asked some of the younger attendees, folks barely out of university, how they felt about all of it. Some hesitation, but mostly a shared sense that the level of abstraction has gone up and that understanding the layer underneath still matters for knowing how to nudge these things in the right direction.

And yeah, everyone is also waiting for the subsidized tokens to go away and for the field to have a bit of a rude awaking and heightened expectations on the returns of invested tokens.

#Working with agents: mental models and frameworks

Netlify’s Matt Biilmann’s opening keynote gave the room a clear way to think about Agent Experience: designing your product for the agents that use it on a user's behalf, not just for the humans. His four pillars are Access (can an agent get in and authenticate), Context (does it understand what your product is and does), Tools (are you giving it the right interfaces, not just your human-facing ones), and Orchestration (can agents be launched and run from your product). Great DX isn't automatically great AX. An interactive CLI is a delight for a human and a wall for an agent. Netlify has an obvious interest in AX becoming table stakes, but the framework is a good one to think with regardless.

The tension between developer and agent experience is the part I've spent a lot of the year writing about, so I'll point rather than repeat it all. I've argued that agentic developer experience starts with your system, not your prompts (where I push on Matt's framework a little, on the question of sequencing, which pillar you invest in first when you only have one sprint), and I've tried to extend the same thinking into ten laws of developer experience for CMSes.

I missed some talks for the hallway track and and a fantastic taco lunch, so take this as a partial read, but there seemed to be a quiet tension running through the program. Matt was talking about building for agents, designing experiences for software that acts on a user's behalf. Auth0’s Michael Liendo touched a little on this too, in an inverse way, in his talk about how to make the agent stop and wait for human approval (so they don’t just go ahead buy those airline tickets). So agents working with humans…

But most of the other talks were about building with agents, the agent as your tool, in your harness, fine-tuning models, using them to help you make the thing. Same vocabulary, opposite direction of the arrow. I don’t think I saw anyone put those two framings in the same room and reconciled them, and I don't think the industry has either yet.

That’s probably a great CFP submission for next year.

#The work didn't disappear; It moved up and down the abstraction layer

Across two days of talks almost none of them were “I leaned back and the agent did everything.” They were good old engineering talks. Someone wanted to build a thing, hit a problem, tried an approach, threw most of it away, tried another, iterated. The agent changed which pieces you assemble. It didn't remove the assembling, or the judgment about what fits, or the part where you figure out why it's broken.

Alex Hinson's talk on live-coding music with an on-device model was the cleanest example. He started with a structured-intent design, where the model emitted JSON and a deterministic engine turned it into Strudel code. I could relate to this instinct and how one would get there. Then he realized 90% of his codebase was the engine. So he constrained the problem differently, let the model emit code directly, and deleted almost all of it (slides here). The thing he'd lovingly hand-built was the thing the model let him throw away. (Funny side note: a colleague of mine had built basically the same thing.)

Joel Hooks called the current moment “harness engineering,” everything around the model is the work now: the prompts, the tools, the context, the orchestration, the feedback loops (his reference page has the rabbit holes). He landed at the conclusion, after a talk full of agents doing wild things including playing D&D against each other, was that swarms are hard, and the real scarce resource is your attention. James Ide made a related point from the Expo side: agents can generate the code, but you still need durable intent, so write the spec and link the code back to it.

For me it was some great examples of how kinda silly it can feel to try and make agents useful with all of this tinkering, fiddling in terminals and shells, figuring out new ways of making markdown files available for them, while folks are talking about the imminent dawn of AGI. It doesn’t feel quite like that on the ground.

#Knowing the layer underneath is the edge

One of my favorite talks wasn't about AI at all. James Steinbach gave a pure front-end talk on modern CSS color features, and it was refreshing to sit in a room and just learn something about frontend development again. light-dark() collapses a thousand lines of theming variables into one-liners. Relative colors let you derive a whole palette from one value, no preprocessor. contrast-color() picks readable text for you, so you can finally stop writing JavaScript to do it.

I've unsuccessfully tried to get AI to write great CSS, and this is exactly the kind of thing it won't reach for on its own. Ask it for accessible fg/bg contrast and it'll happily write a pile of JavaScript, because that's what the training data is full of. It won't reach for contrast-color(), because the function barely exists in the corpus yet. The newest, most elegant thing on the platform is precisely the thing the model is worst at knowing about. Unless you have the intent and awareness to give it that context, or give it the instructions to have the intent and awareness to get that context.

The platform keeps shipping new things, the training data keeps lagging, and the gap regenerates. Whoever knows the current state of the art is the one who can stop the agent from defaulting to yesterday's verbose pattern, or feed it the right context through RAG so it knows better. Knowing the new stuff is the edge, and it stays the edge.

Even though the talk didn’t talk about AI, I ended up bringing a bit of it after all. The talk was light on demos, so afterward I took the published slides, handed them to Claude, and had it build me an interactive demo site for each technique so I could actually play with them. That's roughly the whole conference in one move: a human taught me the concepts and supplied the taste about what was worth knowing, and the model filled in the scaffolding the speaker didn't have time to build. Neither half does the job alone.

#English is great, but programming languages still matter

Filip Sodić's very entertaining talk on TypeScript was the one that landed closest to my own work. His argument: programming languages matter more because of AI, not less. He set himself against the “English is the new programming language” line, the one you hear from the people with the most to gain from you believing it. If all you do is one-offs and demos and inconsequential software, sure, English might be a viable programming language. But anyone who had to put software in front of a lot of people who are expected to use it with their money and for real stuff, know that it gets more complex and fraught.

His counter was that “the spec and docs” has to live somewhere, and English isn't it, too ambiguous, not checkable. If it were, we'd be committing prompts^[1] instead of code.

I spend my days arguing a version of this about content, so it was a little uncanny to hear it made about code. JavaScript with tests and docs scatters the domain knowledge the same way raw text with (or without) a CMS does; types put it somewhere a machine reads natively. <ad>I guess I was biased to like this one, because if you model your content with Sanity, you’ll get those TypeScript types out of the box as well, even from your content queries. </ad>

#The tinkerer isn't going anywhere

If there was a through-line in the spirit of the place, it was the hacker instinct: don't hand all your tooling to other companies to figure out, poke at the thing, bend it, understand it. Joel's harness talk was partly about exactly that, taking ownership instead of renting a black box. That instinct has always driven this work, and it doesn't go away with agents. It just takes new forms.

The proof was in how much joyful, slightly useless building was on stage. Luis Montes reverse-engineered karaoke, separating vocal stems with one open-source model, timing lyrics with another, inventing his own metadata format to hold it all, recreating old WinAmp visualizers in WebGL for fun. He's not a musician and not a Python person; he built the parts he was good at and let the model handle the rest (it's all open source).

The talk that made me (and everyone else) chuckle as a recovering humanities academic was Molly Jean Bennett's Beowulf Stroganoff. She opened with poking at OpenAI's statement that AGI will do “most economically valuable work,” and point out that the best things in life are economically useless. So she fine-tuned a tiny model (TinyLlama, with LoRA adapters) on a deeply silly pile of public-domain text, the thousand-year-old epic Beowulf, a 17th-century cookbook called The Closet of Sir Kenelm Digby Knight Opened, a promotional Crisco pamphlet, and a bag of inspirational aphorisms and Gen-Z slang. The result is a bot that dispenses recipe wisdom in the cadence of Old English heroic verse. Beowulf and Crisco. The whole thing is gloriously pointless and I mean that as the highest compliment.

But there was… “economically applicable learnings” hiding in the gag. She shipped two versions, and her line about the second one was that she slowed down, paid attention, and actually spent time with the code. The careful version is the better one. What she learned, and taught us, was some methodologies and things about models that’s highly useful. So even the joke talk about building something useless landed on the same note as the serious ones: the craft is the part that matters, and the craft is the part you have to slow down for.

#Question everything

And then Theo closed it out with in known style (if you have watched any of his content) with some spicy takes and one of the most impressive live demos I have seen in a while. I’m not sure I 100% buy the historical accuracy of his framing: That before the cloud™, building was capital-intensive, you bought servers before you wrote code and had to predict your own future, so experimentation was expensive and rare. And then cloud made it cheap, and that changed everything. But it doesn’t need to be true to be right.

His claim is that AI is the next drop in the cost of experimentation. Huge, but not as unprecedented as we like to pretend. From there, a string of “why can't we” provocations, things that have annoyed him for years and now annoy the agents too: why can't we commit our secrets, why can't a public repo have private parts, why do we even need a file system to compile an app, why do we assume our codebases still matter. The punchline answer to all of it was “because of Salesforce.” Incumbency and path dependence, not technical limits.

Then he did the thing you're not supposed to do (because of demo gods) and ran a live demo. He deployed a working app with real auth and live sync from a plain directory, had a Cursor agent add a live chat feature, redeployed, watched it go live, and claimed a real domain from the command line. It was super fast and pretty much flawless. And a fraction of a time that it took DHH to build a blog in the infamous Ruby of Rails demo two decades ago (remember how we experimented with building software with Ruby of Rails before the cloud?).

To make that look easy, he'd had to build a cloud, a CLI, a front-end and back-end framework, a bundler, a language runtime, and more or less his own compiler. He shared this with the huge caveat that lakebed.dev is “a bad tool for bad apps and not how anyone should build.”

Theo’s point wasn't the tool itself. It was that we've stopped questioning fundamentals that stopped making sense, and now is the rare moment to try the thing that feels stupid. Note taken.

#The only thing left to do is say thanks

Conference primus motor, Carter Rabasa closed the conference, and told the story of how it started. CascadiaJS exists because years ago he went to a conference called JSConf, fell in love with it, watched it go away, and decided to fork it. His words, more or less: he's not a creative person, he just took something he loved, kept its values, and slapped a new label on it. There's something nice about hearing that at an event where the closing keynote had just argued for forking and rebuilding everything in sight.

(You can do that too.)

He also said the quiet part out loud: The moment we're in as engineers is scary. A lot of people in that room are looking for work, or nervous about the work they have. But it’s also exactly the reason you’d come to a conference like this. To see how everyone is trying to figure out the same stuff, and share our experience from doing that.

He said the lesson he carried from JSConf's founder is that the only thing you should really do at the end of a conference is thank people, and then he did, the caterers, the sponsors, the speakers, the volunteers who made it run. And us who showed up for it all.

That's the part they don't make like they used to. Not the conference, exactly, the talks were the most forward-looking I've seen all year. The craft, and the care, and the room full of people being honest that they're all still figuring it out together. The tools will keep changing. Someone might even rebuild the whole stack from scratch. What holds is the people and the work and the willingness to keep poking at the thing until you understand it.

Go if you can. And make more events like it.

Most of the talk details here are reconstructed from my own notes plus the excellent community notes repo (PRs encouraged, and talk recordings will land there as they're uploaded). Jon Edwards' day-one notes are worth a look too.