Google's Jules AI Codes New Feature Instantly

A new feature, including UI and functionality, was added to software by typing four paragraphs of instructions. Google's Jules is a new coding agent. Other coding agents perform coding operations on a GitHub repository. GitHub is a software storage, management, and distribution hub. Google made Jules available to everyone, for free.

The free access version of Jules allows only five requests per day, but it was possible to add a new feature to the software in only two requests. The first prompt asked Jules to document the "hooks" that add-on developers could use to add features to the product. It returned some markup to drop into the code's readme file. The second prompt was to ask Jules to suggest five new hooks, but opening up those capabilities in a security product was too risky.

Jules stopped functioning for about 90 minutes. The goal was to see whether Jules could add some real functionality to code and save some time. Private Site is a security plugin for WordPress, running on about 20,000 active sites. It puts a login dialog in front of the site's web pages. The plugin provides access control to the front-end of a website. Site owners control the plugin via a dashboard interface. Jules was tested 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. The goal was for Jules to add an option on the dashboard to hide the admin bar from logged-in users, so the admin bar would be visible on the back end, but not to logged-in users browsing the front-end of the site.

Adding options to the interface is time-consuming, requiring the UI element to be added, preference saving, and preference recalling when the dashboard is displayed, in addition to program logic. It takes about 2-3 hours to add a preference UI element, along with the assorted housekeeping involved.

The Test

Adding a hide admin bar feature requires programming in a variety of locations throughout the code and an understanding of the overall codebase. Here's what Jules was told:

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.
2. Be sure to save the selection of that checkbox to the plugin's preferences variable when the Save Privacy Status button is checked.
3. Show the appropriate checked or unchecked status when the Site Privacy tab is displayed.
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.

The first test failed. The second test succeeded. Jules was fed a prompt set and returned a plan of action, approving the plan on its own. Jules picked up on variable naming conventions and the architecture of the code. By the time it was done, Jules had written in all the code changes it planned for originally, plus some test code. Pushing the Publish branch button caused GitHub to create a new branch, separate from the main repository. Jules then published its changes to that branch. By pushing the code to a branch, Jules and GitHub made it possible to replicate the changes safely down to a computer to test them out. The changes could have been discarded by switching back to the main branch.

Once the branch was brought down to a development machine, it could be tested out. The new dashboard had the Hide Admin Menu feature. The feature was turned on and off to make sure the settings stuck. Other features in the plugin were tested. The test website was logged into, and there was no admin bar showing. The branch code was merged back into the main branch on the development machine using GitHub Desktop. Then it was pushed back to the GitHub cloud. The new branch was deleted from the computer and from the GitHub cloud service. Finally, the new code was packaged up, a change was added to the readme to describe the new feature and to update the code's version number, and it was pushed using SVN up to the WordPress plugin repository.

Jules is beta. It hung in a few places, some screens didn't update, and it stopped functioning for 90 minutes. Jules can handle an entire repository of code across a bunch of files. The speed with which it can change an entire codebase is terrifying. The damage it can do is potentially extraordinary. It will gleefully go through and modify everything in a codebase, and if something is specified wrong and then pushed or merged, there will be an epic mess. There is a deep inequality between how quickly it can change code and how long it will take a human to review those changes. Working on this scale will require unit tests. Experienced coders need to review and guide these agents. When one critical instruction was left out, the agent bricked the site. Junior developers' jobs are likely to be destroyed, as Jules is easily doing junior developer level work.

A new feature that had been requested was turned out in less than 10 minutes. The prompt was fed to Jules while another article was being written. The code was checked out, brought down to a computer, and a release was pushed. It took longer to upload the thing to the WordPress repository than to add the entire new feature. These tools will require programmers, managers, and investors to rethink the software development workflow. There will be failures and coding errors. Real, human intelligence will be necessary to figure out how to deal with it.