Yeah I use my phone heavily too now. I have my setup running on a PC, and ignoring code review the vast majority of my time is refining issues.
Process is:
1. I describe the issue (voice mode) then I wait / do something else.
2. Model looks at my repo, my gitlab issues board, stuff currently worked on etc
3. Model creates a gitlab issue and presents it.
4. Model starts a grilling session. That is: it will keep asking me questions until everything for the task is addressed: design decisions, unclear elements, default behaviors, edge cases, conflicts with current behavior. Usually around 5-30 questions.
5. Loop of me answering and it asking a new batch of questions
6. Model updates the issue with all the decisions that were made.
7. Model with start implementing once I give the go. Once done it runs tests/validation and sends me a MR to review. (That takes anywhere from 5 mins to 2h depending on the task complexity, but on larger projects just the final test/validation/no regression step can be 10 mins)
8. I review / merge
The grilling is nice because for the most part if solves a lot of future issues by not allowing the model to make decisions you didn’t agree with, and it front-loads all questions so it can work uninterrupted. Very rarely does it need to ask a question during implementation.
But yeah most of my time is helping the agent define all the boundaries of the problem, decide how to break goals into issues (such as high level PM issues into technical issues) and so on.
Also one chat per issue which limits chat compaction.
A few common elements but interestingly also pretty different from my usual flow. Unless I'm fixing issues, I start out by dumping as much as I can think of about what I want built in a brainstorm, then start with that as context for a grill. Depending on how detailed I am and the scope covered, I've been hit by anywhere from say 20 to 80 questions, and when something gets settled it has Gherkin scenarios. Then a spec is created from all that, followed by feature slices with the scenarios as acceptance criteria. Get all those implemented, run standards and spec code reviews over them and it's then up to me to test. I don't review the code, but I have a pretty solid rubric, and I'm always iterating on tools alongside to enforce more and more parts of the flow.
I tend to keep a long-running chat per project for a lead agent, with which all the grilling and ticketing happens, and it then delegates slices to other agents for implementation+review and ensures everything is merged properly after. Maintains context across multiple compacts, and when I do want a fresh session (usually because compact summary had also gotten oversized), I still do a handoff doc so I'm almost never starting from zero in a session, per se.