As some of you may already know, Eric Binnion (ebinnion) of #Automattic and #WordPress has stage 4 esophageal cancer. His prognosis is about six months to live. This fundraiser is to support him and his family through this incredibly tough time. Every bit of support helps them focus on what matters most. If you’re able, please consider donating or sharing to help set them up with as much support as possible. 🙏

https://gofund.me/94f74495a

21 years at Automattic

https://odd.blog/2026/06/20/21-years-at-automattic/

21 years at Automattic

One year ago today I published a post about 20 years at Automattic, so it follows that I’ll post this one today, with 17 minutes left in the day. AI is still disrupting our industry, and tech companies that are rolling in money are laying off thousands of developers. I don’t know what’s coming next,Continue reading

https://odd.blog/2026/06/20/21-years-at-automattic/
#Automattic

Two Weeks at AI Enablement, NYC 

Last month I spent two weeks in New York with Cohort 3 of Automattic’s AI Enablement program. The idea is simple: put a cohort of Automatticians (who usually work remotely at home) in a shared, single room for two weeks, and fill the days with talks, workshops, and prototyping time, all about working with AI. The mix changes from cohort to cohort (some lean toward engineering, one was the executive leadership team, another the growth team); Automattic is experimenting with the recipe. My cohort was deliberately broad: around fifty people from product, design, engineering, data, and ops. We’re a distributed company. There’s no office to bump into each other in, so when many of us share a space, something different happens.

The schedule had range, the content was rich, and the room was kind. The most precious part was the people, more than the schedule itself. Don’t get me wrong, the sessions were excellent. But people make the party. The mix did a lot of the work, and the sessions were the scaffolding for it.

The vibes

The bit that stood out most was how easy it was to learn from each other. I could walk over to someone, glance at their screen, and ask about the thing they were doing right then. People showed each other what was working, what wasn’t, and what they were about to try. Distributed knowledge by osmosis. Not easy to replicate in a Slack thread.

We also did a coffee exchange. Everyone brought a bag from somewhere they liked, told the story behind it, and went home with someone else’s. Thanks to Esteban for building a temporary, private website to coordinate the exchange, and for that delicious fermented coffee from Costa Rica! I drank six different kinds of delightful coffee over the two weeks, and took a seventh home with me. The coffee exchange served as a tiny ritual that helped us connect. It gave us a small object to talk over, and reminded us that the people on the other end of those Slack avatars also have favorite beans.

Interfaces are moving up the visual stack

…give the human and the agent a shared surface they can both manipulate.

Across many demos, I saw the same evolution: command line, markdown files, HTML, rich browser experiences. Agents and humans are converging on a shared visual surface: pointing, annotating, dragging, and previewing, instead of describing things in pure prose.

Two tools fit this pattern especially well. Agentation lets you click any element on a page, drop a note, and turn the result into structured context (CSS selectors, source paths, computed styles) that an agent can act on. DialKit is a floating control panel with sliders, color pickers, and spring editors wired to your live component values. You can tune things by hand or ask your agent to wire it all up for you.

The same shift is reaching our own dev tools. The field went all-in on CLIs after Claude Code shipped. It was surprising to see that the previously heavy CLI users I know are now running Claude Code inside the Claude Desktop app for daily coding work. The visual surface has caught up with the terminal and is offering a nicer experience. The CLI may be a temporary lead, not the destination. The same direction shows up everywhere: give the human and the agent a shared surface they can both manipulate.

One demo took this idea all the way: Renku, a private social app for small communities, built on top of WordPress.com. The surface is fresh (posts, video, stickers, a feed) but every post is a real WordPress post and every like is a real WordPress like. I love watching people bend a familiar platform into a shape it was not packaged for, especially when the bending reveals that the platform always supported that shape and we just had not named it yet.

Context failures, not model failures

The cohort opened with a session on context fundamentals by Derek. The reframe that stuck with me: drift, repetition, and “AI doesn’t know my world” are usually context failures, not model failures. The line to remember: the right 50 lines outperform 5,000 lines of everything. Derek’s image for it: a model is a brilliant new hire who joined five seconds ago. Sharp, but with no idea about your team, your past decisions, or the rules you never wrote down. Everything it can see has to fit in one window that gets re-read at every turn, so a few precise lines beat a flood of everything.

Shaun’s talk on design systems made the same point from the design side. Your design system has a new audience now, and that audience is not human. As Shaun put it, despite the second word in its name, AI is really dumb. It fills gaps with training data and assumptions, then ships convincing but incorrect implementations. It’s all too easy to bypass the design system and go straight to the model, and what you get back is whatever the training set had.

