Sometimes, a problem you didn’t know existed meets a solution you didn’t set out to build. That’s precisely what happened when a routine conversation about our developer docs turned into an AI-powered tool for our content team.
Here’s how it all came together:
How It Started
At the start of 2025, my team at Automattic (WordPress.com’s parent company) had taken over responsibility for updates and maintenance of the WordPress.com Developer Docs.
As part of this process, we met with Alexa, a content marketing manager for WordPress.com, to chat about processes and guidelines around this handover.
Toward the end of the meeting, Justin Tadlock, my team lead, asked a simple question, “Is there anything else we can help you with?” Alexa replied, “I have a question, but it’s unrelated to the docs. Do any of you know if a calendar view of GitHub Issues is possible?”
The Problem
Alexa explained that her team uses GitHub Issues and Projects to manage content publishing, a common practice in software companies.
The process generally worked well but was missing one critical piece for visibility into scheduled content and content gaps: a calendar view. Their team couldn’t view these content issues in a monthly calendar to get a quick snapshot of what was planned for the month ahead, as the GitHub Projects view only offers a roadmap-style view—helpful for developing software but not ideal for content planning. Nick Diego was in that meeting. You probably know Nick from his Revolutionize Your WordPress Development with Cursor AI video.
Since leadership at Automattic encouraged us to explore AI tools like Cursor, Nick and I had spent the past few months experimenting and had some fantastic successes, building everything from WordPress plugins to a desktop app for viewing a local WordPress debug log.
If you’ve never heard of Cursor, it’s an AI-powered code editor. Forked from the popular Visual Studio Code editor, Cursor takes the idea of AI-assisted coding to the next level by adding a ChatGPT-like agent to the mix. This AI-powered chatbot interprets your written prompts into working code. This concept has become so popular it even has its term—vibe coding, or using a large language model for coding.
We were both inspired by an Automattic Town Hall in December, where one of our engineering leads used Cursor to automatically generate a pull request for a project he was working on.
Now, I can’t say this for sure because it was across the digital divide of Google Meet, but I’m almost sure Nick and I looked directly at each other and had the same thought at the same moment.
“This is not that hard to solve with AI.” Nick was the first to express this idea, so we spent the next few minutes chatting about it. We both agreed that the only challenging part would be figuring out the right way to query the data we would need to fetch the relevant GitHub Issues from the project view; building the actual calendar app would be pretty easy.
Fortunately for us, our colleague Birgit Pauli-Haack was also on that call. She mentioned that, yes, GitHub Projects have a publicly queryable API. However, it was not a REST API but a GraphQL API. She had explored querying GitHub Project data with some success, but she hadn’t dived into something like this before.
Sitting on that call and listening to all this information, I felt like generating a calendar view for these GitHub Issues would be doable and relatively straightforward. I just had to:
- Figure out the GraphQL query.
- Use Cursor to build a web app around it.
How hard could it be?
Perplexity to the Rescue
The first thing I had to do was figure out the GraphQL query, and I’ll be the first to admit that my knowledge of GraphQL is limited.
I have written tutorials on using GraphQL to build static frontends for WordPress websites, also known as “Headless” or “Decoupled” WordPress sites. In that process, I used the WP GraphQL plugin that our colleague Jason Bahl developed; however, I’ve never used it in a production environment or used it to build a web app.
So I wondered if I could take a shortcut in this learning curve with AI and craft the GraphQL query without understanding it deeply and completely.
Then I remembered that WordPress.com had partnered with Perplexity. Perplexity is similar in many ways to ChatGPT, but it describes itself as an AI-powered answer engine that lets you research the web.
What I like about Perplexity is that when it outputs the generated AI response, it also includes all the sources of information it has used. If the answer you get from Perplexity isn’t quite what you were looking for, you can open the source links to do further manual research.I also needed a way to test and validate the GraphQL query that Perplexity would provide. Fortunately, GitHub has a GraphQL API Explorer, which allows you to authenticate with your GitHub account and run valid GraphQL queries on any private or public GitHub repositories you can access.
It took me a total of two Perplexity Threads (back-and-forth conversations with Perplexity) to figure out the GraphQL query. The first Thread was me asking it to build basic versions of the query, running them in the explorer, and then I fine-tuned the query based on the data from the explorer. After three rounds of fine-tuning, I started a new Thread and created a more specific prompt, using all the lessons I’d learned from the previous Thread. Testing that query in the Explorer returned the exact data set I’d need for the web app.
The Cursor Build
The next step was to begin app development with Cursor. One of the things that I discovered early on (both through Nick’s video and this Twitter thread) was the idea of using Cursor to generate an instructions file. The idea is to have a “conversation” with the Cursor agent and share the basic requirements of the application.
You then instruct the agent to write out those requirements to a requirements.md markdown file. Next, you ask the agent to go through the requirements file itself and ask you any clarifying questions about the requirements. As you answer the clarifying questions, you instruct the agent to update the requirements file.
Once you have the requirements file, you instruct the agent to create the instructions.md file based on the requirements file, which outlines the steps needed to build the application.
Because I already had the GraphQL query, I also added it to a file in the project directory. Armed with my requirements.md file, instructions.md file, and the file containing the query, I instructed the Cursor agent to start building the app step by step, following the instructions.
In about two hours, I had a working prototype. I returned to Perplexity once or twice to help me solve something that Cursor couldn’t do on its own. I wrote no other code beyond running one or two terminal commands to set up the project directory and its dependencies or running the development server to serve the app for testing.
It took me maybe another hour to polish the app the following Monday morning (mostly adding colors and making GitHub Issues clickable). By midday, I felt I had something very close to what Alexa’s team needed.
All that remained was to find an internal location to host it, which ironically took longer than the app build because this was so new.
By Wednesday, I shared the link with Alexa and my team in an internal post.
Everyone was really happy with the outcome. Alexa and a few of her teammates tested it out and picked up one or two small issues.
One of those bugs was interesting; it seems that Alexa saw all the items in the calendar one day before they were due to be published. I fed this info back to the Cursor agent, and it confirmed this was due to some timezone-related bug, which it promptly fixed.
One week later, we had a working GitHub Projects Content Calendar.
Final Thoughts
With all of the AI tools available today, software development is at an inflection point.
I felt the same way when Google introduced its search engine and Gmail. This is probably how people felt in 1886 when the first practical modern automobile was invented.
LLMs and AI agents will definitely change how we develop software, from speeding up how we learn new things to assisting us in our actual development.
I don’t believe they will replace the need for human developers because if we don’t use them responsibly, we’ll end up with mountains of inefficient code. But it’s certainly possible today to build things with a higher success rate than it used to be. Based on my experience creating the content calendar app, I made another GitHub-related web app that lets you view any GitHub issues assigned to you across all your GitHub repositories.
As someone who works across multiple repositories, I’ve wanted a dashboard like this for years—and I was able to build it myself!
Getting used to how these tools work also has other benefits. For example, you may have noticed that this blog post includes links to my colleagues’ online accounts or products’ websites. I added all these links simply by exporting the content to a markdown file and asking Cursor to “look for all proper nouns in the text, find the online URL for each one, and add the link to the proper noun.”
I needed to spot-check the links, but finding and linking them myself would have taken me half an hour. I did it in minutes with Cursor.
If you’re a developer, I encourage you to experiment with these tools. Your next great product idea may be easier to build than you think!
