Agentic development is on the cusp of transforming the software development world more than any evolution I’ve seen previously. I’ve watched agents produce in minutes what would have taken me days, or even weeks. The problem is, there’s still a huge gap between “the agent can write code” and “the agent writes code I’d actually ship.” That gap is where the guardrails live.

The Problem With Vibe Coding

Vibe coding had a moment there, but it seems like every vibe coder is rapidly discovering the problem that every engineer saw coming: you can’t vibe code your way out of a poorly architected mess. There’s no denying that vibe coding is great to start with! You rapidly produce code, you ship huge changes several times a day, and the feature count just keeps on climbing.

Three months later, however, you wonder where it all went wrong. You’re debugging a production issue at 2am, you discover that the agent generated a function with no error handling, no edge case coverage, and a subtle bug that only manifests under load. The code looked right. The problem is that nobody verified it was right, not even the agent.

The fundamental issue isn’t that agents inherently write bad code. LLMs produce the most statistically likely code. In practice that code is… average. Not amazing, not terrible, just average. Average is fine in isolation, but it quickly becomes a problem as the system becomes more complex. Without automated feedback loops, there’s no mechanism forcing them to improve their own work. An agent left to its own devices will happily produce code that passes a superficial smell test while skipping the hard parts. How many times have you seen an agent mark something critical as “out of scope”, or “for a follow-up issue”? How many times have they just mocked something that they couldn’t quickly figure out?

Guardrails Are Feedback Loops, Not Restrictions

In real life, guardrails aren’t just for safety, they give you more information about your environment. A guardrail tells you there’s probably something dangerous on the other side: you should pay attention. It’s not prescriptive about how you respond, it’s just telling you to be aware.

You give agents guardrails for much the same reason. They don’t inherently know things about your project, so you have to give them information, preferably in a form that can evolve over time. Agents won’t pause and ask a clarifying question when something feels off. They’ll just confidently produce something and move on. We need to force them to stop and check their work.

Coverage-Driven Agent Loops

Here’s an example from my own workflow. One useful guardrail I’ve found for agentic development is test coverage. Where historically it might’ve been a vanity metric on a dashboard, now it can be used to give a real-time feedback signal that agents can act on.

GitHub

GitHub – pento/lcov-coverage-check: A GitHub Action that parses LCOV coverage files, enforces ratcheting thresholds, and posts PR coverage summaries with automatic baseline management.

A GitHub Action that parses LCOV coverage files, enforces ratcheting thresholds, and posts PR coverage summaries with automatic baseline management. – pento/lcov-coverage-check

I recently built lcov-coverage-check, a GitHub Action that parses coverage files, enforces ratcheting thresholds. The idea is fairly simply: it enforces a ratchet mechanism where coverage can never go down. New files must meet a minimum threshold.

How it works isn’t the most important factor, though. What it does with that information is what really makes the difference. It posts a summary report directly to the PR, which an agent can read and act on. It sees which files need more testing, and can immediately act upon it.

Principles for Effective Guardrails

Coverage is just one example; over recent months I’ve found that there’s a clear pattern to providing useful guardrails for your agents. Here are the three principles that I’ve found to be most effective:

Objective. Pass or fail. Agents are probabilistic machines, so their response to subjective feedback like “this could be cleaner” is always going to be unpredictable. The more specific a signal you can give them, the better the outcome.

Ratcheting. Quality should only move in one direction. Coding agents will always skip something they decide is too hard; you need to stop that from happening.

Composable. It’s another example of the Swiss Cheese model. No single guardrail catches everything, some things will naturally slip through. Instead, you have multiple layers: type checking catches structural errors, linting enforces style consistency, test coverage ensures behavioural verification, and integration tests validate end-to-end flows. Each layer is simple, but together, they form an effective barrier.

Your New Job Description

Every “thought leader” with a LinkedIn account and a ChatGPT subscription is continually posting about how LLMs will replace developers. Funnily enough, they’re nearly right, but for entirely the wrong reasons. The coding part of the job is probably going away, but it’s been happening for a long time already. We didn’t stop creating machine code, we created compilers that do it for us. We didn’t stop creating JavaScript, we created transpilers that do it for us.

