Hacker News Reader

I've recently gotten religion on the workflow that is many (relatively) short-lived agent sessions passing planning/handoff docs between themselves. It's better for my own task tracking, better for handling "oh btw I noticed XXXX", and better as a clear review point. Overall it just feels like it takes a lot of the formerly implicit context that was whatever we happened to have talked about and turns it into a much more explicit "this is what you need to know, now go".

Currently looking for a framework for managing this in a more formal way, and I think it's probably beads, but interested to hear from others.

I've been on this kick since I realized the primacy of the initial part of the session context. I created a python app that reads a phased plan and kicks off a new session for each phase. There is a standard prompt and handoff mechanism to determine if we encountered any unforeseen issues that we need to address in chat, but otherwise it will just grind with a clean session with appropriate context for each phase.

Just kicking off a subagent does this automatically...?

My main conversation is usually with an orchestrator that hands off work to various (usually cheaper) subagents to plan / review / etc. It has instructions to find the correct model for each task and not to do too much itself so a multi-phase plan automatically gets a fresh subagent for each phase.

i disable subagents. it also helps that i work in microservice size repos, so a single agent can keep the full relevant context. subagents waste alot of unnecessary tokens doing code exploration that the main agent is going to end up duplicating, i think they make more sense for monorepos.

anecdotally I've tried the same plan on different branches with both approaches (single agent with subagents implement the full plan vs. my little session per phase app) and then had agents judge the code quality and my approach worked better and saves tokens. horses for courses.

Look into beads/dolt then - it does this pretty much with a cli - Jira for agents :)

Spent the past 1,5 years building a tool that might be relevant, helping keep durable task state between agent sessions. It is an issue tracker persisting state as immutable event logs, allows you to inspect workflows after the fact, lets you inspect diffs inline in the tickets and it is much more lightweight than Jira/Linear. There is no central service to integrate with, as it is Git-backed and lives with your code in your repo.

https://ljtn.github.io/epiq/

Might be worth a look if you’re evaluating alternatives to Beads.

Wow. It's like beads++

Great work man.

Oh shit, this looks incredible. Thanks!

Not OP but will definitely have a look.

I have some older projects that use beads (I still run an old version without dolt that's imho pretty good overall) but lately with Fable also have a few newer projects where I just have the agent write docs and keep a worklog with the what/why/decisions etc. (I think I read it here on HN somewhere and figured I'd give that a try.)

The latter seems to work pretty well for now (slightly better than beads) but I'm always looking for ways to improve it. This could be an interesting replacement.

I think it works well for tracking intent. I tell my agents to use a "human-input-needed" tag when there is a high stakes decision fork, and then I just filter on that tag, immediately highlighting blocked workflows. I think you can get a long way with clever tagging, filtering + time travel.

This looks really nice and I'm definitely going to give it a go. I been relying on Jira so this will be a breath of fresh air. Beads was great in principle and I haven't given it a look in a while but this looks much cleaner.

Curious to hear how you find it after trying it!

> 13:37 - 13:49

“ayy lmao”

Checking this out, the skill it wants me to add to my project seems to reference issues that wouldn't make sense in the context of my project. IE: `QPPR7PE` and `MBB6WY5` ?

You are totally right in that it makes no sense. It seems like the skill.md had regressed as I had updated it via agent proxy. Thanks for pointing it out, the skill has been brushed up.

I’ve been trying it out on a personal project. It’s been going well. The only difficulty I’ve had is getting it to work with cloud sessions on Claude.

Got it! I am not up to speed on Claude cloud sessions yet. Interested to hear how that works out for you. Let me know if you figure out what's getting in the way, I'd be happy to look into it.

httpd://recursive-mode.dev

https://recursive-mode.dev

I used taskwarrior for myself and agents, but felt it was insufficient for agentic era in many ways, so I started building my own a while back:

https://aventasks.dev/

