IT/Software career thread: Invert binary trees for dollars.

Deathwing

Deathwing

<Bronze Donator>
17,852
8,790
ShakyJake said:
What is your exact workflow? Are you doing this all within a chat session?
Click to expand...
  • Pull ticket and stick it in plan mode.
  • Read plan, make corrections, ask questions.
  • Stick it in manual mode, laboriously approve all operations so it doesn't blow past code changes. Read, understand, and correct if necessary said changes.
  • If the change was substantial, spawn separate agent who coordinates a review swarm.
  • Read dozens of findings, fix some, question why others even happened in the first place. Repeat if you had to change a bunch of code, but usually jettison this loop after two iterations.
  • Create MR, review overall diff because Claude Code sucks at giving necessary context for many changes. Go back to implementation if not happy.
  • Put it up for review. Depending on who you choose: argue code comments or do another round of the previous loop(they have the same skill and just AI vomited on your MR).
  • Defang the completely separate AI review your MR receives when leaving draft mode lest the lazy human reviewer agrees with it.
I try to do most of that from Claude Code. Most of my tickets take about two thirds of Opus context by the end, not counting the review. I really dislike interacting with MRs via Claude. It's verbose to a disgusting degree and if I don't watch it like a hawk, I end up inflicting these really bloated MRs on people that don't deserve it.
 
Noodleface

Noodleface

A Mod Real Quick
40,239
20,196
"Stick it in manual mode, laboriously approve all operations so it doesn't blow past code changes. Read, understand, and correct if necessary said changes"

This might be where we differ here. The direction we've received is tell AI to do X, let it do X and then test/review. They don't really want us caring about code changes at the basic level, but more the functional level. Obviously though, my company has different processes.
 
ShakyJake

ShakyJake

<Donor>
8,840
21,627
Deathwing said:
  • Pull ticket and stick it in plan mode.
  • Read plan, make corrections, ask questions.
  • Stick it in manual mode, laboriously approve all operations so it doesn't blow past code changes. Read, understand, and correct if necessary said changes.
  • If the change was substantial, spawn separate agent who coordinates a review swarm.
  • Read dozens of findings, fix some, question why others even happened in the first place. Repeat if you had to change a bunch of code, but usually jettison this loop after two iterations.
  • Create MR, review overall diff because Claude Code sucks at giving necessary context for many changes. Go back to implementation if not happy.
  • Put it up for review. Depending on who you choose: argue code comments or do another round of the previous loop(they have the same skill and just AI vomited on your MR).
  • Defang the completely separate AI review your MR receives when leaving draft mode lest the lazy human reviewer agrees with it.
I try to do most of that from Claude Code. Most of my tickets take about two thirds of Opus context by the end, not counting the review. I really dislike interacting with MRs via Claude. It's verbose to a disgusting degree and if I don't watch it like a hawk, I end up inflicting these really bloated MRs on people that don't deserve it.
Click to expand...
This is similar to how I work, except that I do not work inside the chat session entirely itself.

I work in several phases, and each phase produces a durable Markdown document:

- Pull the ticket or user story from ADO. This writes a `story.md`, which I then review.
- Initiate an investigation with the agent set to high reasoning. This generates `investigation.md`. I review it, resolve questions and assumptions, and agent updates `investigation.md` to reflect those decisions.
- Agent creates a `plan.md`. I read the plan and make sure the agent is not drifting off course.
- Once everything looks sound, I start implementation in steps. The agent is set to a workhorse model such as Luna 6.0 MAX. I review each step, evaluate the code, approve it, and move on until the work is done.

I do not try to one-shot implementation. The work is done in incremental steps.

I also created skills for each of these phases, and the agent follows them. I have refined the skills over time. For investigation, for example, I require the agent to write out assumptions, ambiguities, and similar issues so I can see them and make adjustments.

This has worked well for me. As I have mentioned before, I handed this workflow to a new junior dev, and she has been crushing it.
 
Nija

Nija

<Silver Donator>
2,259
4,627
ShakyJake said:
I do not try to one-shot implementation. The work is done in incremental steps.
Click to expand...
I think this is the key.