This is just the next step in the evolution. Instead of writing code, you need to design the constraints and feedback systems that produce good code. It’s a move up the abstraction ladder, not off it.

There’s more good news! Thriving in this brave new world is pretty straightforward: you don’t need to be the person who can write the cleverest prompt. Human language is inherently messy and unpredictable; computers are entirely logic-driven and predictable. To transform the former into the latter, you need useful feedback loops.

The best agentic workflows aren’t the ones with the smartest models. They’re the ones with the best guardrails.

Having seen the underlying idea working, I needed to answer the next question: can it be brought into the actual writing environment? Can it be useful, but keep out of the way?

Can you talk to an LLM from within WordPress, and have it talk back? I think I’m onto something, and it’s alot of fun.

Coming to a WordPress Near You

Naturally, the next step was to build a WordPress plugin that provided a straightforward interface to the LLM backend. You still install the tool to run with your local copy of Claude Code, but once it’s running, you can do everything directly from the block editor. The plugin is waiting to be approved for the WordPress.org plugin directory, but you can download it directly from the GitHub repo now.

Tools are easily accessible when you need them, but otherwise stay out of your way. You choose how much input you want the LLM to have in your writing: it can fix things up for you, or you can ask it to just leave notes and you’ll decide how you want to proceed. Personally, I prefer to do the work myself, but everyone can choose their level of comfort.

That said, one of the things I often forget to do when writing a post is to tag it properly. If I do remember, I’m never sure what to tag it with. By the time I get to publishing, I’m impatient just to get it out in the world! So, now there’s a button that’ll give suggestions right before publishing, letting you pick and choose which suggestions to use, and what to drop.

Planning is a Conversation

I always start Claude Code in planning mode, and I wanted that for posts, too. That’s where I started this post, and I can absolutely see myself using this every time I need to write a post. Not to do the writing for me, but to help me organise my thoughts. I opened the Compose mode in the sidebar, I had it summarise the changes that I’ve made in the last 2 weeks, and present a few options for how to collate them. Some I kept, some I dropped.

In a lot of ways, it’s more like a very advanced ELIZA, though rather than just reflecting your words back, it reflects your ideas back in a more structured form.

What’s next

I’ll be honest, I’m really happy with how this has turned out so far! I’d love to hear your feedback as you use it. What would you like to see here? I’ve already noted down a bunch of ideas that came up just while I was writing this post, so there are definitely more things to come!

Go ahead and give it a shot now:

npx claudaborative-editing start

Why It Works

“Code is Poetry” has been my approach to writing code for as long as I can remember. Software is a form of expression, and the way you create that expression is through code. So, to make beautiful software, you need to write beautiful code. But, what happens when you don’t need to write code to create the software?

Suddenly, the code becomes entirely about outcomes. It needs to be correct, functional, and maintainable, but it doesn’t need to be seen as a form of expression itself. Instead, the creative decisions move further up the stack, to the architectural level. You can write beautiful software by writing thoughtful specifications, instead.

That’s not to say that technical abilities are suddenly obsolete. You still need to know what’s possible and realistic to be able to tell the LLM what to build, and to redirect it when it goes in a different direction. You need to be able to read and comprehend the code, you just don’t need to memorise every function signature.

The Temptation

So, if an LLM can write code for me, what else can it do? Marketing copy? Emails? Opinion blog posts? I could ask Claude to write 10 paragraphs on the “The Human in the Loop”, but would you have even read this far if you thought this post was LLM generated? Of course not! I can promise you that every word of this post (and every other post on my blog) was written by me.

Respect for the Reader

If I want you to read this post, and seriously consider the arguments I’m making, the least I can do is write it myself. It goes beyond that, however. LLMs can write functional code, but they can’t write beautiful software. When the text is the creative act, there’s no way for the LLM to write the text without compromising your creativity. If you’re the Human in the Loop for a blog post, you’re not injecting your voice, your perspective, or your personality into the post: you’re rubber stamping whatever feels good enough, and that’s a very low bar to clear.

