OK. Deep breath. This is surreal. I just added an entirely new feature to my software, including UI and functionality, just by typing four paragraphs of instructions. I have screenshots, and I’ll try to make sense of it in this article. I can’t tell if we’re living in the future or we’ve just descended to a new plane of hell (or both).
Let’s take a step back. Google’s Jules is the latest in a flood of new coding agents released just this week. Last week, I wrote about OpenAI Codex and Microsoft’s GitHub Copilot Coding Agent, and ZDNET’s Webb Wright wrote about Google’s Jules.
Also: The best AI for coding in 2025
All of these coding agents will perform coding operations on a GitHub repository. GitHub, for those who’ve been following along, is the giant Microsoft-owned software storage, management, and distribution hub for much of the world’s most important software, especially open source code.
The difference, at least as it pertains to this article, is that Google made Jules available to everyone for free. That meant I could just hop in and take it for a spin — and now my head is spinning.
Usage limits and my first two prompts
The free access version of Jules allows only five requests per day. That might not seem like a lot, but in only two requests, I was able to add a new feature to my software. So, don’t discount what you can get done if you think through your prompts before shooting off your silver bullets for the day.
Also: How to use ChatGPT to write code – and my favorite trick to debug what it generates
My first two prompts were tentative. It wasn’t that I wasn’t impressed; it was that I really wasn’t giving Jules much to do. I’m still not comfortable with the idea of setting an AI loose on all my code at once, so I played it safe.
My first prompt asked Jules to document the “hooks” that add-on developers could use to add features to my product. I didn’t tell Jules much about what I wanted. It returned some markup that it recommended dropping into my code’s readme file. It worked, but meh.
I did have the opportunity to publish that code to a new GitHub branch, but I skipped it. It was just a test, after all.
My second prompt was to ask Jules to suggest five new hooks. I got back an answer that seemed reasonable. However, I realized that opening up those capabilities in a security product was just too risky for me to delegate to an AI. I skipped those changes, too.
It was at this point that Jules wanted a coffee break. It stopped functioning for about 90 minutes.
That gave me time to think. What I really wanted to see was whether Jules could add some real functionality to my code and save me some time.
Necessary background information
My Private Site is a security plugin for WordPress that runs on about 20,000 active sites. It puts a login dialog in front of the site’s web pages. There are a bunch of options, but that’s the plugin’s key feature. I acquired the software a decade ago from a coder who called himself “jon radio” and have been maintaining and expanding it ever since.
Also: Rust turns 10: How a broken elevator changed software forever
The plugin provides access control to the front-end of a website, the pages that visitors see when they come to the site. Site owners control the plugin via a dashboard interface, with various admin functions available in the plugin’s admin interface.
I decided to try Jules out on a feature some users have requested, hiding the admin bar from logged-in users. The admin bar is the black bar WordPress puts on the top of a web page. In the case of the screenshot below, the black admin bar is visible.
I wanted Jules to add an option on the dashboard to hide the admin bar from logged-in users. The idea is that if a user logged in, the admin bar would be visible on the back end, but logged-in users browsing the front-end of the site wouldn’t have to see the ugly bar.
This is the original dashboard, before adding the new feature.
Some years ago, I completely rewrote the admin interface from the way it was when I acquired the plugin. Adding options to the interface is straightforward, but it’s still time-consuming. Every option requires not only the UI element to be added, but also preference saving and preference recalling when the dashboard is displayed. That’s in addition to any program logic that the preference controls.
Also: I test a lot of AI coding tools, and this stunning new OpenAI release just saved me days of work
In practice, I’ve found that it takes me about 2-3 hours to add a preference UI element, along with the assorted housekeeping involved. It’s not hard, but there are a lot of little fiddly bits that all need to be tweaked, and that takes time.
That should bring you up to speed enough to understand my next test of Jules. Here’s a bit of foreshadowing: The first test failed miserably. The second test succeeded astonishingly.
Instructing Jules
Adding a “hide admin bar” feature would not have been easy for the run-of-the-mill coding help we’ve been asking ChatGPT and the other chatbots to perform. As I mentioned, adding the new option to the dashboard requires programming in a variety of locations throughout the code and an understanding of the overall codebase.
Here’s what I told Jules.
1. On the Site Privacy Tab of the admin interface, add a new checkbox. Label the section “Admin Bar” and label the checkbox itself “Hide Admin Bar”. [Place this in the MAKE SITE PRIVATE block, located just under the Enable login privacy checkbox and before the Site Privacy Mode segment.]
I instructed Jules where I wanted the AI to put the new option. On my first run through, I made a mistake and left out the details in square brackets. I didn’t tell Jules exactly where I wanted it to place the new option. As it turns out, that omission caused a big fail. Once I added the sentence in brackets above, the feature worked.
2. Be sure to save the selection of that checkbox to the plugin’s preferences variable when the Save Privacy Status button is checked.
This ensures that Jules knows there is a preference data structure and that it is updated when the user makes a change. It’s important to note that if I didn’t understand the underlying code, I wouldn’t have instructed Jules about this, and the code would not have worked. You can’t “vibe code” something like this without knowing the underlying code.
3. Show the appropriate checked or unchecked status when the Site Privacy tab is displayed.
This tells the AI that I want the interface to be updated to match what the preference variable specifies.
4. Based on the preference variable created in (2), add code to hide or show the WordPress admin bar. If Hide Admin Bar is checked, the Admin Bar should not be visible to logged-in WordPress front-end users. If the Hide Admin Bar is not checked, the Admin Bar should be visible to logged-in front-end users. Logged-in back-end users in the admin interface should always be able to see the admin bar.
This describes the business logic that the new preference should control. It requires the AI to know how to hide or show the admin bar (a WordPress API call is used), and it requires the AI to know where to put the code in my plugin to enable or disable this feature.
And with that, Jules was trained on what I wanted.
Jules dives into my code
I fed my prompt set into Jules and got back a plan of action. Pay close attention to that Approve Plan? button.
I didn’t even get a chance to read through the plan before Jules decided to approve the plan on its own. It did this after every plan it presented. An AI that doesn’t wait for permission raises the hairs on the back of my neck. Just saying.
I desperately want to make a Skynet/Landru/Colossus/P1/Hal kind of joke, because I’m freaked out. I mean, it’s good. But I’m freaked out.
Here’s some of the code Jules wrote. The shaded green is the new stuff. I’m not thrilled with the color scheme, but I’m sure that will be tweakable over time.
Also: The best free AI courses and certificates
More relevant is the fact that Jules picked up on my variable naming conventions and the architecture of my code and dived right in. This is the new option, rendered in code.
By the time it was done, Jules had included all the code changes it had originally planned, plus some test code. I don’t use standardized tests. I would have told Jules not to do it the way it planned, but it never gave me time to approve or modify its original plan. Even so, it worked out.
I pushed the Publish branch button, which caused GitHub to create a new branch, separate from my main repository. Jules then published its changes to that branch.
This is how contributors to big projects can work on those projects without causing chaos to the main code line.
Up to this point, I could look at the code, but I wasn’t able to run it. But by pushing the code to a branch, Jules and GitHub made it possible for me to replicate the changes safely down to my computer to test them out. If I didn’t like the changes, I could have just switched back to the main branch, and no harm, no foul. But I did like the changes, so I moved on to the next step.
Around the code in eight clicks
Once I brought the branch down to my development machine, I could test it out. Here’s the new dashboard with the Hide Admin Menu feature.
I tried turning the feature on and off and making sure the settings stuck. They did. I also tried other features in the plugin to make sure nothing else had broken. I was pretty sure nothing would, because I reviewed all the changes before approving the branch. But still: Testing is a good thing to do.
I then logged into the test website. As you can see, there’s no admin bar showing.
At this point, the process was out of the AI’s hands. It was simply time to deploy the changes, both back to GitHub and to the master WordPress repository. First, I used GitHub Desktop to merge the branch code back into the main branch on my development machine.
<!–>
–>
