An asynchronous coding agent can safely own work when the issue defines the outcome, boundaries, and checks for success. Issue age can signal neglect, but it does not tell Jules whether a change is low-risk, reversible, or ready to review.
The five issues looked identical from a distance: each had been open for weeks, each had a short title, and each had accumulated a few comments. By Monday afternoon, their real differences were hard to miss.
One said, “Fix flaky checkout test.” It named the test, linked the failure, described the expected behavior, and excluded production checkout code. Another said, “Clean up auth.” No reproduction steps. No desired behavior. No decision on whether “clean up” meant deleting code, changing session handling, or rewriting an integration that still had customers behind it.
Jules can work asynchronously across GitHub issues, cloning repositories, setting up Cloud VMs, and creating pull requests. That makes it useful for a backlog. It also makes vague work more dangerous, because a vague ticket gives the agent room to choose the problem on the team’s behalf.
Issue age measures attention, not safety
A 90-day-old issue may be the safest item in the repository if it describes a contained bug with a clear test. A three-day-old ticket can be unsuitable if it touches billing, permissions, customer data, or an architectural decision the team has not made.
Founders often sort a backlog by oldest first because it feels fair. The oldest tickets have waited longest, and clearing them creates visible progress. That sorting rule becomes less useful once an asynchronous coding agent enters the workflow.
The agent needs a task it can finish without inventing product policy. “Add the missing validation message when a user enters an expired coupon” is a bounded request. The affected flow is named. The expected result is visible. A reviewer can inspect the pull request against a clear standard.
“Make promotions more reliable” creates a different assignment. It could involve validation, database state, third-party payment behavior, analytics, or the pricing rules themselves. The issue may be important. It is not ready to hand off.
Age is still useful as a prioritization signal. It can reveal forgotten customer pain, recurring debt, or an ownership gap. It should not become a proxy for implementation clarity.
The five issues separate into different kinds of work
A useful Monday review sorts issues by the decision they require, not by the date they were opened.
The first issue, a failing test with a linked stack trace, is a strong candidate. Jules can reproduce the failure, make a focused change, and open a pull request with the test result.
The second, a request to update a dependency, may also be suitable if the desired version, affected package, and compatibility checks are specified. “Upgrade to the current version” is weaker, particularly if the upgrade changes an API or a deployment requirement.
The third, “clean up auth,” belongs with an engineer or product owner until someone defines the outcome. Authentication code tends to encode decisions about sessions, recovery, permissions, and user access. A pull request is a poor place to discover that those decisions were never written down.
The fourth, a documentation gap, can be safe when the source of truth is clear. Ask Jules to update a setup guide to match a specified command or configuration path. Avoid asking it to “make the docs accurate” when the repository and production behavior disagree.
The fifth, a customer-reported bug, needs one more pass before assignment. A report that says “export downloaded the wrong columns for accounts with no owner” offers a reproducible condition. “Exports are weird” does not. The difference is often a ten-minute triage step, yet it determines whether the agent can make a useful first move.
Write the constraints a reviewer will need
The best agent-ready issues read like a compact review brief. They explain the desired outcome, the relevant location in the codebase, the boundaries, and how the team will judge the change.
That does not require a long specification. It requires the decisions that would otherwise be made while coding.
A strong issue might say: “When an account has no owner, include an empty `owner_name` column in CSV exports. Update the export service and its unit tests. Do not change column order for accounts with owners. Verify with the existing export test suite.”
That task gives Jules an observable target and a limit on scope. It also tells the human reviewer what to check before merging.
For higher-risk work, add explicit stop conditions. Tell the agent to open a draft pull request if it finds a schema migration, a change to authorization behavior, a dependency conflict, or a requirement that cannot be verified in tests. These conditions turn uncertainty into a handoff instead of a guess.
The same boundary-setting question appears in Software Engineers Shift to Defining AI Agent Boundaries: teams need to decide which choices remain human decisions before they delegate the code around them.
Treat the pull request as evidence, not completion
Jules can reduce the time between a well-defined issue and a reviewable pull request. It cannot make an unclear request clear after the fact.
That distinction matters when teams measure agent output. Five pull requests created from five old issues can look like a productive Monday. The relevant question is how many contain a change that matches an agreed outcome, passes the right checks, and stays within the intended boundary.
Start with one issue that has a narrow behavior change and a known verification path. Read the resulting pull request closely. If the agent had to infer a product decision, revise the issue template before assigning the next batch.
By the end of the week, the useful artifact may be less code than a better backlog: tickets with explicit outcomes, named boundaries, and a clear point where a human needs to step back in.
Comments
No comments yet.