Jules AI - The (Currently) Free Coding Assistant That Can't Follow Directions But Gets Shit Done

Jules is currently free, so I figured it was worth a try. Of course, I had to find out what I could break.

Each user gets these default limits:

• 5 concurrent tasks
• 60 total tasks per day
• 5 codecasts per day (still not sure what this means)

Sixty tasks a day for free? That’s really generous and it meant I didn’t have to worry about reading documentation or instructions the first time.

I Jumped in Feet First

My Obsidian plugin worked well enough for me to use it, but there were issues. Issues that I’d been ignoring because the damn thing worked and I had other shit to do. But I finally added issues to my GitHub repo.

Four issues. Nothing too crazy. Should be straightforward for an AI that can supposedly code.

I gave Jules access to the repo and told it: “I want you to work on the issues in this repository and create a feature branch for each fix. Start with the first one.”

Simple enough, right?

Jules Decides to Ignore My Instructions

Jules fetched the repo, cloned it into a VM, and read the README file. But then it discovered the “Future Enhancements” section I’d added to the README and decided that’s what it wanted to work on instead.

It completely ignored my instruction to work on the issues, the same issues that are listed right above the “Future Enhancements” section, and decided it would work on the “Interactive book selection dialog” instead.

Jules then asked me to approve the plan, but I didn’t see any way to reject it. It was going to auto-approve in about a minute anyway. I thought maybe clicking “Approve” would launch a modal where I could say “no, you illiterate AI, work on the issues I told you to work on.”

It did not.

So it started working on the wrong thing. I messaged “stop” and it replied: “I have stopped the current task. Is there something specific you would like me to do instead, or a different issue you’d like me to focus on from the README?”

It paused for a few seconds and then continued doing exactly what it was doing before.

Currently, as far as I can tell, the only way to reject a plan is to let it start, pause it manually, and then delete the entire task. User experience design at its finest.

Jules finished the feature and gave me the option to click a button to create a feature branch. So now I had a new feature to test before I could fix the actual issues I wanted fixed.

Testing the Feature that Jules Built While Ignoring My Prompt

So I pulled the branch down to the Obsidian vault I use for testing, the one with all the plugins I’m developing loaded up. There was one error in the code, in unit tests I never asked Jules to add:

tests/main.test.ts:160:35 - error TS2554: Expected 0 arguments, but got 1.
sortAnnotationsByCFI: jest.fn((ann: Annotation[]) => ann), // Simple pass-through

I just deleted the broken test.

It took me a while to figure out that the selection modal didn’t launch via the sidebar button like I expected. I had to hit Command+P and find the command to launch it. But you know what? It actually worked.

Since the feature worked, I merged the change and created a new release. Then I did some reading to figure out how to prevent Jules from going off on another tangent.

Back to Fixing Bugs (This Time With Feeling)

I thought maybe I should be more descriptive, but there wasn’t much to be descriptive about. There are issues. I added them to the repo. They’re also in the README that I know Jules can access. Most of the example prompts are very short, shorter than what I’d already tried.

So I tried again: “This github repo has 4 issues listed here: https://github.com/eristoddle/apple-books-annotation-import/issues. Give me a plan for fixing the first issue. If you have no access to these, let me know. Do not do anything else.”

This time it worked.

Both the accidental feature and the bug fix took very little time. I was actually surprised by the speed. But Jules created broken unit tests again. I figured maybe it was because I didn’t have my npm and node versions in the package.json, so I added those and deleted them again.

It actually fixed the bug and at least doubled the number of book covers I was getting.

The Great Color Mapping Mystery

The second issue was about finding annotation colors.

Me: “Fix this feature in the repo: https://github.com/eristoddle/apple-books-annotation-import/issues/5. Do not do anything else.”

I think “Do not do anything else” will be part of my prompt from now on.

Jules said: “The code changes have been reviewed for syntactical correctness and logical soundness. Direct testing with an Apple Books database is not possible, so final validation will be up to the user.”

Translation: “I changed some code and it compiles. Good luck!”

After testing, I told Jules: “Now it seems like there are no annotation color indicators at all in the md files. Before they were all just purple. Now they are just not there at all.”

The second attempt produced different colors, but they didn’t match the highlight colors in the Books app.

I mapped the colors Jules gave me to the actual colors and told it about the differences: “The color images are back and there are a variety of them, but they do not match the colors in the Books app. Here is how they differ (Books app color → markdown color): underline → both yellow and underline, purple → no icon at all, pink → red, yellow → purple, blue → blue, green → green.”

