This was the industry 25 years ago, back when I was first getting started in tech around the time of the dotcom crash.

Less than 10 years later, it was happening again: the iPhone had launched, so we’d figured out how to make mobile sites. Then the App Store launched, so we had to figure out how to build apps, instead. The development landscape was changing faster than any one person could keep up: how could you possibly be a good developer now?

Good Development Then

Even back then, writing the cleverest, or neatest, or fastest code was only a part of being a good developer. The industry was rapidly iterating on development practices and developer tooling: you didn’t write code in notepad.exe, you used a code editor, or perhaps even an IDE. You didn’t copy files into production, you used version control. These tools had existed in the corporate world for years, of course, but open source alternatives were making them available to anyone who wanted to be a a developer. They improved, too: adding auto-complete, templates, and integrating test environments for rapid iteration.

The democratisation continued, too: from the rise of Stack Overflow as a source of code snippets that you could easily re-use, to package managers made it even easier to re-use code on an industrial scale, through to the proliferation of through to the proliferation of transpilers and build tools. It got to a point where it where didn’t even really matter what language you wrote your code in. As long as you had the right build tool for it, it could run anywhere.

The history of our industry has been defined by a never-ending drive to increase the leverage of every keystroke, but it’s always been at something of a measured pace. But what happens when a giant leap occurs?

Good Development Now

A couple of year couple of years ago, LLM-based development tools were little more than slightly smarter (but infinitely slower) autocomplete, and it looked like they’d stalled there. A year ago, agentic development tools came along, and it was starting to look like there might actually be something useful here, though they were far too prone to making unacceptable mistakes. More recently, the current generation of agentic tools emerged, and we find ourselves able to generate production-ready code with minimal developer intervention.

So if we no longer need to write code, what becomes of the software developer?

Hint: you’re still coding, just at a a different abstraction level. Your job has always been to take a problem, and solve it with software. The exact method you used to produce that software has never been prescribed, you use the right tool for the job.

Right now, the tools are pretty messy. Concepts are changing week to week, state of the art last quarter is today’s legacy. I’m reminded of when the mobile web was first emerging, the horrible CSS hacks we’d previously reserved for Internet Explorer now had to be applied to make things work in mobile browsers, too. When we first started building mobile websites, they were entirely different code bases, but we slowly figured out how to make the same code work everywhere. The change came as a hurricane, the tooling followed later, cleaning up the mess.

HOWTO: Be a Good Developer

Once again, the tech industry is in a state of upheaval. The good news is, the exact same mindset that made you a good developer previously is what will keep you being a good developer today. Some of the bad habits we picked up along the way might have to go, though.

You can’t just look at the code in front of you any longer. Closing out your 5 tickets for the sprint won’t help you use agentic tools: it’s impossible to stick to your little corner of the machine if the tooling is suddenly able to reach everywhere. You need to learn how the entire system works: not necessarily so you can create code that spaghetti-fies its way through the system, but so you can know when it’s right to make changes elsewhere.

Think about the tools that always made it easiest for you to create good code. From the simplest code formatter to the most comprehensive test suite: these tools gave you fast, reliable, timely, and actionable feedback that you can act upon. The exact same tooling is what will give you the best output from agentic development tools today.

The same is true of process. Well-written, unambiguous requirements produced in a collaborative, iterative fashion creates clear guidelines for what needs to be built creates clear guidelines for what needs to be built. Useful code reviews that helped you learn more about the system you’re building inside of ensures you’ve built it the right way ensures you’ve built it the right way. Comprehensive real world testing with clear, actionable feedback checks that you’ve solved the problem.

Creating great software was never about being the most brilliant coder, it’s always been about creating an environment where great software comes naturally: that’s as true today as it was yesterday.

Raising the Floor

Information sharing has always been a key driver in pushing the software engineering practices forward. From the global Open Source movement right down to how your team works together, sharing compounds exponentially. Where one developer with a well-configured CI pipeline raises the quality of their own output, an entire team on the same pipeline raises the floor for everyone.

Start with shared guardrails. If you’ve set up a test coverage ratchet or a linter config that’s been improving your own work, propose it to the team. Champion it in a PR, explain why it caught something it would otherwise have missed, and make it part of your shared CI standard. Remember that you’re not trying to impose process, you’re aiming to help the team’s agents work to the same standard as yours. When everyone’s feedback loop is well-configured, the whole team moves faster with less rework.

Work on shared review culture. In code reviews, start asking questions like “what guardrails did you put in place?” and “how did you verify the agent’s output?” You’re not looking for gotchas: be genuinely curious, and find the patterns that can help evolve the tooling everyone uses.

Talk about what “done” looks like. Define acceptance criteria and type checks that everyone agrees on, so that agents across the team are working to the same standard, instead of individual interpretations of what’s good enough. Always remember that you’re not looking to create bureaucracy, you’re defining alignment: when developers and agents share a common north star, when you’re pulling in the same direction, the job becomes easier and you can move onto new and bigger opportunities.

Choose Your Own Adventure

There are big changes happening in the industry right now, the practice of software engineering is evolving to encompass agentic development tools. Your choice remains, however: just as you could always choose whether you prefer to use a full IDE, a code editor, or notepad.exe. Now you can choose to use the frontier LLMs, you can choose self-hosted LLMs. You can use the myriad of available harnesses, you can write something that works just for you. Previous generations of software engineering practices didn’t disappear because something new came out, they adapted to work with the best bits, and kept the rest optional.

This is a time of exciting and challenging opportunities: just as has happened before, we’re defining what the practice looks like for the coming decades. Start with something small, perhaps have a chat with your lead about what their view is, I promise they’re trying to figure out what it all means just as much as you are! Now is a good time to take care of technical debt: agents work best in a consistent environment, so cleaning up some of those old abstractions and interfaces will help increase the momentum. Keep learning: my years in this industry has taught me that nothing ever stays the same, there’s only one way to continue improving your craft.

Feed your curiosity.

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.