The path forward is to feed AI your system in a form it can actually consume. Two pieces I started using right away: Automattic’s homegrown design-skills repo, and Impeccable, a design fluency skill with a detector that catches gradient text, AI-purple palettes, low contrast, and a few dozen other anti-patterns. Demos at the cohort pushed further in the same direction: an MCP server for the WordPress design system, a tracker that measures how the design system actually shows up across our products, and a tool that fills mockups with sensible, context-aware content instead of lorem ipsum.

We’re still in the beginning stages of working with and understanding AI. The layered approach (MCP plus context files plus skills) sometimes produces worse results than any one piece alone. Quality, taste, and art direction still need a human being in the loop. The honest framing is that the job is shifting from using a design system to evaluating an agent’s use of one.

What’s the data equivalent?

Spending the days alongside designers, PMs, and engineers was a different kind of fun. The expectations on data folks and on designers look different on the surface (data should be accurate, designs should look good), but neither of those is where the work actually happens anymore. The real work has moved a level down, into the systems each craft is built on.

Once you say it that way, the parallels stack up. A design system is, structurally, the same thing as a data model: a set of named primitives, rules about how they compose, and conventions for what good looks like. Tokens are columns. Components are entities. Patterns are queries. Documentation is documentation.

So here’s the question I kept coming back to. Design systems give AI a vocabulary, and the result is that AI-generated interfaces feel on-brand instead of generically templated. What would the same thing look like for data work? Components for query validation, schema and lineage lookups, chart selection, and standardized output formats. A shared library that codifies what “good” looks like and which AI can pull from.

I floated a rough version of this (a shared data library an agent could pull from) with colleagues who work on product analytics: a central data tool (MCP, CLI, or API) that handles validation, verification, and standardized output, paired with hooks any team can wire into their own workflow. We didn’t walk away with a plan. We walked away with the realization that we’re hitting similar challenges from different angles. People found the idea interesting, which is the only kind of green light a rough idea should get at this stage.

Everyone has a skill library

The library you write yourself is more about understanding the loop than about future-proofing a workflow.

A pattern showed up in almost every session: people keep a personal or team skill library—a folder of prompts and procedures that take them from rough idea, to spec, to plan, to tests, to review. The recipes overlap a lot:

• obra/superpowers bundles brainstorming, planning, subagent-driven execution, and test-driven development.
• get-shit-done is built around fighting context rot by doing the heavy work in fresh subagent contexts.
• gstack compresses the Y Combinator idea-validation flow into a Claude Code plugin.
• Harper Reed’s LLM codegen workflow is a beautifully short blog post describing the same loop, distilled.

Skim them all and they’re roughly the same shape: Socratic specification (the AI asks the questions), then spec-driven development plus test-driven development, with extra compute thrown at planning and review passes.

My takeaway: try new ones occasionally, but don’t worry about missing out on a golden one. As the models and the harnesses keep maturing, they absorb these patterns directly. Once a skill is golden, it quickly becomes a default in the model or the harness. The library you write yourself is more about understanding the loop than about future-proofing a workflow.

Start simple. Add as you need.

The most repeated advice across sessions: don’t copy someone else’s elaborate setup. Start with the smallest thing that works, and add a skill, a hook, an MCP, or an agent only when you feel the friction it would remove. Two reasons. One, the model keeps getting better, so yesterday’s scaffolding can quickly become today’s overhead. Two, the field is moving so fast that the elaborate setup you’re tempted to copy is probably already a little stale. Several presenters said it directly: they rewrite their decks every month because everything they said last time has new and better answers now.

The corollary: audit your workflow monthly. What is actually saving you time, and what is just there because you set it up once? Claude Code has an /insights command that helps with this. It reads back your recent sessions and surfaces patterns: where context fills up, which tools you keep reaching for, which prompts repeat. I ran it during the cohort and got feedback like “this could be a skill” and “this never gets used, retire it.”

One direction people are growing into is always-on agents. I was surprised by how many colleagues have something running in the background, often hooked into Slack, doing personal-assistant and technical-operator jobs: aggregating news, summarizing the inbox, monitoring deploys, dropping research summaries into a channel. The agent becomes a thing you talk to, not a thing you open. I haven’t tried this yet, but I want to. The right entry point feels like one narrow job done well; begin with that, and grow from there.

Start simple, audit monthly, add only when something is missing.

Three things I built

Otomatik

