Then the reviewer returned the form to the coder twice: first because of the language and set of fields, and then because of the remaining unnecessary workplace selection. By the second time, the test had already captured this error and was passing. I did not monitor the internal returns between roles or intervene in them. The roles communicated on their own.
On the third attempt, the reviewer ran the checks, took screenshots following the scenario from the plan, and compared each screenshot with the plan:
# Code review — 260326_0140_air_time_booking_workplace_flow **Status:** ✅ OK ## Commands / evidence - plan_lint.py docs/plans/260326_0140_air_time_booking_workplace_flow.md → OK - manage.py makemigrations --check --dry-run → No changes detected - make doc-lint → doc-lint: OK - make test-air TESTS="apps.bookings.tests.test_services …" → OK (119 tests) - make test-car TESTS="apps.bookings.tests.test_views …" → OK (67 tests) ## Visual evidence - air_02: same-modal invalid rerender preserves `Lesson from the AUC section`, entered title, selected client/instructor/aircraft, and preview placement.Here is this frame (the data is for demonstration). The form was submitted without the lesson from the AUC section that the scheduler had asked about. The window did not close; it displayed an error and preserved the title, trainee, instructor, and aircraft.
The first time, he did not accept it because the set of files in the plan did not match what had been prepared for the commit: three files were not part of the declared set, and the task was returned to the developer. After the correction, the architect accepted it. With this setup, my control task became simpler: I check whether the plan, review, tests, and screenshots line up.
How the Pipeline Improves Itself
The idea of developing the pipeline gradually took shape. At first, after each plan, I left the role threads open and continued with subsequent plans in them so that the threads would accumulate history. While they were still relevant, I asked what else they would suggest completing and how they could help with the task or the process. These were manual prompts: I asked questions, collected the responses, and changes accumulated that way. Then I automated it. In the main mode, after each plan, the roles perform a docs closeout, that is, they suggest what else needs to be done on the task and how to improve the process so it does not get bogged down. The suggestions are collected into registries, and then triage checks them: whether this should be done and in what form. First an experiment, then implementation.
At the beginning of the year, I was actively monitoring the state of the pipeline. After each task and post-merge check, I launched the pinned threads in Codex. They examined what the commits had brought in, what had changed and how, and looked for anomalies. Together with them, I dug into cases that yielded something.
I immersed myself in an environment that was new to me, read the news, and tried applying other people’s mechanics to the pipeline. I still brought in anything new I came across. I brought in search ideas from the market, such as QMD. It is an open-source search tool for Markdown files. We compared them and decided that QMD was unnecessary; SQLite full-text search was enough.
I took the idea of doc gardening from an OpenAI article about harness engineering.This is a process that keeps the documentation up to date. As it happened, I was looking for what this process was called, took it as an option, tried it, and it worked.
Where I need to stay in control
A sign that the process may stall is the iteration limit. After 12 iterations on a single plan, the manager role stops. An iteration is a manager step: invoking the role along with a self-check. In case of an anomaly, I start a separate thread in Codex and figure out whether we have gone off course, whether the scope needs to be narrowed, and what is actually happening now. If necessary, I narrow the scope of the task or ask to split it into separate plans. Such an investigation usually takes me up to an hour.
Sometimes, several iterations of simplifying the plan do not reach the intended goal. In that case, I resort to help from other models, such as Opus 5.5. I also often validate plans with the GLM model through MCP and ACP integrations.
Sometimes the pipeline has a clear brief, the work is done, but the direction is wrong. In that case, I investigate what ended up in the brief and where it came from. This is what happened with the role proposals in Tooling itself. I kept working on it for a long time and added unnecessary complexity: the roles submitted proposals to the manager, and the manager invoked the helper on behalf of the role and recorded what it had proposed. I decided to simplify the design: the roles should invoke the helper themselves, directly, without the manager.
Or another example. During the summer, I noticed that GPT-5.6 Sol was complicating the designs. Most of the time went not into solving the task, but into proving made-up, highly theoretical cases that could then neither be reproduced nor fully substantiated. Often, this led to the unnecessary construction of an “iron bridge hanging in midair.”For example, the model in Codex wanted to add wrappers and isolation when working with Git and its API. This was not required by the task, but Codex was determined to provide a clean proof.
Then I stepped in: I began monitoring which decisions were being made and requiring simplification and a search for alternatives. For example, I assumed that there was no need to prove that a proxy had failed somewhere. In other words, I introduced deliberate simplifications to determine what we were actually running into. The picture changed, some openings appeared, and we managed to complete the task. I still do this today.
Once the plans had been broken down, I would leave the pipeline unattended for a week. I would create 7–10 plans, and if everything worked normally, they would be closed. Then, during the post-merge review, I would look at the commits, screenshots of the CRM changes, and the documentation in Tooling. I never left it unattended for a whole month.
What we ended up with
The CRM was built for two areas: aero clubs and car rental. Their registration and management functionality differs slightly and is determined by the launch key, but the service is unified. The work lifecycle has been implemented for managers, customers, instructors, and aircraft technicians.
An example of the functionality that has been implemented and is available in the test environment: a manager selects a time interval in the venue calendar and creates a booking, while the system checks whether the venue, aircraft, and instructor are available. The instructor’s dashboard contains documents with validity periods—a license, medical certificate, and insurance—as well as their available flight day. Before a flight, the instructor prepares the aircraft, records the fuel and documents, and then logs the rental, the start and end of the flight, and the hour-meter readings. After the flight, an entry with the flight hours and the instructor’s comment appears in the customer’s logbook, while the aircraft’s hours are tracked separately.The Telegram bot sends the instructor a daily summary and notifies managers about new bookings.
The BRD has not yet been fully implemented, and there are still some parts to refine. We need to make it possible for clients to choose the time and plan their flight through the Telegram bot or on the website, whichever is more convenient for them from a computer, while instructors set the times and locations when they are available to conduct a lesson. We also need to track instructors’ time for billing with the airfield: the airfield pays for the services.
For scale: CRM currently has around four hundred plans, while Tooling has more than eight hundred. The pipeline slows things down wherever documentation needs to be changed: this can take several hours because all roles have to approve the changes. That’s why I make some documentation changes outside the pipeline. One of the most valuable benefits is that Tooling has become an experimental testing ground. I tried out mechanics there that I later used in pipelines at my main job.
How much does it cost?
I started with $20 subscriptions for GPT, Opus, and GLM models. For a solo developer, they should be enough to get started. Last summer, I realized that everything was getting more expensive while Chinese models were advancing, so I wanted to move development to local models. I upgraded my MacBook and got a little more memory so I could try Gemma, Qwen, and GLM. Smaller models are not yet intelligent enough to trust with anything, while larger models in quantized form use up all the memory.But it turned out that it’s convenient to run many Codex instances in parallel.
I currently have an annual GLM subscription on the highest tier, and its limits are the first to run out. I also have two personal Codex Pro subscriptions and a Claude Ultra subscription. This is necessary because I work on many projects in parallel and cross-check the results with different models. I pay for the subscriptions myself and use them to some extent in my main work: at the moment, it’s specifically about creating pipelines. This is my setup—it gives me peace of mind, and this is how I structure my work.
When a pipeline is needed
Most simple or nonstandard tasks can and should be solved by dropping a prompt into Claude or Codex. A pipeline comes into play when you need routine, stable, predictable, and controlled development. That’s why I use a single prompt in chat for supporting analysis or for dealing with unusual and new situations: checking how a new mechanic performed, investigating whether I need QMD and whether to store JSON inside an MD file or use plain MD, and comparing task-tracking systems.
If you compare skills with a pipeline, then, as I see it, skills are better suited to describing work involving clearly defined functionality, a program, or a utility. Perhaps I’m wrong. I use them for technical tasks that don’t need to be explained every time: they have a template, clear mechanics, and a set of helpers. For example, a skill creates a draft plan and puts a task into the queue. None of my skills has grown into a pipeline: I approached this deliberately from the moment skills first appeared. A skill can test another skill, but that’s already a construct that must carry context between the steps or, conversely, not carry it.
Acceleration and illusion go hand in hand here.With a regular prompt, it seems faster, but only up to a certain level. The same is true of a pipeline: once it is set up, everything seems fast, but again only up to a certain level.
If you need to make a quick fix, a prompt is enough.
Minor edits: fix three lines of documentation, configure CI, change a test—why use a pipeline here? It just wastes resources.
The work is repetitive or small, fits within certain bounds, and has a template and a set of helpers—that’s a skill.
The work is substantial: the model lacks context, recoverability is needed, and you want to double-check it—it’s time for a pipeline.
A pipeline is needed where consistency and process tracking matter.
For me, a pipeline is an opportunity to do things I wouldn’t have done myself because of certain constraints. Sometimes it’s a lack of knowledge or skills, and sometimes it’s a lack of time: you simply don’t have time to handle it yourself. A pipeline gives you freedom. You load it and get to work.Came back—and just like that, everything was ready.