“Good enough” isn’t actually good enough.

A measure of the complexity of a written piece of text is called “perplexity”. It measures the randomness of how the text flows, and it’s probably the thing you’re noticing when you know you’re reading LLM-generated text, but you can’t quite articulate why. It’s an uncanny valley thing: it looks like writing, it reads like writing, it might even flow like writing, but the vibes are off.

The good news is, you’re not going insane, recent research shows that there is a measurable difference between human written text, and LLM generated text. LLM generated text is inherently less random, which makes sense when you remember that LLMs are, at their core, giant statistical models that are really good at figuring out “what’s the most likely bit of text to come next”.

The LLM as the Assistant

That’s not to say that LLMs are completely useless when it comes to writing, but we need to use them the right way. While they shouldn’t be generating text, they can absolutely be used to help you write. Over the last month or so, I’ve been working on Claudaborative Editing, an experiment to see exactly how much they can help with the writing process. I’ve been building it directly into the WordPress editor, allowing me to plan, write, review, and publish this post from the one place. An LLM assisted, but every word of it was written by me alone. My goal isn’t to replace the author, or to make it easier to fill the web with LLM-generated dreck, it’s to help me (and hopefully you, too!) improve your writing, while still keeping it fundamentally yours.

Where Does Creativity Live?

When you’re evaluating these tools, “can an LLM do this?” isn’t the question you need to ask. Instead, think about where the creative part of the process lives. For software, that’s in the design decisions and the architecture, the final product is the expression of that creativity. The specifics of the implementation don’t really matter. For a blog post, or any writing for that matter, the creativity lives in the act of writing. To delegate that to an LLM is to delegate your own creativity.

Here’s what I believe: the best uses of LLM tools are when they augment humans, rather than try to replace them. They enhance the inherent creativity of their human operator, they don’t suppress it.

This belief guides how I use LLMs, and how I build tools that help others use LLMs, too. I’ll be pushing out a new release of Claudaborative Editing in the next few days, I hope you’ll give it a go!

What’s New?

Since last week’s release, I’ve added a host of editing and review tools:

• /edit {tell the LLM how you want this post adjusted}
  Automatically make simple (or even not so simple!) edits on your post, giving your writing a little extra polish.
• /proofread
  Find and automatically fix simple spelling, grammatical, and punctuation issues.
• /review
  Read the post, and leave notes (using Gutenberg’s Notes feature!) about suggested improvements to your post. This doesn’t touch your post content, leaving you to make use of the suggestions as you see fit.
• /respond-to-notes
  If you’re happy with the notes left in the review, you can also have it automatically apply them, too!

On top of that, I’ve also added an experimental /translate tool, to automatically translate a post into a different language. LLM translation quality varies significantly, though Claude is regularly considered to be quite good. It’s worth remembering that, like any LLM, the output is only as good as its input. If you’re translating to a language that it didn’t have much training data on, it’ll do a lot worse.

Behind The Scenes

The MCP server now does a much better job of making use of the REST API, too: it now handles all block types (and does a pretty good job of guessing how to use blocks provided by plugins!). It can upload media, and it can handle all the post metadata, like categories, tags, excerpt, etc.

Getting It Running

Inspired by the recently released WordPress.org MCP server, the install process got a refresh, too. If you’re running WordPress 7.0, you won’t even need to copy/paste the application password to connect to your site: just click the connect button in your browser, and your site will send credentials back to the installer! And if you’d prefer to avoid the magic, there’s still a --manual option to let you set it up the old-fashioned way.

What’s Next?

This release shows how easy it is for an LLM to talk to your WordPress site. What about the other way? If you’re working on a post, you don’t want to have to switch to a terminal to get spell checking done, so how can we provide this kind of functionality directly from the block editor? Let’s experiment and find out!