I even included the log showing the distinct annotation style values from my test database. So this bug took three interactions, but Jules finally got the color mapping right.

Taking It to the Big Leagues

My main Apple Books account has 4000 books and over 60 books with highlights. When I first worked on this plugin, the database structure was different, so I wanted to make sure everything worked in the wild before calling it done.

The plugin handled the larger database just fine. All the covers loaded correctly, and the color annotations matched what I saw in the Books app.

Everything I Fixed In This Change

It took about two hours total, not counting the issue Jules couldn’t fix. I let it code while I took notes for this article, worked on Obsidian cleanup, and checked out Reddit for a while.

Here’s what got implemented:

✅ New interactive ebook selection dialog: By accident when I was asking Jules to fix issues, but I’m counting it as a win.

✅ Fixed finding ebook covers: This was the original first issue. Jules doubled the number of covers the plugin could find.

✅ Fixed annotation color icons: Took three tries and some detailed feedback, but now the colors match what’s in the Books app.

✅ Fixed missing annotation dates: This needed a second attempt. I had to tell Jules: “I have include dates set to true and include citations set to false. There are no dates in the markdown files though.” But it got it right the second time.

❌ Did not fix gibberish in epub chapter names: This one turned into a nightmare. The TypeScript build error migrated from the tests that never worked. I tried to get Jules to fix it once and it failed. The second time it was thinking forever, so I tried Copilot in VS Code, and that fixed the build.

But then there was a runtime error I’d run into before when Claude Code tried to use a Node.js ebook parsing package. Something about not being able to access the file system in Electron. I went round and round with Jules on this one and finally gave up.

One thing I realized is that I could tell Jules to build the app to test the build and fix issues, but I had to make it a command. When I asked “Did you build the app to test it?” it said that wasn’t possible. But when I just told it to build the project, it did it.

So I let it churn through fixing the build errors for 30 minutes. When I tested the result, the chapters still weren’t fixed. But I didn’t expect this one to be easy without doing some research first.

I used 5 of my available 60 free tasks for the day.

Jules: Fast, Confused, but Generally Useful

Jules is fast. That surprised me. At least until there’s back and forth on changes, then the conversation slows down.

It was done with the next fix before I finished testing the previous one. I added one feature I didn’t plan on and fixed four issues in a little over an hour.

But Jules went off on a weird tangent when I gave it what I thought were specific instructions. There seems to be no real interaction other than the first message and accepting the plan. I was worried about fixing issues in a branch it created if something didn’t work.

Using a task like it was a chat and trying to fix more than one issue per task got confusing. Then I figured out I needed a different workflow:

• 1 chat per branch, but can do multiple related things
• 1 chat can be as big as 1 feature
• Code review each branch
• If there are issues, go back to the chat and have Jules fix them
• If there are build errors, tell Jules specifically to build the app again, test, and fix any errors.
• Pull and test again

I was used to my Claude Code process where everything happened in the branch I was on locally. The “Publish Branch” button in Jules seemed scary at first, but the second time I used it, it just pushed modifications to the existing branch. I was expecting merge conflicts or some other drama.

Most things I asked Jules to do worked well, except for the chapter names issue. I also didn’t ask it to create unit tests, but it kept creating broken ones anyway. It each branch it created, I ran them once and if they failed, I deleted them. They mainly failed because of TypeScript type issues.

The Future of Lazy Coding

Sixty tasks a day for free is generous. I’m planning to move everything I have to GitHub that isn’t already there and create issues for any feature ideas or bugs I encounter.

I could envision a process where:

• A user puts in a support request
• An issue gets created on the repo
• I tell Jules to fix it
• Jules fixes it, creates a custom build, and the user tests it (don’t know about this, but I can dream)
• If the fix works, I merge it and create a new release

I’m not sure exactly how this process would work in practice, but the potential is there.

Verdict: Worth the Price of Free

Jules isn’t perfect. It ignored my initial instructions, created broken unit tests, and couldn’t fix the most complex issue I threw at it. But it’s fast, it’s free for now, and it actually solved most of the problems I needed solved.

In two hours, I got a new feature and fixed three out of four issues that had been sitting in my backlog. The fourth issue would have taken me some research into ePub structure even doing it manually.

I’m definitely planning to shift more of my “vibe coding” projects to Jules. At 60 free tasks per day, I can afford to let it work on the boring stuff while I focus on the interesting problems. In fact, to use 60 tasks a day, I might have to try running concurrent tasks and I can do 5 of those.

And if it goes off on another tangent and builds something I didn’t ask for? Well, sometimes the best features are the ones you never knew you needed.