Kanbanero
Sign in

What Kanbanero is

Kanbanero is where you request work from your development team and follow it until it is delivered. You describe in your own words what you need. You do not need to know anything about how software is built.

The work itself is done by AI, Claude, running with the developers on the team. Kanbanero keeps the work in order: what has been requested, what is in progress, who did what, how much work it took and what is done.

The problem it solves

Asking an AI to write code is quick. The hard part is everything around it: that it understood what you meant, that someone checks the work before it becomes part of the product, and that afterwards you can see why something turned out the way it did. When you talk directly to an AI, most of that exists only in the conversation.

Kanbanero gives every request the same road, with checkpoints along the way:

  1. Analysis. The request is read and interpreted. If something is unclear you get questions, and you answer them here.
  2. Decomposition. The request is split into smaller parts that can each be built and checked on their own. You see what the parts are.
  3. Build. Each part is built and tested.
  4. Review. The work is read by a reviewer who did not build it, with security in mind as well. If the reviewer finds a fault, the part goes back to the build.
  5. Merge. Only when the review has approved a part is it brought into the main version of the code, the version everything else is built on.

A project can also take a shorter road, where several of the steps are done as one. There, too, the work is reviewed before it is brought in.

What you get out of it

  • You do not have to repeat the context. A project can have a goal: a description of what the product is meant to become, for whom, and what matters most right now. It is on the Goal page here, where any requester in the project, anyone who may file requests there, can change it, and earlier versions stay readable. If there is one, the analysis reads it with every request, so your request only has to say what is new. If a request seems to pull away from the goal, the analysis may raise an objection, and you answer it on the request's page: rewrite the request, have it built as it stands, or change the goal. The work goes on whichever you pick.
  • You see how it is going. Every request shows its parts and how far they have come.
  • You can change your mind. Until the work has started you can change your request. If you are not happy with what was delivered, you can request a change to it.

You file your requests here, in the browser. If you already use an AI assistant, you can also file them directly from there. That requires a paid plan with the assistant's provider, and it is an option, not a requirement.

Compared with just using Claude

You can also ask Claude for the same thing directly, or ask a developer to do it with Claude. Sometimes that is the right choice. This is how the two roads differ.

In favour of Kanbanero

  • The work is reviewed before it becomes part of the product. Directly with Claude, the person who asked is the one who has to judge whether the answer is right. Here the work is first read by a reviewer who did not build it, and the reviewer can send it back. The reviewers are AI too. They do not replace your own judgement, but the work never gets to approve itself.
  • You see what is going on and what it has cost. Every request shows what the work has taken so far, in time and in tokens. The estimate of what it would take is not on the request: in projects that plan the work in rounds, called sprints, it is on the sprint's page, and if you have connected an AI assistant it can tell you as well. Tokens are the AI's measure of how much text it has read and written: a measure of the amount of work, not an invoice. Directly with Claude you only see the conversation in front of you.
  • Decisions and questions are kept. Every question and every answer you have given is kept and stays on the request's page. The same goes for decisions made for the whole project, and whoever builds something is shown the decisions that concern it. In a conversation with Claude the decisions live in the conversation, and whoever takes over next time has to find them there.
  • Every change can be traced. From your request, through the parts it was split into, to the change in the code: who requested it, who built it, who reviewed it, and when.
  • Production is protected by a person. Kanbanero itself can read the code but not change it, because the changes are made on the developers' side, and Kanbanero never releases anything. Getting a change to the people who use the product, what is called a release, is a separate step that a person on the team takes. Directly with Claude it is up to each person how far the AI may go.

Against

  • The work only moves while a developer is connected. Kanbanero runs no AI itself. The work is done in a developer's own Claude session, that is, Claude running on the developer's computer on their own subscription, and the terms of such a subscription do not allow a program to start it automatically. When no session is running, everything stands still. A request that comes in during the night lies untouched until someone on the team starts theirs.
  • A small change is faster directly. Fixing a typo takes a minute with Claude. Here it still has to be analysed, built, reviewed and brought in, and that takes longer than the change itself. If what you requested has already been done on the side, you or an admin can close it as delivered, and it then shows as delivered outside the pipeline.
  • Every request costs more runs. Analysis, decomposition, build and review are each a separate work session for the AI. The same change therefore takes more AI work here than directly. That is the price of the checkpoints.
  • You have to be invited and sign in. You cannot create an account yourself. An admin invites you to a project with your email address, and then you sign in in the browser. The reason is that whoever can file requests can, in the end, get changes into the product.
  • Someone has to set up the project first. An admin creates the project and connects it to the code before anyone can file requests in it.

When it is not worth the trouble

You are on your own: you are both the one who wants something and the one who builds it, and you want to try an idea over an afternoon and perhaps throw it away afterwards. Then there is nobody else who needs to see the work, no decision anyone else has to find later, and every checkpoint is just waiting. Ask Claude directly.

Kanbanero is worth the trouble when several people share a product that is used for real, when the one who requests is not the one who builds, and when the decisions need to be found again in six months.