Last week I had a new plugin idea, as I’m sure many developers do. Typically I put the idea on a list somewhere, in Trello maybe, and then I get over the idea and delete it. This time, however, I decided to turn it into a little experiment: how far could I get writing the plugin using only Github Copilot, the AI pair-programmer that I’ve been having a little fun with recently.

So I’ve started a repo: Habit Streak. The idea is simple: display some indicators inside WordPress of your current “streak” of writing content. I’ve had this daily blogging goal this year (well, I’ve had the goal for a decade, but this year I’m trying it in earnest). So I want a simple plugin that shows my current daily streak in the admin tool bar, something like: “Streak: 5 Days”.

I also want the plugin to hook into the block editor’s “post publish” screen, to show you some positive feedback after publishing a new post. Maybe one day with confetti. And finally, I’ll need to add a basic settings screen to control things like which post types to include and which days of the week to ignore (in case your goal doesn’t include the weekend or is only a few days per week).

And I want Copilot to do it all for me. Or should I say… with me.

Along the way, I’m hoping to write a few blog posts, maybe record a few videos, of how it’s going. Mostly, I want to focus on some tips and tricks for using Github Copilot with WordPress development (as I tend to think pair-programming is going to be the next phase of development). Looking at the task list above, there’s going to be a lot of React and block editor work, so I think that’ll make it especially interesting. So here’s the first few lessons learned from my initial commit:

Smaller Pieces Always Win

Copilot seems to think it can write the entire plugin in one go. Well, it can’t. For some reason, it clearly had some idea of what I wanted, just based on the plugin description. And it kept trying to give me this huge function that included references to user_meta fields that I’d never really thought about or generated. And it had ideas on what a “streak” was that were almost opposite of what I was looking for.

If I had to guess, I’d think maybe there were similar ideas in its training data. Plus it assumed there was streak data “somewhere” in WordPress already and I was just trying to pull it out. The problem is, I need to calculate the streak fairly dynamically: I may need to count posts that were published before the plugin was activated, or count posts across multiple post types or authors. I need functions to actually run these calculations on request, not just pull metadata out of the database. I needed more than it was providing.

The best tip here is to break the goals of your plugin into a bunch of tiny parts or separate function names. Don’t expect Copilot to create the entire range of functions in one go. Give it smaller instructions, break big ideas into little ones. As I’m sure you know, this is just good advice for web development in general. But it also means you can’t just turn off your own brain here. There’s a reason it’s called “Copilot” and not “Pilot”.

Your Standards and Expectations Have to be Explicit

I didn’t come into this plugin with huge expectations on coding standards or structure. I used the WP-CLI plugin scaffold, but that was about it. I assume I’ll want to use the WordPress Coding Standards, include modern PHP practices like namespaces, and use some amount of object-oriented programming. Honestly, I don’t have huge opinions here and wanted to see where Copilot decided to go.

Well, it basically decided to go with straight procedural programming until I explicitly told it otherwise (by creating a basic class). Again, I don’t have strong opinions either way, and neither does Copilot. And in the WordPress world, this makes sense. That said, the more you pull specific patterns into your style, the more it will try to mimic that.

The next set of features will require much more JavaScript, as I plan on writing the settings page entirely using the packages and React components from the JavaScript side of WordPress. Which means I’ll need to think more intentionally about file structure and build processes. These are areas where Copilot probably won’t have a lot to say until I create the actual files, but we’ll see.

Performance/Optimization isn’t the default

One shortcoming you’ll notice in the current codebase is that the initial query stops at 100 posts. If you have a streak longer than 100 day (props to you if you do!), it won’t show up. Why?

Well, number one- I thought a database query of every single post from a specific author might be a tad performance intensive. At this point, I’m calculating the streak every time you see it on the admin bar. I haven’t stored or cached it yet. The plan is to eventually pop it in the database and refresh it only on certain actions, such as save_post or after a certain amount of hours has passed. But until then, it’s running the query a lot.

Copilot wanted to use WP_Query, but that’s just overkill. I was able to add one line of code: global $wpdb; and Copilot quickly picked up on the idea that I wanted to build my SQL manually.

I just want it to be able to handle a large amount of posts without hogging too much memory. Honestly, I’m not sure what this will end up looking like, so this is all up in the air, but so far Copilot has nothing to say on questions of performance optimization. It may end up that I’m completely wrong about where the performance hits are. We’ll see.

The lesson here: the developer has to really think these things through, because there’s a good chance that Copilot will write code that just assumes everything is available all of the time. A good developer typically looks at their own code and sees opportunities for performance improvements, and Copilot’s code is no different.

---

That’s it for this installment. The skill of using Copilot is a lot like the “skill” of using Google. The more you know how to ask the right questions, the better you can be at finding the right answer. In some ways, using Copilot feels a lot like using Google + Stack Overflow to come up with code, just faster. I’m interested to see how it goes and I’ll try to post some progress here in the coming weeks.