Deathwing Deathwing I try to break the work into logical components and make sure the agent understands the phases/checkpoints I want along the way. So like the phase 1 batch of the work is performed, I inspect/iterate there and when it's done - commit. Phase 2, same thing... commit... Phase N, commit and push to create start the PR process.

I'm in alignment with ShakyJake ShakyJake in that I do an overview / planning pass (I still don't use "plan mode" as I've settled into this overview (planning I guess stage) ), and implementation "plan" phase, and finally the implementation phase, where I take it in one logical unit of work at a time. Even if that means stubbing some stuff out in the early phases before adding any meat to those methods/function calls in a later phase.

Iterate a few times in your phase 1 to make sure the document for your feature / complete unit of work is as close to perfect as you can make it. Assumptions and vague requirements here lead to a subpar implementation plan, which leads to a poor implementation. Putting a lot of thought/effort into the first few phases, in my experience at least, ends up with an implementation that is Pretty Dang Good - first shot. (first shot after a lot of iterations making sure the requirements I'm handing to the agents are crystal clear.)
 
Last edited:
  • 2Like
Reactions: 1 users
ShakyJake

ShakyJake

<Donor>
8,840
21,627
Nija said:
I think this is the key.

Deathwing Deathwing I try to break the work into logical components and make sure the agent understands the phases/checkpoints I want along the way. So like the phase 1 batch of the work is performed, I inspect/iterate there and when it's done - commit. Phase 2, same thing... commit... Phase N, commit and push to create start the PR process.

I'm in alignment with ShakyJake ShakyJake in that I do an overview / planning pass (I still don't use "plan mode" as I've settled into this overview (planning I guess stage) ), and implementation "plan" phase, and finally the implementation phase, where I take it in one logical unit of work at a time. Even if that means stubbing some stuff out in the early phases before adding any meat to those methods/function calls in a later phase.

Iterate a few times in your phase 1 to make sure the document for your feature / complete unit of work is as close to perfect as you can make it. Assumptions and vague requirements here lead to a subpar implementation plan, which leads to a poor implementation. Putting a lot of thought/effort into the first few phases, in my experience at least, ends up with an implementation that is Pretty Dang Good - first shot. (first shot after a lot of iterations making sure the requirements I'm handing to the agents are crystal clear.)
Click to expand...
Same here. I don't use "Plan" mode or really any mode other than Full Access / YOLO.

The plan is the Markdown document generated from the investigation. The point is to have a "hard copy" that the agent can follow rather than relying on its memory of the earlier conversation.

Keep in mind that context gets compacted along the way, so information can eventually be lost.
 
Deathwing

Deathwing

<Bronze Donator>
17,852
8,790
Is there that could help guide someone on this the first few times? This sounds similar to stuff Matt Pocock cooks up, but he iterates far too much to follow closely.
 
ShakyJake

ShakyJake

<Donor>
8,840
21,627
Deathwing said:
Is there that could help guide someone on this the first few times? This sounds similar to stuff Matt Pocock cooks up, but he iterates far too much to follow closely.
Click to expand...
That's kinda the thing, dude -- this is all changing so rapidly that we're all still trying to figure out how to use it efficiently. The only real recommendation I can make is to immerse yourself in it and practice using it. What we're doing today could look radically different a year from now.
 
Nija

Nija

<Silver Donator>
2,259
4,627
Deathwing said:
Is there that could help guide someone on this the first few times? This sounds similar to stuff Matt Pocock cooks up, but he iterates far too much to follow closely.
Click to expand...
Here is what I found that kind of put the pattern I was (mostly) using to a term. This is dated, as mentioned everything is moving so fast. It's only a 15 minute video, there is a blog post somewhere that outlines things in more detail that I can't find now. But this weird lefty dude, Dexter, had (has?) some pretty good content around context engineering. Back in the OLD DAYS (less than a year ago) where the context being mostly full was a huge problem.

 
  • 1Like
Reactions: 1 user
You must log in or register to reply here.