What is kaizen? A guide to continuous improvement on VibeKaizen

The "kaizen" in VibeKaizen is not decoration. An idea from Japanese industry shapes how the platform works: split the work into small pieces, make every piece visible, and carry something learned from each round into the next. This guide starts with what kaizen is and where it came from. Then it covers how a kaizen board is used, what those ideas look like inside VibeKaizen, and what you can do to get better results.

What kaizen means

Kaizen (改善) is a Japanese word meaning "improvement" or "change for the better". As the Wikipedia article on kaizen puts it, outside Japan the word stands for many small, continuous improvements across every part of a company's work.

Three ideas sit at its core:

Small steps. Instead of one big, risky overhaul, you make small changes you can undo, often.
It never stops. Improvement is a habit, not a project. When one problem is solved, you look at the next.
Everyone takes part. Ideas don't only come from the top. The same article says kaizen involves everyone from the CEO to the cleaning staff. The Kaizen Institute sums it up as "Everyone, Everywhere, Every Day".

A short history

Kaizen grew out of post-war Japan. After the Second World War, American advisers helped rebuild Japanese industry. Part of that help was Training Within Industry (TWI), a US programme that had trained factory workers during the war years, 1940 to 1945. Its "Job Methods" course taught people to question every step of their own work. Can this step be dropped? Combined with another? Done in a different order? Made simpler? The programme was very well received in Japan and became the basis of the kaizen culture in Japanese industry. According to the kaizen article, a 1951 training film called "Improvement in Four Steps" introduced the word kaizen in this sense in Japan.

The second name to know is the statistician W. Edwards Deming. In the summer of 1950, invited by the Union of Japanese Scientists and Engineers (JUSE), he taught hundreds of engineers and managers about quality control. His message: better quality lowers costs and raises productivity and market share. JUSE created the Deming Prize in his honour that same year. The cycle Deming took over from Walter Shewhart and developed is known today as PDCA: Plan, Do, Check, Act. The four-word version came from participants at Deming's lectures in Japan in the early 1950s; Deming himself preferred "study" to "check".

The company that built kaizen most deeply into daily factory work was Toyota. The Toyota Production System was developed by Taiichi Ohno and Eiji Toyoda between 1948 and 1975. It rests on two pillars: "just-in-time" production (make only what is needed, only when it is needed, only in the amount needed) and jidoka, "automation with a human touch". Continuous improvement is one of its principles. Taiichi Ohno is considered the father of the system, which in turn inspired lean manufacturing in the West.

The person who brought the word to the West was Masaaki Imai. He founded the Kaizen Institute in 1985 and in 1986 published "Kaizen: The Key to Japan's Competitive Success" with McGraw-Hill. The book presented kaizen as a method managers outside Japan could understand and use.

Where it's used today

Manufacturing: from cars to electronics, kaizen and lean are still the everyday language of running a plant.
Healthcare: in 2002 Virginia Mason in Seattle began adapting the Toyota Production System to health care to improve patient safety, and named the result after itself.
Software: the last principle of the 2001 Agile Manifesto is kaizen in plain words: at regular intervals the team reflects on how to become more effective and adjusts. Lean software development, from Mary and Tom Poppendieck's 2003 book, carried lean principles over to software.
Personal productivity: the Kaizen Institute describes kaizen as improvement that runs through personal, home and social life, not just work. Fixing one small habit a little every day counts.

How a kaizen board works

The most visible kaizen tool is the board. It can be a wall, a whiteboard or a screen. Kanban, Japanese for "signboard", started as a card system Taiichi Ohno developed at Toyota, inspired by supermarkets: a shelf is refilled with only what customers took. Software teams adopted the idea as the kanban board. When we say kaizen board, we mean the same tool.

Columns are stages

Each column is a stage of the work: waiting, in progress, being checked, done. Each piece of work is a card that moves from left to right. Anyone who looks at the board sees where every piece of work stands without asking.

Work in progress is limited

Kanban's key rule is an upper limit on how many cards can sit in a stage at once, the WIP (work in progress) limit. When a stage is full, nothing new starts; you finish what you have first. That stops dozens of half-done jobs from piling up, and when a stage gets stuck, everyone can see it.

Problems stay visible

A stuck card isn't hidden; it's marked. The WIP limit helps here too: when a stage fills up, the blockage is in front of everyone. The aim is to solve a problem while it's small and fresh. A card marked "blocked" isn't a failure. It's an invitation.

A short daily look

Teams look at the board briefly every day. What moved? What's stuck? Who needs help? It isn't a long meeting; the point is to keep work flowing.

Small batches

A big job doesn't go on the board as one card. It's split into small pieces. A small piece finishes fast, gets checked fast, and its mistakes show up fast. In a big piece, mistakes surface late and cost more.

The improvement loop and retrospectives

The board isn't only for doing the work; it's for improving how the work is done. That's where PDCA comes in: plan a change, try it, check the result, and make it stick if it worked. Software teams do this in regular retrospectives: what went well, what didn't, what will we do differently next time? A retrospective is only worth something if its decisions actually reach the next round.

How it works on VibeKaizen

VibeKaizen applies these ideas to a team of AI agents. There are four roles: product owner, architect, developer and reviewer. Tests aren't a separate agent; the platform's test gate runs them. You, the founder, bring the idea, make the decisions and try the results.

The board's columns

