Workflows for coding with Neo
Different engineers and different projects find different ways they like to work with Neo. Here are some ideas.
Assign a ticket to Neo and comment on Neo’s PR
Neo will often make an 80% good pull request when you assign a ticket to it.
Leave lots of comments for Neo - don’t worry about leaving too many, it will go through them one at a time making improvements.
This is often enough to get a ticket to the point where you can test and merge it.
Make subtasks and review Neo’s PR to each separately
Just like any engineer, it’s easier to review Neo’s work, and it is more likely Neo will do exactly what you want, if you first of all break the task down into subtasks.
On the parent ticket, say the name you’d like for the feature branch. Then make a subtask, and assign it to Neo. Sometimes you can give Neo several independent subtasks to do at the same time!
You can either check out that subtask’s PR while reviewing it, or just merge it and tidy it up on the main feature branch for the ticket.
It’s very fast and powerful to make your own commits about other aspects of the task to the main branch, while Neo is making and responding to your review of subtasks.
Make your own PR and get Neo to improve it
Depending on your codebase and how you like to work, it can work well to write a large number of comments on one PR to gradually implement features. This is very fast. If you made the PR, you will need to @ mention Neo.
To avoid merge conflicts, make sure you pull any changes Neo made before making your own commits. If this feels awkward, you may prefer to use subtasks (as described above).