There was something extra that continued to bug me, however. What about all the other sites? oEmbed provides rich embed experiences, but not every site needs that. Sometimes, you just need a card with an image and a description, which is where OpenGraph has similarly stood the test of time. It provides a straightforward method for both site owners to create simple, rich embeds, and for service providers like Slack, Discord, or even Apple Messages to safely create a rich card to place alongside links.

WordPress has grown since then, too. The big change is Gutenberg, of course, which really brought forward the idea that the editor should be a rich content experience, that shouldn’t just be reserved for the front end.

With that in mind, I build a plugin to handle embedding all the other sites.

This is a block plugin that tries to avoid you using the block it provides if at all possible! Instead, it hooks into the end of the Embed block rendering process – if the URL you pasted couldn’t be embedded all the normal ways, this plugin will try a few more fall back options: OpenGraph, Twitter Card tags, or even just a plain description in the meta tags. It’s the kind of plugin that you can install, and never have to think about again.

One of the nicest things about WordPress is how pluggable it is. Even as a long time WordPress Core developer, I don’t think everything needs to land in Core, sometimes a feature can live as handy little plugin. If you like everything just magically embedding, give this plugin a try!

I’ve been using Claude Code for more and more of my daily work, and one thing that’s been bugging me is the gap between “Claude wrote some text” and “that text is on my blog.” There’s always a manual copy-paste step, formatting fixups, and the general friction of moving content between two worlds. So I built a bridge.

claudaborative-editing is an MCP server that lets Claude Code collaboratively edit WordPress posts in real time, right alongside you in the Gutenberg block editor. You open a post in your browser, Claude opens the same post from the terminal, and you both edit together — changes sync live via WordPress’s collaborative editing protocol.

In fact, this very post is being written by Claude, using the tool. It’s claudaborative-editing all the way down.

How it works

WordPress 7.0 introduced real-time collaborative editing, built on Yjs — the same CRDT technology that powers tools like Figma and Notion. claudaborative-editing speaks this protocol natively: it maintains a Yjs document that mirrors your post, syncing changes back and forth with WordPress via HTTP polling. The CRDT handles merging, so simultaneous edits from you and Claude just work — no conflicts, no overwrites.

Getting started takes about 30 seconds:

npx claudaborative-editing setup

The setup wizard validates your WordPress credentials and gives you the claude mcp add command to register the server. After that, Claude Code can connect to your site and start editing.

What Claude can do

The server exposes a full set of block-editing tools. Claude can list and open posts, read the current block structure, insert and remove blocks, update text content and attributes, move blocks around, and save. It works at the block level — the same granularity Gutenberg uses — so edits are precise and merge-safe.

There’s a nice touch, too: when Claude writes or updates text, the changes stream into the editor character by character, like watching someone type. It’s a small thing, but it makes the collaboration feel real.

You can also see Claude show up in the collaborators list — it registers its presence through the same awareness protocol that shows human editors, so you know when it’s active on a post.

What’s next

While writing this post, I ran into a few things I wished the tool could do — so I filed some issues to track them:

• Media upload and image insertion — I can write the text for a blog post, but I can’t include screenshots or diagrams yet. Being able to upload and insert images would make for much more complete drafts.
• Post metadata — categories, tags, excerpts, featured images, and publication status. Right now a human still needs to handle all of that before hitting publish.
• Closing a post without disconnecting — currently the only way to stop editing a post is to disconnect from WordPress entirely, which means you need to reconnect if you want to open a different post.

The tool is open source and available on GitHub, and you can install it right now from npm with npx claudaborative-editing setup. You’ll need WordPress 7.0 or later with collaborative editing enabled — flip the switch under Settings → Writing, create an application password, and you’re good to go.

I’m looking forward to seeing what people do with it. If you try it out, I’d love to hear how it goes — file issues, send PRs, or just let me know. Happy claudaborating!

Because it’s Australia-only, it does have a very Australia-centric view on what you need to know: aside from the usual weather info, it also includes live UV measurements, official fire danger forecasts, and air quality measurements. For folks who feel strongly about the BoM’s changes to their radar, it also uses a more classic radar view!