I have a lot of little projects and I also prefer this way of working with agents. Sometimes I would start to interrogate on a specific portion or ask questions to better understand a concept, and the session would get poisoned and the agent would fixate on that topic for all the remaining turns.

I asked fable to look at my interaction patterns and clearly stated my frustrations and the problems I wanted solved, and it designed a simple process to track things in git and built a couple simple session hook skills. It’s pretty lightweight and I’ve been very happy with it for a couple months.

The power of this mode of work is that after you deconstruct the task into smaller subtasks, it's a lot easier to use cheaper models to implement that task.

I get a long way using models like Opus to make a plan of action and a bunch of tasks, and then using Deepseek to implement that plan of action. Saves a bunch of money and is fast.

Yep! The other big advantages for me:

- I have a record of work done and work to be done that helps _me_ when I come back to the project after several months. It’s committed and lives with the code.

- when a task inevitably ends up more complicated than I thought, I can in that session break it up

- I initiate sessions from multiple computers, so things stay in sync (through git)

- I also have a “tooling” repo that builds out some views of the work and hosts it for me to see when I’m on my phone.

- The hooks let the agent manage all of the workflow/task management, so there’s very little management overhead for me.

I rejected beads and JIRA. I wanted something more lightweight.

What do the session hooks do?

- start: invokes `work brief` skill to put the current tasks into context

- pre-compact: does the same so work state survives compaction

- stop: lints the work-tracking yaml files to make sure that updates mid session don't break

Nice. I found myself doing a lot of repetitive stuff handing off between agents, time to fix that. I think I agree with your approach of keeping it lean.

I also sometimes rewind the conversation after going off on a tangent, sometimes not if I want the agent to have the sorts of things I’m thinking about in context. I probably justify keeping too much crud in context than I should

That sounds very similar to just manually compacting after every message. Is there a difference I'm not seeing?

I use Jobs [0] to manage this—it's an agent-first CLI to track issues and tasks. A single `job orient` command gives the agent the current task in the context of the larger plan. It's a replacement for Plan Mode and issue trackers, and it has allowed me to execute massive plans in parallel with minimal oversight. There's a web UI, but it's a work in progress.

[0]: https://github.com/bensyverson/jobs

> (most of the time it’s actually the comments that are the problem, not the code).

I wonder if it's just a consequence of a gigantic training set full of comments completely out-of-date with the code, leading to the model considering this "normal"

I don't usually see Claude leaving comments that are obviously out of date compared to the code. The problem is that the comments are just a dumping grounds for Claude's stream of consciousness, verbosely recording random bits of history and context that are true and at least somewhat relevant, but without cohesively explaining why the code is the way it is. And some sentences in the comments will be beginner-style restating what's obvious from reading the code.

Exactly. Comments are basically its scratchpad for whatever it wants. Ask it to change a number in a TOML config and it'll also add 2 new comment lines above it with some Claudeslop about it being changed and what that accomplishes, as a useless note to itself.

I now make sure to do a big decommenting pass before every PR.

This kind of stuff annoys me too, and I have instructions in agent.md to avoid it, which helps.

But I also am starting to just let go and stop caring. It’s not clear to me that it causes problems down the road, it’s easy to strip out en-masse if needed, and in my experience, agents now are really good at read git blame, the commit log, even prior agent transcripts if available to sleuth out when a change was made and why. So yeah, it’s annoying, but the code agents write for me is increasingly never read by a human, so does it matter?

This. Be honest: who reads the human-written comments? ;)

When I read, I skip most comments, especially the larger "Javadoc" style. My brain sees them colored differently in the editor and it doesn't even take mental effort. Then, when I have a question about the code, I look back up for a relevant comment. That doesn't happen very often.

If Claude writes great code and leaves a garbled Claudese-but-accurate comment ... I can read and comprehend (with like 5x the effort of a human comment) ... that's a small price to pay.

