Limitations
Why Tusk may fail to create a PR
Overview
AI agent outputs are non-deterministic, so Tusk may sometimes fail to create a PR or create a PR with incorrect changes. For the sake of transparency, we wanted to share some of the main things that tend to trip Tusk up.
We’re constantly working on making Tusk better at generating the highest-quality code for your codebase, so you’ll see the list below shrink as we make improvements.
Reasons for PR Failure
Issue is too complex
Tusk is optimized to handle smaller issues (i.e., 1 story point) end to end. It works best when you assign it an issue that is a single user story.
Tusk is unlikely to create a PR for an issue that:
- Requires changes in more than 5 files, unless the changes are straightforward
- Requires concurrent changes across more than 1 repo
- Would take a human engineer more than 1 hour
- Would trouble a junior software engineer
In these cases, Tusk will create a branch with its work-in-progress changes and provide you with advice on the ticket as a jumping-off point.
No issue description
Some teams haven’t formed a habit of creating detailed Linear, Jira, Notion, or GitHub issues. They may find themselves creating issues with just a title and no description.
However, assigning an issue with no description to Tusk may cause Tusk to spiral as it tries to make assumptions about your requirements. Your description doesn’t need to be overly detailed. We recommend stating the user acceptance criteria in the issue description.
Over-reliance on image
Some teams will simply link the Figma mock-up or add a prototype image to the issue description and nothing else.
Tusk’s vision capabilities aren’t to the point yet where it can implement a full page in a pixel-perfect manner from the prototype image alone. We strongly recommend including an issue description even if you’re adding an image — better still if part of your description contextualizes the image.
No common components
Tusk may not generate the most elegant code if your repo does not have common components that it can reuse or reference for new tasks. When you add an image or Figma frame to your issue description, Tusk will do its best to match the relevant UI components in the design to the components in your repo.
If there are no common components in your repo to match against, Tusk will create custom components to meet the design specs, which may or may not go against your frontend development best practices.
Deprecated code in repo
If your repo contains deprecated code, Tusk may inadvertently reference legacy code patterns when it is reasoning through a task. We recommend cleaning up your repo of deprecated code to get the best results from Tusk. To mitigate this problem, you can also set custom repo instructions or contact the Tusk team to block legacy directories from being synced to Tusk.
Adding image files
Tusk isn’t yet able to create new image files in your repo based on images added to your issue description. One workaround we recommend is providing the image URL in the issue description for Tusk to utilize.
Updating libraries
This rarely comes up but we don’t recommend using Tusk to update libraries. Tusk doesn’t run the install script to generate the lock files, which could lead to dependency conflicts.