Django CRM author builds a five-role AI pipeline that drives a task all the way to a screenshot

A familiar picture: you launch Claude or Codex, throw in a prompt, and get "done." You open the code and find the same forms, only with renamed variables. The author of a write-up on Habr came from database development and in autumn 2025 took on a CRM for car rental and flying clubs. He went through this four times in a row and ended up building a pipeline that drives a task by itself and brings back evidence.

Why one prompt is not enough

He was building shared resources for cars, instructors and venues in Django. The forms were similar, and he wanted to reuse the code. Codex reported that the refactoring was complete, but review showed that almost nothing had changed. Three more rounds in different chats produced the same result. The author's main complaint: he only understood what the model had actually done at the very end. Knowledge had to be carried between chats by hand, and context compaction lost details.

He needed a system in which it is visible up front how the model understood the task, the work is broken into steps, and each step is checked by someone else. He could not check everything himself.

Five roles and one file

The roles grew out of a set of console wrappers for Codex CLI, Claude Code and GLM. At first there were four:

• the architect builds the high-level solution (GPT models in Codex);
• the planner determines the set of files and sketches a draft of the code;
• the coder writes the changes;
• the reviewer checks the result. This role was given to GLM, partly to stay within subscription limits.

When parallel work in five git worktrees consumed the author's attention, the manager appeared. It is an almost mechanical role that hands off the turn. The author made it an agent rather than a script because he wanted to ask "what status are we at." There are now two reviewers, split by areas of responsibility.

Everyone is tied together by a coordinating artifact, the plan file. The architect maintains it, the others append their own sections, and the manager only reads it and passes the turn on. The header records the status and who is entitled to set it: Ready for Planner, Ready for Coder, Ready for Review, Done. This is the same idea as in SDD frameworks such as Spec Kit, OpenSpec, BMAD and Kiro. The task lives in a file and survives context compaction.

There is also an amusing detail: the roles disliked rereading the plan and relied on "memory." The architect once declared that it was the planner's turn, although the planner had already finished. The fix is simple. A helper issues the status, the role asks it and invents nothing.

What it looks like on a real task

The task came from the CRM for flying clubs: booking an aircraft, an instructor and a student by time. The planner noticed that the data model had no place for the field "Lesson from the ATO section" and asked the architect a question marked "blocker." The architect specified where to map the fields, and the coder started work without questions.

The reviewer sent the form back to the coder twice. The second time, a test had even cemented the bug and passed, which is why green tests alone are not enough. The third time, the reviewer ran the checks (119 and 67 tests, a migration check, doc-lint), took screenshots following the scenario from the plan and compared each one against the plan. The architect opened six screenshots and did not accept the task the first time: three files in the commit were not in the declared set. After the fix, it was accepted. The human submits the task at the input and looks at whether the plan, review, tests and screenshots agree.

The pipeline also improves itself. After each plan, the roles do a docs closeout: they suggest what to finish and how to improve the process. Suggestions accumulate in registries, and triage decides what to adopt. The author also takes ideas from outside. Golden paths, short recipes of the form "for a typical form, open these 3–5 documents," and doc gardening came from OpenAI's article on harness engineering. QMD search over markdown was tried and rejected: full-text search on SQLite was enough. A limit guards against looping: after 12 iterations on one plan, the manager stops the work.

Limitations and what to take away

This is the experience of one person on one project, without measurements such as "saved so many hours." The author never brought the forms to a single codebase, settling on an "understandable level of sameness." Not every edit goes through the pipeline, only those that need a trace in the repository. Checking by another model now mostly happens outside the pipeline. The specific models he names are not the main point: they change faster than the process.

What to take into your own project:

• Demand evidence, not reports: tests, screenshots, comparison against the plan.
• Set up a single task file with statuses and a rule for who sets which status.
• Do not ask the model to compute the status; move it into a helper.
• Let the roles ask blocking questions before code is written.
• Set an iteration limit so agents do not spin endlessly.

The main lesson: a prompt is good for a one-off solution. As soon as a project has to be developed and maintained, you need a process whose result can be verified with your own eyes.