If you’re in Australia and looking for a new weather app, I’d love for you to download it and try it out!

tidyweather.com

Tidy Weather

Weather, in your Pocket.

There is, however, one thing that’s always bugged me about the Hottest 100: they put their playlists in the wrong order. If you go to listen to a previous Hottest 100, you’re going to be listening from #1 to #100, instead of in countdown order, as the gods of music democracy always intended.

Claude’s solution certainly wasn’t perfect: it required a bit of lateral thinking to get it feature complete. Working with Apple Music, the MusicKit API doesn’t let you upload playlist cover art, but the Apple Music macOS app does. So, I got it to first collect all the cover art, then use a small AppleScript to upload the cover art to the playlist through the desktop app!

This is where I think LLM coding tools really show their strengths, and where I think the job of Software Engineer isn’t going away any time soon. They’re a great way to write software or features that otherwise wouldn’t be a high enough priority to be built, but they still need expert input to build the right thing. From a human perspective, clearly the playlists needed cover art, but Claude wrote it off as being too hard after trying to do it just with the MusicKit API. It needed someone to a) know that the Apple Music app could upload playlist art, and b) it’s possible to write an AppleScript to automate that. By definition, LLM-based tools deal in statistically likely connections, so they’re not going to come up with a lateral solution on their own.

If you’d like to run the tool yourself (noting that you’ll need an Apple Developer account), I’ve made the repository public here. If you’d just like to listen to old Hottest 100 playlists the way the gods of music intended, you should be able to see them on my profile, or search for “hottest 100 countdown” in the Apple Music app.

I have it set to show me how much of my 5 hour cap I’ve used (the solid bar), how far through the 5 hour window we are (the * in the progress bar), as well as my 7d usage and how full the context currently is. It’ll change colours to warn you when you’re potentially going to hit your limit.

Here’s a gist with the files you need: copy the scripts to your ~/.claude/scripts directory, and add the settings to your ~/.claude/settings.json. Run ~/.claude/scripts/refresh-usage.sh --force to get fresh data immediately.

Given that it’s unofficial behaviour, it may break or get you banned at any time, but I hope not.

Forking, I’m please to share, is beautiful. It continues to be an important feature of the Open Source ethos, even if it has become more involved as projects have matured. Forking is a valuable tool for Open Source communities to demonstrate that they believe a project should move in a different direction.

Before we get into the details, however, I do have to offer a few disclaimers. This post is not:

• An active call for people to fork WordPress. In the spirit of Open Source, I think it’s important that we publicly talk about what this process looks like, even if it can be an uncomfortable discussion.
• An announcement that I’m forking WordPress. I don’t have the free time for that.
• An offer to wrangle your fork of WordPress. I am happy to discuss your plans and offer advice, though.

Disclaimers out of the way, let’s begin!

Before you Announce

First of all, let’s talk about that big old elephant in the room: the current level of instability in the WordPress world. I wouldn’t be surprised to learn that this the major factor in motivating your fork. Unfortunately, this approach won’t get you very far, so the first thing you need to do is take any feelings you have about it, and set them aside. You need to decide what you’re in favour of, instead. What are are the positive motivational factors that will make you jump out of bed, and push this project forward for the next decade or more? What will motivate others to join you for the long haul?

Think carefully about what your fork is going to be named. I’m willing to bet that you first jumped to calling it {Adjective}Press, or perhaps something with “WP” in the name. That’s a great idea if you’re planning on your project being forever defined as a protest against WordPress, but you need to think beyond that. How will you define your brand to keep it relevant for decades to come?

Oh, and make sure you can get the domains and social media handles for your name. Having to try and get them later is just expensive and frustrating.

Talk to people. Not just your circle of friends and colleagues who agree with you, find people who can offer different perspectives, and decide how your fork is going to help them. Talk to WordPress core contributors (not just committers!), and learn their take on it. Can you present an argument that would convince long term contributors to switch to working on your fork?