Yes, comments might be my biggest gripe with CC due to what you said. 9 out of 10 of my revisions to Claude's work is deleting or rewriting comments. Such a silly thing for it to fail on.

(I do have detailed instructions for it on how to comment (or not) but it has not fixed this.)

You can only fit so many bits of watermarks in code... but comments on the other hand, the possibilities are endless!

Nah, it’s the typical Claude-isms, and way too much info, info in the wrong places, and putting lots of planning discussions into comments that are completely irrelevant.

It’s always “you explain only what but not why” or “this is way too much prose” or “these comments don’t belong here, they should be inline comments” or “this is completely redundant as it’s already obvious from the code”.

I do find that once I beat it into submission and the codebase is “clean”, the new code it generates gets better and better, which makes sense gives its pattern-prediction nature. But it seems like there is work to do for Anthropic in terms of getting Claude to not confuse code comments with dumping its interactive discussion state into there.

There is a popular skill for this kind of workflows: https://github.com/obra/superpowers

Yeah I always balked at the amount bloat in that repo, and I just prefer a more lightweight setup and plannotator’s UI which I can use to interactively review stuff. It solves this one problem better, where superpowers tries to do way too much, poorly.

https://plannotator.ai/

I dived into one or two of the skills there and some of it feels very cargo-culty. In a similar vein to the article, the models have improved markedly now and I’m not convinced that “You are an experienced senior software engineer and an expert reviewer, here are five pages of instructions on how to do a review” style prompts are massively useful any more.

I get great review results (as good or better than colleagues using superpowers or even adversarial review skills) just by asking Claude to review a PR and spit out results in order of severity.

Superpowers never really held up in my own testing vs /plan - not just more expensive but markedly worse code organisation, because the plan itself leads to higher cognitive burden for the models - and today it's even worse, because /plan doesn't hold up versus coming up with a few high level slices and having cc work on one per session, for much the same reason.

5.5 is much closer to Fable so i don't even need it. I am pretty sure it's got Fable's DNA in it.

I really need to find a role where I can do more DX...

Going through the superpowers spec-plan-implement-review cycle took one of my test runs (local AI) from 40 minutes to 8 hours, and produced a lower-quality result. I want to use something like that skill, but I'm doubting the efficacy of this one.

My workflow is very similar. But I just ask agents to write design in html instead of markdown, due to its richer layout and better interactivity. When the design is about UI or anything related to graphics, this approach is extremely efficient.

I also found that having the design reviewed by multiple agents has very little marginal value. The review agent will always find something to improve, but mostly it’s just nit and not anything super important.

I used to let Claude just upload the html design doc to Claude artifacts for me to review. Recently I switched to codex and started to use my own tool https://github.com/hyperlogue/r3 to complete this workflow.

I do the same, I don't use Claude Code or Codex planning because it is mostly pointless, even with Fable/Astra. I just have multiple agents work on a markdown file which I manually perfect, often breaking into multiple different files for large features or PRs. I also create design 'handoff' documents which I feed into Claude Design or Astra along with screenshots and wireframes. By the time an agent does something I'm well prepared.

I've tried doing the incremental, iterative approach with just Code and it's just not as effective unless you're working on something simple or experimental. Or you're shipping to something non-serious or perpetually beta.

Have you recently tried working without generating that plan? What I've been doing is first tell the model I want to plan the implementation, talk about it a few turns, then when I'm happy with the idea and method just tell the model to go ahead with the work.

Note that this is only really necessary for complex work that I don't know yet what the best way to do it is.

I've tried doing it your way as well, but there was just too much fiddling about with writing the plan somewhere, then having another session rebuild their context with whatever info is in the plan. It really didn't result in better output for me.

Currently 9 times out of 10 I just say to the model: xyz is the problem/bug/feature, fix it. Since about Fable and Opus 5, this is more than enough. Opus 5.5 (and previously Fable 5.1) got even better at this. However, this is in a codebase where there are already a few hundred thousand lines of code for the model to look at to see how we generally attack things in our codebase.

