The goal is to keep the process light enough to be able to use locally hosted small model agents like Qwen 3.6 27B without letting the system digress into a vibecoded mystery.

So far I am using a very simple and yet very traceable workflow. It has formed into a convention that could probably be used in any project:

root
  |.meta
  |.fixes
  |.plans
  |.features
  |.reviews

The .meta folder contains information about the project and is added to the .continueignore so that it isn’t read by the LLM. It stores metadata about the project such as LLM configuration parameters and setup guides, and also keeps a prompt history as a series of daily markdown logs of the prompts used to create the system. Key prompts are always captured in the log first.

Most of the prompts simply reference either a .plan file, a .fixes file or a .features file. These document the system as it has evolved over time. All changes are first documented as an implementation plan with any background design or requirements context already established.

The workflow involves cycling through the steps:

  1. Write the prompt in the daily yyyy_mon_dd.md log file. This may be simple a reference to the already created implementation plan, or a request to create one.

  2. In Plan mode, point the agent to a .feature file describing the requirements, or have the requirement embedded in the prompt. The first output is a detailed implementation plan that the Agent can follow.

This enables agents to restart where they left off after a crash by retracing what has already been done, without having to re-invent the implementation from the requirements.

  1. Once the implementation plan has been reviewed and adjusted it is time to move to Agent mode, which is often simply a prompt like:
Please complete the implementation in .plans/error_surfacing_remediation.md 
and follow the specifications in the plan precisely.

This sort of prompt can be re-used after a crash and the agent will assess the implementation state against the specifications to know where to continue.

  1. When the implementation is complete, and the build and tests pass, it is time to swich back to Plan mode and have the agent review the implementation.

  2. The review is captured into the .reviews folder in readable markdown where it can be edited and read before the Plan mode turns it into an actionable remediation plan usually then stored in .plans.

When in Plan mode, the content is produced to output (as it is a read-only mode), which is then quickly reviewed before being manually copied into a markdown file in the appropriate folder.

With self-hosted agentic code reviews are free and can be performed often. Placing them into the workflow before testing and review saves a lot of human effort.

Each of the folders has an .archive sub-folder where completed plans are moved once finished and verified, and reviews are moved when their output has been reworked into a remediation plan.

When the prompt history is combined with the referenced plans and feature specifications, in combination with the git history, there is a fully traceable implementation path that leads back to original requirements, thoughts and specifications.

Once the system passes Plan mode inspection, it is generaly time for human user testing. Fixes can then be captured, diagnosed and remediation plans created in .fixes.

This could easily scale to reference tickets in external tracking systems.

An LLM could reconstruct the entire codebase creation graph from this information. It certainly makes it possible to understand the why behind the implementation. Everything is in the repo.

I think this offers greater traceability then most human structured projects and demonstrates that vibe-coding is not the only way to employ LLM in software construction - and you don’t need an elaborate or expensive framework.

The plan documents are all written in markdown and are human readable, and editable. This can be handy if you want to make slight alterations to the design without involving the LLM.

Generally, most of the heavy lifting is left to the agent in Plan mode. Problems or feature requirements are described as accurately as possible, with examples, in a conversational style and the detailed code structure and application architecture are left largely in the hands of the LLM, with some oversight and quality control. The speed at which solutions form is beyond anything human teams can approach.

It feels very much like playing the role of a software architect managing a team of senior and experienced developers, but at hyperspeed.

So far, it has been a productive workflow, with room to grow… and it seems as though it could scale to multiple agents working in parallel.

Perhaps that comes next…