Backlog: your idea starts here. You describe what you want in the setup wizard; the product owner asks about whatever is missing, the architect writes the plan and each task's acceptance criteria, and the work is split into tasks. You approve the task breakdown. Work you put off for later waits here too.
Ready: approved tasks waiting for their turn. A task doesn't start before the tasks it depends on are done.
In progress: the developer agent writes the task in its own isolated environment and runs the tests. Before the task reaches review, its tests run in a real browser. If you connected a Figma file, the platform also compares the screen with the design.
Code review: the reviewer reads the change. If there are findings, the task goes back to In progress and doesn't move on until they're fixed. By default up to two review rounds are tried; if the developer and reviewer can't agree, the decision comes to you.
Acceptance testing: the task comes to you with a preview you can open and try in your browser. Approve it and the change is added to your app. If you don't like it, write why and send it back.
Done: tasks that were approved and added to the app.

A stuck task shows as Blocked on the board, and its card says why and what's expected of you: a key, a decision, or credit in your provider account. That's kaizen's "make problems visible" in practice.

Work in progress

On VibeKaizen the WIP limit is how many tasks are developed at once. Your plan sets the ceiling: 1 task on Solo, 2 on Pro, 5 on Team. Within a project you set the number in Settings, on the Board tab, for the In progress column. Too much parallel work can make tasks that touch the same files collide; a small limit often finishes sooner.

The review loop and your acceptance test

Every task passes two checks. First the reviewer agent reads the code, and every problem it finds goes back to the developer. Then you try it in the preview. That's a small PDCA loop at task size: plan (acceptance criteria), do (development), check (review, tests and your try-out), act (fix or approve).

Sprints, the sprint close and the retro

Tasks move in sprints. When a sprint ends, a release candidate is prepared and a retrospective is written. The retro proposes two things: changes to the pipeline rules, and lasting lessons for the agents. You untick what you don't want and approve the retro. The ticked lessons are added to the AGENTS.md file in your project's repository, and the agents read it on every later task. This is where the kaizen loop closes for the agents themselves: a mistake in one sprint becomes a rule in the next. Then you press "Publish release"; nothing is released until you do.

Settings → Pipeline

You change the rules of the flow under Settings → Pipeline:

Automatic approval: from 0 to 24 hours, 4 by default. If you don't respond in that time, the task is approved on its own. Set it to 0 and the task waits until you approve it.
Human review: turn it on and every change also waits for your approval after the reviewer agent and before the preview.
Round limits: review rounds, test attempts and acceptance rejections.
Budget per run: the most a single agent run may spend; $5 by default, adjustable from $1 to $20. Past it, the task stops and you're notified.

Tips

We built the five demo apps with as little input as possible on purpose: short ideas, mostly default answers, no edits to the task breakdown. The results work, but more guidance gives better results. Here's what you can do, item by item:

Write a detailed idea in the wizard. Who will use the app? What are the main flows (sign up, add a product, place an order)? What must never happen (seeing someone else's data, an order without payment)? How should it look and feel? A few paragraphs settle far more questions up front than a few sentences.
Give your own answers where it matters. Every product owner question comes with a default and what it leads to. The default is usually reasonable, but on questions that touch the heart of your product, write your own answer. If an email must really be sent, say "real sending, not a demo".
Edit the task breakdown before you approve it. On the task breakdown screen you can change a task's title, description, acceptance criteria, priority and dependencies, and remove tasks you don't need yet. To split a big task or change the order, use "Request changes" and tell the product owner.
Connect Figma if you have a design, and say what matters. The platform compares screens with the design, but it doesn't know which details matter most to you. The icons? The spacing? The fonts? Write it down.
Set role instructions. Under Settings → AI and roles you can add instructions for each role: your code style, your design preferences, what the reviewer should look at closely. They apply from the first agent run after you save them.
Try every preview like a real user. Don't just look at the home screen; sign up, enter wrong data, open it on your phone. When you reject, be concrete: what you did, what you expected, what happened. Not "it doesn't work" but "I pressed Save, the list didn't update, it showed up after a reload".
Keep tasks small. A small task is cheaper, faster and easier to try. If a task covers three screens, ask for it to be split.
Turn the retro into rules. If the same problem shows up twice, make it a lesson in the retro and approve it into AGENTS.md. For example: "Every form shows an error message when submitted empty."
Choose models per role. Give large tasks to a strong model on your own key and small ones to the platform model. The "For small tasks" option in Settings does exactly that.
Set a spending cap at your provider. On top of the budget in the pipeline settings, set a monthly spending limit in your Anthropic, OpenAI or Google console.
Publish a release when a sprint closes. When the release candidate is ready, read the retro and publish. A release left waiting makes it unclear what the next sprint is building on.

The demos show what minimal input gives you. More guidance means better results.

Sources

Kaizen (Wikipedia)
Masaaki Imai (Wikipedia)
What is KAIZEN™ (Kaizen Institute)
Training Within Industry (Wikipedia)
W. Edwards Deming (Wikipedia)
PDCA (Wikipedia)
Toyota Production System (Wikipedia)
Taiichi Ohno (Wikipedia)
Kanban and Kanban (development) (Wikipedia)
Virginia Mason Medical Center (Wikipedia)
Agile software development and Lean software development (Wikipedia)

Start with a small idea today; each sprint after that is a chance to make it better.