With Bohdan, I built Otomatik (it means “automatic” in Turkish): AI-driven QA for WordPress.com product flows. What I’ll remember most is the speed we found working in the same room. We sat next to each other, typed the spec together, scoped the MVP in real time, and shipped a v1 by the end of the week. The in-person tempo is the magic: a clarifying question becomes a 30-second nudge instead of a back-and-forth thread.

Localhost NYC

On prototyping day, five of us built Localhost NYC, a personalized New York travel and events guide for visiting colleagues, with recommendations driven off each person’s Gravatar and other public profiles.

The lesson: shared vocabulary is more fragile than it looks. Every time we thought we had alignment on the problem, the hypothesis, the solution, we would start building and realize we had each understood it differently. Not in a “someone is wrong” way, but rather in a“five well-intentioned people produce five legitimate shapes from the same brief” way. 

The same lesson that the design-systems talks had made about agents also applied to humans. Such differences of interpretation are fine for a hackathon prototype. But they leave the kind of gap that matters a great deal once you commit to shipping something.

Hyperactive Amateur

During the cohort, I shared a three-hour, vibe-coded sketch called Hyperactive Amateur. It’s a little in-browser beat-making toy where you record eight short clips from your webcam and mic. AI classifies the sounds and suggests a 16-step pattern, then it plays the song back as a hip-hop video of you performing it in real time. Lasse Gjertsen’s Hyperactive and Amateur videos inspired the sketch.The warm reception got me excited to keep playing with it. About nine more hours of “just one more thing” later, the rough edges are mostly gone, the source is open, and the app is live at hyperactive-amateur.fgelbal.com. Every “one more thing” is the most dangerous phrase in software, and also why this is now my favorite project.

What I’m taking home

The pace at these AI enablement sessions is fast, and we’re all still figuring everything out. That’s the most reassuring takeaway from the two weeks. Sharing where we are with each other (what’s working, what’s not, what we’re trying next) is honestly the fastest way forward.

The other thing I’m taking home is a renewed appetite for just trying things. Pick the smallest version that works. Build a skill. Wire a hook. Set up one always-on agent. The cost of an experiment has fallen to almost zero. The cost of not running any has not.

Something worth saying out loud. Two weeks of immersion came with a real trade-off: I was not productive in the day-job sense. Open office, fifty people moving around, no second monitor, none of my usual rituals. Heads-down, focused work took longer than it would have at home. The bargain Automattic struck for us was a generous one, and the question to ask afterwards is whether I gained more than I gave away. I did, by a comfortable margin, and a lot of what I picked up will let me recapture that productivity over the coming months. The next person weighing whether to join a cohort deserves to know it is a trade-off… and a great one.

“Rather than chasing perfection, the goal was to move quickly before ideas got too precious, share what was in progress, and iterate in real time based on your feedback.”

‘You broke it’

"Like we fucking care”

#automattic #wordpessdotcom

“Radical Speed Month is a creative experiment led by developers, designers, marketers, and many others across the Automattic team to build, ship, and test WordPress.com features faster.”

With absolutely NO regard for the impact on customers or the support ‘happiness engineers’

#wordpresscom #automattic

Nick Hamze about the lawsuit WP Engine vs Automattic:

»The Only People Winning This Lawsuit Are the Lawyers«

WordPress growth has stalled, and if the fighting continues even the winner will lose as both parties depend on WordPress.

#WordPress #Automattic #WPEngine #Lawsuit

https://regionallyfamous.com/lawyers-winning-wordpress-lawsuit/

What a strange turn of events, Matt wrote a blogpost in which he begs WP Engine to stop the judicial war he started himself.

He claims WPE (Silver Lake) is trying to dissolve the WordPress Foundations and wants to control and take over WordPress.

https://wordpress.org/news/2026/05/wp23/

#wordpress #wpengine #automattic

Move Fast and Don’t Break Things: Shipping the Simplenote MCP

When Automattic recently launched a month‑long hackathon, engineers Mark Biek and Evan Tobiesen knew exactly what they wanted to work on: the Simplenote Model Context Protocol (MCP) server.

Neither Mark nor Evan works in data science, so measurement might have been the easy thing to skip. Instead, they shipped a product with built‑in measurement from day one.

The team faced two difficult design questions. First, how do you give a large language model (LLM) permission to write to a user’s notes without a disaster? Second, how do you know if anyone is using the tool, without ever seeing the contents of their notes?

Simplenote is a lightweight note‑taking app for iOS, Android, Mac, Windows, Linux, and your browser. It’s been around since 2008, and like many of Automattic’s products, Simplenote is open source and free. Mark launched a read‑only version on April 15. The hackathon was a chance to go further.

