[HN Gopher] Show HN: VS Code Agent Kanban: Task Management for t...
___________________________________________________________________
Show HN: VS Code Agent Kanban: Task Management for the AI-Assisted
Developer
Agent Kanban has 4 main features: GitOps & team friendly kanban
board integration inside VS Code Structured plan / todo / implement
via @kanban commands Leverages your existing agent harness rather
than trying to bundle a built in one .md task format provides a
permanent (editable) source of truth including considerations,
decisions and actions, that is resistant to context rot
Author : gbro3n
Score : 85 points
Date : 2026-03-09 10:28 UTC (12 hours ago)
(HTM) web link (www.appsoftware.com)
(TXT) w3m dump (www.appsoftware.com)
| h4ch1 wrote:
| There's also https://github.com/openai/symphony that's being
| developed following a similar Kanban pattern based agent manager
| (though yours is more sophisticated at the moment imo)
|
| Interesting to see the Kanban workflow being adapted to managing
| agents, makes sense; each item having the same UX as a Github
| Issue.
| gbro3n wrote:
| 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.
| verdverm wrote:
| 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
| maurelius2 wrote:
| I can certainly see the appeal of distributing the context with
| vc. However, I have always imagined this to be integrated into an
| existing kanban workflow, similar to a Jira or gh issue board.
| Perhaps agent specific, perhaps not.
|
| Furthermore, an existing kanban (ticket) workflow will expect you
| to refine the context into something more ... concentrated, or at
| least something that we are used to seeing as developers working
| with tickets, at least more so than the chat history that seem to
| be favored.
|
| Have you put any thought into how this would integrate into such
| a process?
| gbro3n wrote:
| 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.
| gbro3n wrote:
| Intro: https://www.appsoftware.com/blog/introducing-vs-code-
| agent-k...
|
| Youtube (Quick demo): https://www.youtube.com/watch?v=Y4a3FnFftKw
|
| GitHub: https://github.com/appsoftwareltd/vscode-agent-kanban
| ssgodderidge wrote:
| Great to see more products in this space! Definitely going to try
| this out on desktop.
|
| I'm doing a fair amount of work on mobile, and prompting remote
| agents. I would love someone to build an OSS cross-platform
| kanban. It'd probably be complex to add triggers of workflows
| both locally and remotely though.
| gbro3n wrote:
| 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!
| wek wrote:
| This is interesting. We've seen markdown as the app. This is
| markdown as the database for your tasks.
| termwatch wrote:
| interesting feature!
| hodanli wrote:
| I am using another VSCode Kanban extension. Very similar workflow
| to this one. I am very happy with it, it solved many issues I am
| having with context.
|
| https://github.com/LachyFS/kanban-markdown-vscode-extension
| gbro3n wrote:
| 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.
| hodanli wrote:
| The way I do it is with an agents.md prompt (though the
| extension provides a skill). Basically, if a Kanban item is
| created and referenced, ai uses that to log changes,
| decisions, and proposed commit messages etc. If there isn't a
| Kanban item, it creates one and does the same.
| empath75 wrote:
| I had claude build me something similar for my own autonomous
| agent system, because I was irritated at how much friction Jira
| has. I suspect a lot of people will do this.
| Zigurd wrote:
| For a long time I've been an agile fundamentalist. I welcome
| agent assisted coding because it reduces team size and increases
| autonomy, experimentation, and generally makes self organizing
| teams a more obvious choice.
|
| Highly structured pseudo agile practices like scrum, never mind
| SAfE, make even less sense now than they did before. Flat
| collegial teams for the win.
| gbro3n wrote:
| 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.
| Zigurd wrote:
| Kanban boards are fine. But if you load them down with the
| rules and elaborations they become part of a travesty of
| agility. Kanban originated as a lightweight shop floor MRP
| technique. It was meant to be run by the people making stuff.
| ebiester wrote:
| I mean, this is a task board and not a Kanban board - Kanban
| implies things like Work In Progress limits, continuous
| improvement, and measuring flow to get rid of blockers.
|
| But you're right - you can visualize your workflow without
| using Kanban - I think it's weird how the term gets
| appropriated here.
| trvz wrote:
| Lane position should be managed by putting files into different
| folders.
|
| Name and dates can also be stored in the filename and file
| metadata.
| gbro3n wrote:
| 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.
| varispeed wrote:
| Every time I see this phrase: "Why This Matters"
|
| I wish I could unread it.
| gbro3n wrote:
| Harsh but fair!
| xxwink wrote:
| As a project manager returning to coding after 20 years -- this
| is directly relevant to my experience. AI can genuinely augment
| both productivity and creativity, but it needs strong process and
| constraints to do it well. What separates throwaway AI code from
| something maintainable is product vision and tooling that keeps
| the AI focused. This looks like a step in that direction.
| gbro3n wrote:
| 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'.
| bryanhogan wrote:
| Excited to see many version of such tools to pop up, was also
| planning on building my own actually. Hope people can share the
| most competitive ones here in the comments.
| swaminarayan wrote:
| "Context rot" with AI coding tools is definitely real. After a
| few sessions the agent forgets earlier decisions, and you end up
| repeating the same planning conversation again.
|
| Storing the plan and discussion as Markdown in Git is an
| interesting approach. It basically treats the agent's reasoning
| as part of the project history, not just the final code.
|
| Curious if others here are doing something similar to keep
| context across sessions.
| gbro3n wrote:
| 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.
| swaminarayan wrote:
| sure will take a look
| arikrahman wrote:
| Manus workflow uses three file approach via deliverables.md,
| taskplan.md, and notes.md. I use this combined with VSDD with
| my agents.
| physicles wrote:
| I've been following that post too since I started using
| Claude (about two weeks now) and it's great. Sometimes for
| small changes I shorten research+plan into one step but I
| always tell it to stop and wait before it writes the code.
|
| One thing I've learned: if you notice the agent spinning its
| wheels, then throw the work away, identify a fix (usually to
| Claude.md) and start over. Context rot is real.
| noemit wrote:
| 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.
| scotty79 wrote:
| 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.
| bryanhogan wrote:
| Sorry for the slightly unrelated comment, but the amount of AI
| written slop comments here is so high. Was this caused by
| mentioning "AI" in the title?
| Sakthimm wrote:
| 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.
| ryanholtdev wrote:
| The .md task format as persistent source of truth is the key
| insight. Context rot is a real problem mid-sprint when agents
| lose track of earlier decisions. Do you diff against previous
| state if the agent rewrites a task file mid-execution, or does
| the human review before committing?
| sathish316 wrote:
| OpenKanban is pretty cool if you're on the other end and want to
| use Terminal for both Coding and Task/Project management. It's
| almost as good as a Terminal version of VibeKanban, but not so
| feature rich - https://github.com/TechDufus/openkanban
| gbro3n wrote:
| 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?
| KronisLV wrote:
| I think a container of Kanboard https://kanboard.org/ and an MCP
| integration would achieve something similar - mostly cause when I
| think of project management tools that is the only one that
| actually feels insanely snappy, compared to the slowness of Jira,
| OpenProject and tbh Trello is also slower.
|
| Would actually be cool to have more local tools like that, that
| something like Claude Code can integrate with. Find a bug in the
| code of your own implementation? Comment it in the issue, or add
| a new thing to fix, then at the end of implementation do a small
| retro and maybe end up with a SHORT sentence to add to CLAUDE.md
| on what to look out for in the particular project, OR create a
| new work item to make some additional prebuild scripts or tests.
| rcarmo wrote:
| This is pretty awesome. I might build something like this into
| https://github.com/rcarmo/piclaw (I already have checklists and
| an editor, so...)
| equasar wrote:
| Can we stop all these vibe-coded projects landing on the front
| page? It is annoying. Just feels like reddit.
___________________________________________________________________
(page generated 2026-03-09 23:01 UTC)