How to Get Better Pull Requests from Google Jules

The quality of a Google Jules pull request depends mostly on how you prepare the repo and write the task, not on the model. Two teams using the same agent get very different merge rates. Here is what separates them.

Why do some Jules PRs get rejected?

Three reasons show up again and again: vague issue text, missing tests to verify against, and repo files the agent cannot read (generated code, vendored libraries). Jules does what the repo makes easy.

How do you prepare a repo for Jules?

1. Add a JULES.md or clear README section listing build and test commands.
2. Make sure pytest or npm test runs clean on a fresh clone.
3. Keep test runtime under two minutes — slow suites stall the agent loop.
4. Exclude generated and vendor directories so the agent focuses on source.
5. Tag good starter issues with a label so you can queue them in batches.

That third point matters more than it sounds. If your suite takes ten minutes, the agent spends most of its budget waiting.

How should you frame a task?

Write tasks with an input, an expected output, and a constraint. Compare these two:

Weak task	Strong task
“Fix the login bug”	“Login fails when email has trailing space. Trim input and add a test in tests/test_auth.py.”
“Improve performance”	“The /search endpoint does N+1 queries. Batch them and keep the response shape identical.”

The strong version tells the agent where to put the test and what must not change. That is what keeps the diff small.

What is a realistic review workflow?

Treat a Google Jules PR exactly like an external contributor’s. Run it locally before approving. Check that the test actually fails on the old code — agents sometimes write tests that pass no matter what.

I keep a rule: no agent PR merges without a human typing the manual reproduction once. It catches the cases where the test suite is green but the bug is still there.

Jules vs other agents: when to pick it?

Pick Jules for backlog cleanup on repos you already trust. Skip it for greenfield architecture decisions or anything touching billing logic, where a wrong-but-passing change is expensive. It is a volume tool, not a design tool.

Quick Summary

• Repo prep (fast tests, build docs) drives Jules merge rates more than prompt wording.
• Write tasks with input, expected output, and a constraint.
• Keep test suites under ~2 minutes for best throughput.
• Verify that new tests actually fail on the old code.
• Use it for backlog work, not architecture or billing logic.