That's a nice UI on that board. It's advertising the ability to allow the agent to help manage tasks, where this approach uses the tasks to drive the agent.

I'd been using this workflow for a while, but this post I found on HN a couple of weeks ago really solidified it: https://boristane.com/blog/how-i-use-claude-code/

> The workflow I’m going to describe has one core principle: never let Claude write code until you’ve reviewed and approved a written plan. This separation of planning and execution is the single most important thing I do. It prevents wasted effort, keeps me in control of architecture decisions, and produces significantly better results with minimal token usage than jumping straight to code.

I have a log of commits and the decisions and changes for each commit. I use it as a source of data/context when building out plans.

I agree with the other commenter who said they don't build anything without a plan. I would double down on that and say that you need to overplan, and regularly toss out plans as you do research/discovery.

I'll never understand why people treat context as anything other than ephemeral.

If you had a coworker that had tendency to hold everything about the project in their head you would push them to write stuff down eventually.

In strong words probably.

[dead]

Working on additional meta data in the file. What makes you prefer to have lanes managed by file move? I considered it but was concerned about the potential loss of data if there are unsaved changes in the file, or the user accidentally moving a file while the agent is writing to it. I will consider that further though.

I did - GitHub and Trello (and I expect Jira) have APIs that could be used to hook up an MCP server. I liked the idea of conversing with the agent in the ticket, but I decided against that because I'd have to keep refreshing the issues, and it seemed a bit janky moving in and out of the IDE.

I also considered a full harness that could stream / sync the responses, but as per my comment below, implementing a full harness meant loosing a lot of the IDE integration features that come with the hand off to GitHub Copilot.

> I went down the route of implementing a full harness for a while like Vibe Kanban, but the issue was that it was unlikely (without significant effort) to be as good as Github Copilot chat, and it meant forfeiting all of the IDE integrations etc (like diff visualisation for the agents actions etc).

Having worked with a flow similar to this for a while - the markdown files become quite valuable as a history of planning and decisions for features. I didn't want to loose that. I just needed some help with managing the plan files I was maintaining - which the kanban board tooling does. A few command shortcuts via @kanban help too

Regarding what goes into the files, the agent tends to be quite concise - you don't see the whole train of thought that some of the harnesses surface.

That does look great. I will check that out. What is the storage for the tasks? I didn't love the Git worktree flow when I tried vibe kanban, spawning lots of folders seemed like it could get problematic on large codebases - unless I'm missing something and just need to get used to that?

Can you explain further how that helps / works?

Thanks. I also saw Vibe Kanban which looked quite mature with lots of features. But I was really liking working with markdown files in VS Code - with everything that comes with that (version control capability etc). I went down the route of implementing a full harness for a while like Vibe Kanban, but the issue was that it was unlikely (without significant effort) to be as good as Github Copilot chat, and it meant forfeiting all of the IDE integrations etc (like diff visualisation for the agents actions etc).

Having the Kanban board in VS Code where I'm working, backed by markdown, GitOps friendly files works really well. Moving from the markdown file to the chat editor to type 'plan', 'implement' isn't what I really wanted, but it's really not a problem once you get used to the flow.

What I don't get is why not just use GitHub/Jira kanban directly with the CLI. We don't put them in git for multiple reasons. What are the people who only work in the browser going to do with this?

It reminds me of how Zed wants to have built in Slack when it will be impossible to get everyone to use Zed. A feature that can never really materialize because developers get a say in their tools

I would say that a kanban board is not synonymous with scrum. In this workflow, the tasks are a way of organising task threads and recording the consideration, decisions and actions taken while working with an AI agent.

Yes - and keeps the user in the IDE. There's lots of products with their own harness. I know harnesses are not that complex to build - but VS Copilot has really nice integrations with the editor. Either one of these companies has to build their own editor, the IDE's need to build in their own task management / kanban, or we need an extension (like this one). I'm working on improving the UI task file management and AGENT instruction, but the hooks that VS Code exposes regarding what you can inject into the chat are something I'm having to work around.

Maybe it will go that way eventually. I haven't got into being able to hand off to agents in the cloud yet, I think as good as LLMs are getting, for complex / professional work the agents still need a lot of steering. I just have to be in the editor with the agent!

I think OpenClaw is the reason we are getting so much AI slop these days. The comments here with "key insights" are coincidentally < 1 month old. It seems for some reason, OpenClaw/NanoClaw loves Show HN posts.

You're absolutely right! And here's why it matters—

Harsh but fair!

Agreed. Also multiple humans. One task per person works great (no Git conflicts). I'll think about this more. I'm thinking that having the agent work through an MCP server might be a means of mitigating the issue. I'd rather keep the sync process in Git if I can.

Structure certainly helps, and that's what the markdown format here does. How do you measure the effect of the structure?

Having used a less formalised version of the process (manually managing the agent files but having the user / agent conversation structure the same), I've been getting some really good results out of the agent on some long running complex tasks. I'm seeing so many people talking about leaving agents running and completing projects end to end without any intervention, but my experience so far is that decent software still needs architecture guidance and a human sense of 'taste'.