Claude Codes plan mode I never use anymore, it was useful a few months ago because the models had a tendency to just start doing work and forget I specifically told them not to. But the UX is just annoying and the models now do adhere when I tell them not to change anything.

I have, and it always does something unexpected and undesirable.

Plan mode ensures I'm spending fewer tokens on the code-test loop, and more on the arch/design, and allows me to keep appraised of what's going on, while planning for future changes better.

Maybe folks who don't need planning, don't have as much concern for the details, and are happy enough with just evaluation of if it works or not.

I have roughly the same workflow, also with plannotator - which I like a lot - and haven't used or felt the need to use _plan mode_ for at least 3-4 months.

Then telling Claude to work on a document, the instruction is kept to its core.

Now when bcherny explicitly mentioned that it merely adds a single line - it explains why I don't need it.

What may be concerning about "super plan" mode from the creators (or a skill, for that matter) - is that tuning the amount of effort, and how much deep to dig - may become too hard, as it will interfere with several embedded paragraphs explaining what to do, how to do, where to do, etc'.

What I do look for is even better plannotator ability to track changes, combining historical comments (like Google docs), and git blame of several "generations" before current reviewed doc.

Couldn't you commit the plan markdown to git to get the tracking you're referring to?

While possible to commit, I'd still loose the comments themselves, and the commit will be at least per changeset, and not connected ro a specific changed section.

Roughly speaking, I'd be happy if plannotator would persist something similar to github PR reviews combined with Google docs comments & suggestions.

I do something similar. But where I change it up a bit is depending on plan complexity I divvy up parts of the implementation to different subagents with fresh, only relevant context for whatever they're responsible for doing (e.g. a part of that plan). Edit: to clarify, I will also go back and forth with the planning agent making sure edge cases are covered. Sometimes that involves invoking a new subagent without our planning context to validate it without preconceptions.

I personally still find planning a valuable mental exercise; it's not so different from pre-LLMs and whiteboarding or otherwise taking the time to consciously plan a set of work.

Yeah, sure, but you don't need a dedicated plan mode for that at all. you can just do it in auto mode, and say "let's do some planning first", and Claude will (nowadays) be smart enough to understand that it's not supposed to jump straight into the implementation.

So again: You don't need plan mode, auto mode works just fine, there is no difference in the workflows here.

> write down a markdown file with its plan, then review the plan using plannotator

How do I use plannotator to review an arbitrary markdown file? It always opens the Claude Code plan file for me.

On the quick start page it looks like you just pass it as a CLI argument: https://docs.plannotator.ai/open-source/start/quickstart

I use similar approach, but use gpt to review plan written by opus.

This is pretty much exactly the flow we built Nuanced.dev around.

That used to be my flow but I stripped it all out with opus 5.5 and it's working great. You don't need all the process anymore

I do something similar but a bit more involved, using a few informal stages. Let's say for example I'm trying to launch a new complex feature for https://coderba.se.

- strategy document

- "sprint" document with technical implementation

- actual implementation

- e2e testing scenarios updates

Every step involves iterating with Claude on it with me in the loop (setting the direction then resolving the "founder questions" as they appear), and importantly a different model for review/code-review, be it Codex (usually, it's great at it) or Antigravity/Gemini (sometimes finds novel things, its precision and recall are abysmal but on the odd occasion it has good accuracy). This iteration on the high-level plan then on the implementation plan is essential to me, and IMHO part of why people are surprised that I tend to get solid results from LLMs. At the very least, it allows me to fill gaps in my own knowledge (primarily front-end development) and be more productive than writing the code myself. I cannot stress enough how nice it is to have a partner in the high-level system design – yes, it often suggests utterly moronic ideas, but the overall experience is still net positive and getting better every quarter.

both points to the same outcome: plan mode within harness is dead.

Only because the harness’ current plan mode is too limited.