Hacker News Reader

Comment by skeledrew | Hacker News Reader

I liberated myself from the terminal/desktop and am now doing my stuff primarily via phone, so I can freely move around and handle stuff whatever I am. Feeling pretty fried right now because I started with 1 project, and over the session of that project 3 more got dragged in because dependency or tool issue, and they all have multiple features with multiple scenarios that I'm trying to review and unblock, ideally before auto-compact (I have a setup that kicks in after 40m of no activity) because then I have to instruct the agent to mine the previous session(s) for context and it still sometimes misses stuff and... I'm currently failing. I just let them compact now and take a break, and hope too much isn't missed when I get back at them. Definitely need to improve workflow here because it's a heck of a grind. Liberated, but not really.

View on HN

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.

Reply on news.ycombinator.com