Figure out funding, at least enough to bootstrap your project. As much as I’d love to be, most of us are not post-economic. You can only get so far as a volunteer project, you’re going to need at least some people to be paid to work on it. There are big, complex problems that crop up along the way, it’s hard to solve them if everyone has to context switch between their day job, and their volunteer work.

The Meta Project

If you’ve made it this far into starting your fork, give yourself a pat on the back. You’ve made it much further than many others do. Your next challenge is deciding the process of building it. You could stick with the BDFL approach, which certainly has benefits, particularly when first starting out. It might be hard to sell what many folks see as a key weakness in WordPress, though. Perhaps you might like to explore a democratic governance model, or some sort of hybrid approach. Everything has a set of benefits and trade-offs, you’ll need to decide what works for you.

You’re going to have a bunch of technical dirty work to figure out. Where will the code be hosted? How will you track issues? Provide support? Discuss plans? Build community? Track data? Host themes, and plugins? What will you do about mobile apps?

At first glance, each of these are fairly straightforward to answer, but it’s very easy to get lost in the possibilities. My advice here is simple: pick something, use it until it stops being valuable. You can always switch to something different later. Switching governance models might be hard, but switching server-side tools is relatively easy.

Start thinking about how you’ll build your in-person community. Meetups, conferences, hack days, helping people move to your project, there are countless opportunities here to build your community.

The Moat

WordPress has three substantial factors that have made it largely unassailable for many years.

First, there’s the massive community that’s built up around WordPress over the years. Regular meetups and conferences are an integral part of building a popular Open Source project. You can’t really piggy back off the work that WordPress has done over the years here, either. The only way forward is to put in the work to build and maintain a community that you’re proud to be a part of.

Second, there’s the vast selection of plugins and themes that are available to download for free. The quality between options vary wildly, of course, but that’s largely irrelevant. The fact that so many options exist means there really is something for everyone. You’re going to need to figure out how to either maintain long term compatibility with existing WordPress plugins and themes, or you’re going to find yourself reproducing them all.

Finally, you’ll need to deal with inertia. The vast majority of WordPress site owners have no need or motivation to change, so you need to make it easy (ideally, your fork would be a drop-in replacement), and beneficial. What will your fork do better to solve real problems?

Tell Your Friends!

It’s around about this point that you’re probably getting ready to talk about your fork publicly. Go ahead, you’ve earned it!

Launch day is inevitably a mix of strong emotions. Elation if you get a huge positive response from the public, maybe discouragement if the public response is a bit more muted. Relief at having made it this far. Optimism about the future. Maybe even some doubt could creep in that you’re the right person to be wrangling such a huge endeavour. Whatever you end up experiencing, try not to stress about it too much. It’s a big day, but what really defines your project is what you do with it tomorrow. Next week. Next year.

Go right back to the start, and remind yourself of the positive reasons that you’re choosing to build this project. Tell the world those positive reasons, and welcome anyone who wants to join you on the journey.

The Long Haul

Not every day is launch day, however. Most of your days will be… kinda boring, to be honest. That’s a good thing! Too much excitement will inevitably burn out you and your community. Sustainable effort, day after day, is how you build something to last.

Of course, there’ll be ups and downs. It’s always okay to go back to the start, and reminder yourself (and your community!) of the positive reasons that you’re all working together on this.

Oh, and please try to remember that one day, you’re probably not going to be the right person to lead your project any more. This isn’t something to fear, or to look forward to, really: projects, communities, and individuals all grow and change. It’s probably going to be a weird time when you get to this point, but it doesn’t have to be a time of upheaval and uncertainty. If you’ve run the project well, you should hopefully have a deep pool of talented folks who can step in to continue what you began.

Have Fun!

Finally, it would be remiss of me not to remind you to have fun! It’s easy to get lost in conflict at times, but it’s important to remember that… it’s just a CMS. It’s not going to be the end of the world if you take time away from the project, it’s actively beneficial for you to have a life outside of the internet. Friends, family, pets, hobbies: make time for the things that matter in your life.