undefined | Better HN

0 pointstheshrike794mo ago0 comments

It's like working with humans:

  1) define problem
  2) split problem into small independently verifiable tasks
  3) implement tasks one by one, verify with tools

With humans 1) is the spec, 2) is the Jira or whatever tasks

With an LLM usually 1) is just a markdown file, 2) is a markdown checklist, Github issues (which Claude can use with the `gh` cli) and every loop of 3 gets a fresh context, maybe the spec from step 1 and the relevant task information from 2

I haven't ran into context issues in a LONG time, and if I have it's usually been either intentional (it's a problem where compacting wont' hurt) or an error on my part.

0 comments

troupo4mo ago

> every loop of 3 gets a fresh context, maybe the spec from step 1 and the relevant task information from 2

> I haven't ran into context issues in a LONG time

Because you've become the reverse centaur :) "a person who is serving as a squishy meat appendage for an uncaring machine." [1]

You are very aware of the exact issues I'm talking about, and have trained yourself to do all the mechanical dance moves to avoid them.

I do the same dances, that's why I'm pointing out that they are still necessary despite the claims of how model X/Y/Z are "next tier".

[1] https://doctorow.medium.com/https-pluralistic-net-2025-12-05...

theshrike79OP4mo ago

Yes and no. I've worked quite a bit with juniors, offshore consultants and just in companies where processes are a bit shit.

The exact same method that worked for those happened to also work for LLMs, I didn't have to learn anything new or change much in my workflow.

"Fix bug in FoobarComponent" is enough of a bug ticket for the 100x developer in your team with experience with that specific product, but bad for AI, juniors and offshored teams.

Thus, giving enough context in each ticket to tell whoever is working on it where to look and a few ideas what might be the root cause and how to fix it is kinda second nature to me.

Also my own brain is mostly neurospicy mush, so _I_ need to write the context to the tickets even if I'm the one on it a few weeks from now. Because now-me remembers things, two-weeks-from-now me most likely doesn't.

troupo4mo ago

The problem with LLMs (similar to people :) ) is that you never really know what works. I've had Claude one-shot "implement <some complex requirement>" with little additional input, and then completely botch even the smallest bug fix with explicit instructions and context. And vice versa :)

j / k navigate · click thread line to collapse

0 comments

troupo4mo ago

> every loop of 3 gets a fresh context, maybe the spec from step 1 and the relevant task information from 2

> I haven't ran into context issues in a LONG time

Because you've become the reverse centaur :) "a person who is serving as a squishy meat appendage for an uncaring machine." [1]

You are very aware of the exact issues I'm talking about, and have trained yourself to do all the mechanical dance moves to avoid them.

I do the same dances, that's why I'm pointing out that they are still necessary despite the claims of how model X/Y/Z are "next tier".

[1] https://doctorow.medium.com/https-pluralistic-net-2025-12-05...

theshrike79OP4mo ago

Yes and no. I've worked quite a bit with juniors, offshore consultants and just in companies where processes are a bit shit.

The exact same method that worked for those happened to also work for LLMs, I didn't have to learn anything new or change much in my workflow.

"Fix bug in FoobarComponent" is enough of a bug ticket for the 100x developer in your team with experience with that specific product, but bad for AI, juniors and offshored teams.

Thus, giving enough context in each ticket to tell whoever is working on it where to look and a few ideas what might be the root cause and how to fix it is kinda second nature to me.

troupo4mo ago

j / k navigate · click thread line to collapse