Radical Speed Month (RSM) was a single month where Automattic employees stepped away from their regular work to pair up, build, and ship a passion project. The hackathon started on April 22, and by May 8, Mark and Evan had already shipped a new version of the MCP.  Neither Mark nor Evan works on Simplenote day-to-day. Mark is on domains, Evan on marketing technology.

“I have been a Simplenote user for 10 years. I’ve always really loved it, and I have a gazillion notes,” explained Mark. “And back in February, I wanted an excuse to write an MCP server because I had never written one before.”

Designing for Data Safety

As Mark put it, “The last thing we want is to put a tool out and have an LLM run wild and delete somebody’s notes.”

At first, the MCP tool was Mac-only and read-only (list, search, get). Opt-in write tools (create, update, trash, restore, revert) were the obvious next step. The MCP spec lets a server tag each tool as either read-only or destructive. 

Part of the work involved quantifying LLM guardrails, turning vague safety concerns into concrete numeric thresholds.

Before enabling writes, Mark and Evan added several data safeguards:

• Discoverability: The MCP write tools are not exposed when the MCP is in read-only mode, so LLMs can’t discover them by accident. 
• Content protection: There are also limits to how notes can be updated—text can’t be replaced by large amounts of white space, and updates can’t drastically shrink or blank out a note.
• Recoverability: Notes may be added to the trash but not deleted, so they can always be restored. 
• Rate limiting: Bulk operations are blocked, too. If the MCP detects more than five write operations within 30 seconds, it stops.

“If you have a note that is above a certain length, and that length changes by more than 50%, we block it,” Mark explained. “Let’s say you have a note that’s a dozen paragraphs long, and the LLM does something wacky and tries to wipe it out with just a single sentence… the rate limiting will prevent that.” 

Designing for Telemetry

The MCP only records two data event types: setup run and tool call. That may look like it wouldn’t be enough. But those two event types answer more questions than you’d expect. The telemetry records data on adoption, stickiness, tool popularity, and connector preference.

Instrumenting an MCP server without leaking user data was part of the project. 

“On a technical level, we generate a random or a unique ID,” explained Evan. “It’s just an ID for the install. And then we track very minimal data…. So we can see that this random user ID ran the tool ‘get note.’ While we don’t see which note or anything like that, we still get worthwhile usage stats.”

One way to use Simplenote is on a Mac with a local install rather than in the browser. This way of using Simplenote can be fully offline, so notes never get to the web. The MCP also works with this setup.

Users can also opt out of tracking completely with a single command.

We both spent a lot of time making sure we understood what the AI was doing and whether it was the right way to do it.

How they built it

Connecting AI to Simplenote was only half the story. AI also helped build it.

“We worked really hard at not just vibe coding this, letting the AI crank out whatever and not knowing what it was doing,“ Mark explained. “We both spent a lot of time making sure we understood what the AI was doing and whether it was the right way to do it.”

The team applied guardrails to their own process, not just to the LLM’s behavior at runtime.

“We didn’t just say, ‘hey, build me an MCP server,’” added Evan. “We had the documentation and the scope of the project lined up. We used issues in Linear, pull requests, and automated tests, kind of like guardrails around the AI.”

Working with multiple AI tools created a separate problem: keeping the codebase consistent.

“The agents’ markdown files, which definitely helped to keep [the project] on track, made it easy to review, and ensured that, in the end, it looks like a uniform code base,” Evan said. “It’s not like parts of it look different depending on which AI agent or which prompts we used.”

This is especially important because Simplenote MCP and Simperium, the open source sync backend that powers Simplenote, are both publicly available on GitHub.

“This is available as an open source project,” said Mark. “People could fork it, people could submit their own enhancements or bug fixes to it. And so we wanted to make sure that the project was organized from that perspective as well, in case there are outside contributors who want to add anything.”

The number of open source contributions the project receives is just one of the metrics the team will watch.

“I think it’s just going to be: are people using it?” said Mark. “That’s the first level of success. We don’t have a number in mind. But if anybody’s using it at all, I’m going to be excited.”

He added: “A second layer of success would be if we actually started getting some outside contributions.”

The Simplenote MCP shows a pattern other teams can copy: Set numeric limits on writes, so an LLM can’t run wild. Record which tools ran on which platform, but never what the user wrote. Let users turn telemetry off with a single command. Apply the same discipline to how the AI writes the code as you do to how it runs at runtime. None of this is technically difficult. It just has to be decided early.

The new Simplenote MCP currently works with Claude Desktop, Claude Code, Cursor, VS Code (Copilot), Zed, Cline, Windsurf, and anything else that speaks MCP. Give it a try, and, in the comments below, please let us know what you think.