My Development Workflow

My development workflow at EdgeXene brings together five AI models: Claude, Codex, Qwen, Kimi, and DeepSeek. Each contributes differently, but their work follows one coordinated process. Claude acts as project manager and primary developer, bringing in other models when they have a specific contribution to make.

I set the direction: what I want to build, how it should behave, and where the boundaries lie. Claude turns that brief into an implementation plan, coordinates contributions, and handles integration and release. The other models work on defined assignments and return their findings or proposed changes for verification.

The difficult part is deciding which answers deserve to become code. A convincing explanation can describe a bug that does not exist. A fix can introduce another defect. A passing test can fail to check anything meaningful. More models give me more opportunities to catch those problems, provided their work is checked against the actual software.

That need for verification has shaped the workflow. I designed the division of responsibilities deliberately. Many of the controls came later, after a failure showed me what was missing.

I use this workflow to build PATANYX, my privacy browser. Why I built it, and how, is in my article Building PATANYX.

Before any code is written, I work through what the project needs to do and how I expect it to behave. AI helps with the research: comparing approaches, identifying tradeoffs, and testing assumptions about the languages and technology stacks I am considering. I assess the findings and decide what fits, including which suggestions to leave out.

My aim is to give Claude a detailed, useful brief: the intended outcome, relevant context, constraints, expected behavior, and what falls outside the task. A suggestion worth exploring later is not permission to implement it now. I also maintain a dedicated task list for each project and development phase, keeping the broader objective visible as the work is broken into smaller assignments.

That preparation takes time, but it helps keep implementation aligned with what I asked for. Claude has room to work through technical details within the brief; expanding the scope still requires my direction. Detailed instructions cannot prevent every misunderstanding, so review and verification continue throughout the process.

Claude's project management instructions begin with a practical rule: if Claude is best suited to the task, Claude should do it. It remains responsible for delivering the work. Delegation needs a reason.

That responsibility covers planning, development, verification, and integration. Other models receive a defined brief and return their work. They do not communicate directly with one another. If one model needs another's findings -- for example, when Codex assesses conflicting reports -- Claude passes them on deliberately. It coordinates those handoffs and resolves disagreements by checking the code.

Codex, Qwen, and DeepSeek can receive explicit permission to make changes in designated scratch copies of a project. This lets a reviewer propose a fix while the relevant code is still in context. Claude then reproduces the issue, tests the proposed correction, and decides what to integrate. That permission excludes credentials, the infrastructure running the workflow, and live application files. Kimi works through its API and sees only the project material Claude includes in the request.

Every model that commits work follows the same handoff routine. It commits on its own branch, subject to a pre-commit audit. If the audit blocks a commit, the model must resolve the issue; it may not bypass the check. Each commit is announced as it happens and recorded on the audit card under the model that produced it.

Changes touching privacy, consent, uploads, or public claims require a different handoff. The contributing model stops before committing and passes the work to Claude for the required review.

The coordinating Claude session is the only model session designated to commit integrated changes, push them, and deploy. I remain responsible for the direction of the work and the rules governing it.

The publishing rule has a limit. The other models work in restricted sandboxes or through API requests that give them no publishing access, but that protection depends on how each run is set up, not on separate server accounts. Beyond that, the rule depends on instructions, checks, and an audit trail. Giving each model a separate server account, with publishing permission reserved for the coordinating Claude session, would let the server enforce that boundary directly.

I bring in another model when it adds capacity, provides a fresh review, or challenges a conclusion worth testing. The roles below reflect what has proved useful in my workflow.

Access matters as much as the assignment. A model receiving only the text of an API request cannot inspect a repository it has not been given. I learned that after a session in which a model tried to compensate for missing repository access with web searches. The assignment required capabilities that the chosen access method did not provide.

Before using a model for the first time, the workflow checks its availability with a real test call. Published model lists and accepted identifiers have not always matched in this setup. Assignment decisions also draw on a record of actual results, tracking whether a model's output was usable separately from whether the model was available at all. That record reflects my own tasks and setup; it is not a benchmark comparing the models.

The rule requiring a reason for delegation came from a particularly unproductive session: four delegated requests produced nothing useful, while Claude's direct measurements of the running system produced the answers that mattered.

A reviewer needs access to the evidence behind a claim. Without it, the reviewer can assess only the description it was given.

The project's shared working memory runs as a local service. It holds nearly 400 notes covering decisions, corrections, constraints, and the reasons behind them, organized under a numbered table of contents with a chapter for each project.

Claude and Codex read the store directly. Qwen and DeepSeek can also read it when running inside the sandbox, and every run dispatched through Hermes has access. Plain drafting requests to Qwen or Kimi include the table of contents and index by default. If the model needs a particular page, it names it and Claude supplies it.

Models with access can list, read, and search the notes, and propose corrections. Each proposal must explain what changed and why. The system records the channel it arrived through, which the model cannot choose, along with the model's name when its launcher provides one. Claude reviews the proposals and publishes those that hold up. The store has many readers and one designated writer.

I built this arrangement after a day when Claude made four incorrect claims. One came from a stale record; the other three came from misreading correct records. Three of those claims reached Codex in review briefs, but those review sessions had no access to the project. Codex was assessing a summary without the evidence needed to challenge it.

Two layers help keep secrets out of shared memory. The first is a rule that credentials never go into notes. The second is a filter that redacts text resembling a secret before serving it to a model. The filter is deliberately conservative and can hide ordinary text too. When that happens, the model must report the redaction rather than guess what was hidden.

Security findings begin as hypotheses. A reviewer may identify something worth investigating, but the claim must hold up against the actual implementation.

1. Find. One model investigates, or two work independently from the same brief without seeing each other's conclusions.
2. Reproduce. Claude investigates the findings against the actual code and establishes which issues are real.
3. Fix. Corrections are developed in a scratch copy, including by the model that identified the issue.
4. Integrate and test. Claude incorporates accepted changes and runs the relevant checks.
5. Verify. The corrected code receives a fresh review, including scrutiny of the fixes themselves.

Keeping initial reports separate reduces the chance that one reviewer adopts another's reasoning. Agreement can help prioritize an investigation; it cannot establish that a finding is correct. Independence also has limits. Qwen and DeepSeek produce separate assessments through a shared provider connection. Their conclusions are developed separately, but their access path is shared. Kimi or Codex adds another provider path.

For changes that follow the full review sequence, Claude implements, a security review runs when required by the plan, Qwen reviews next, and Codex reads last. Claude then reproduces the reported issues and integrates the accepted changes. A model's review of its own work does not count as the independent review.

My defensive security work uses access through Claude's Cyber Verification Program and Codex Daybreak Blue. It is limited to software I own or have permission to test. If the scope is uncertain, the workflow pauses for clarification. A refused review is recorded as a refusal. Calling it "no findings" would imply that a review took place.

Verification has proved especially valuable. In one sequence, a review identified five problems; a subsequent review found four more in the fixes. Each round examines the corrected code afresh, and the process continues until a round reports no further findings. Corrections are also checked against the versions they replace to establish whether they change the relevant behavior. A clean review provides evidence about the scope examined, not proof that the whole application is free of defects.

Some changes automatically trigger additional review based on the files they touch: upload handlers, age or identity checks, retention, consent versions, privacy and legal pages, and landing pages. Changes to location handling or the addition of a third party to the request path require the same review by rule.

The reviewer works read-only against standing requirements. It records a pass, failure, or not-applicable result for each check, cites the file and line for failures, and proposes wording where my approval is required. Any subsequent edit needs another review. The controls described below track whether that review actually happened.

A close call showed me why this review must extend beyond the repository. A draft privacy policy described two protections that had been implemented, committed, and tested, but were missing from the signed application users had downloaded. Searching the source code would have supported the claims. Inspecting the released application caught the mismatch before the policy took effect.

For downloadable software, the review checks the build users actually receive. Implementation, testing, and release are separate events. Public claims have to match what has shipped.

Two consecutive review rounds exposed weaknesses in tests written to validate Claude's fixes. The first test searched the program's output for a phrase, so merely echoing the input could satisfy it. It also mishandled crashes, allowing a crash with no output to pass.

The second tested a copy of the application logic pasted into the test file. Twice, deliberately breaking the real implementation still produced the same result: seven tests passed, zero failed.

Both results had already been presented as evidence that the fixes worked. The workflow had accepted evidence that did not support its conclusion.

The resulting requirements are specific. Tests must exercise the implementation that ships, check a defined result, and account for whether the program completed successfully. When a test needs logic from a shipped file, it loads that logic at runtime instead of maintaining a separate copy. For changes to safety checks, the workflow deliberately breaks the relevant behavior and verifies that the test fails. That provides evidence that the test can detect the defect it is meant to catch.

These lessons changed how I assess a passing test. I want to know what ran, which behavior it exercised, and whether it would notice if that behavior were wrong.

Every session keeps an audit card on disk, updated after each turn. It is assembled from the transcript and execution logs, giving it a basis beyond the model's closing account. Below is a card captured during a session on September 19, 2026, with Codex's exact model version and the ledger line removed.

Task classified: security-sensitive
PM Workflow: armed automatically
Reason: guardrail files touched; credential-handling files touched; independent review ran
FIND seats: none; review: Codex review
Codex policy: read-only / subscription auth
Findings: 17 + 1 run(s) refused
Claude dispositions: accept 5 / reject 2 / defer 1
Tests: 13/14 this session (FAILURES)
Suite stamp: green at 2026-09-19 06:53
Publish gate: not run this session
Gates: compliance-audit: not required; verify-app: not required
Seat record: 5 runs, 5/5 usable
This turn: quiet (no files written, no commands run)

The card records the task classification, participating reviewers, findings, test results, and applicable checks. Findings are marked accepted, rejected, or deferred, with reasons. Publishing activity is attributed to the session that performed it, which matters when several sessions are active at once.

The card lists 17 findings but only eight dispositions. The eight decisions cover four earlier review rounds. Claude accepted all nine findings from the latest review in its reply seconds before this card was written, but never recorded those decisions, so the card could not count them.

This card shows 13 of 14 tests passing in the session's latest run and explicitly flags the failure. A separate line records the most recent successful run of the global test suite. Keeping those entries distinct prevents a general status indicator from being mistaken for evidence that the current task passed.

The audit card does not block a release. It provides traceability: what was attempted, what evidence was produced, what was decided, and which checks remain incomplete. Its entries feed a ledger whose records are chained together so changes disrupt the chain. Once a day's entries are anchored, a later rewrite can be detected.

The workflow is documented through skills: folders containing instructions, supporting references, and scripts where needed. Each begins with a short description that helps the coordinating model decide when to use it; detailed instructions are loaded as needed. A deployment skill can stay short by pointing to a separate recipe for each application. A drafting skill needs more explanation because it covers several roles, access methods, and review sequences.

Small programs support those instructions at three points: before tools execute, after files change, and when a model is about to end its turn. Before execution, guards check for conflicts with other active sessions. After an edit, the workflow classifies the affected files and identifies the checks that apply.

At the end of a turn, three gates request evidence. A user-interface change requires loading the page in a real browser and inspecting a screenshot. A change to a security boundary or release artifact requires an independent review saved with a verdict and numbered findings. A compliance-sensitive change requires a compliance review completed after the final edit.

If the evidence is missing, the gate asks for it, and if it still does not arrive, the gap is normally recorded as an unresolved obligation. These gates prompt review and keep a record of what was skipped; they do not technically block publication. Saying a review happened is not enough.

The controls can produce false positives. In one session, two harmless read-only commands were blocked because their text matched a pattern associated with writing. The response is to investigate the conflict, use an appropriate alternative, or coordinate with the session holding the file. Rephrasing a command solely to evade the guard would defeat its purpose.

Shared memory needs maintenance too. A store that every model trusts can give outdated information undeserved authority. One note's summary said Claude was the only writer, while its body already described other models' permission to write in scratch directories. The detailed record was current, but the summary used to find and interpret it was wrong. That contradiction circulated for a week.

A script now checks for this kind of mismatch whenever a note is written. Early versions were too broad: one flagged 97 of 335 notes, and a narrower version still flagged 37. Requiring the summary and correction to concern the same subject reduced the results to 10.

A regular maintenance pass proposes consolidating notes that have grown or overlap, and a periodic review identifies records that no longer match the system. Both produce proposals or reports; Claude reviews them and applies the changes that hold up.

Lessons from development and review follow their own process.

Another model's finding begins as a candidate until Claude verifies it. Informal observations require three comparable cases across two sessions. Only lessons marked confirmed or enforced are recalled as established guidance. Retrospectives can propose candidates, and periodic reviews can report inconsistencies, but neither can rewrite the workflow's rules without supervision.

Hermes is an agent framework from Nous Research. In my setup, it provides the shared task board and runs Codex and Qwen assignments through its own agent, using the assigned model. Qwen tasks use its larger model. Claude assignments bypass the Hermes agent and run in Claude Code through my subscription.

A task begins as a line in the task list naming a model and an instruction. A planning pass turns it into a board item; a dispatch pass sends ready items to their assigned models one at a time. Both run only when a Claude session has been active recently, so the board does not pick up work on an idle machine.

Failed runs are retried after a pause, with limits on retries and run time, so a stuck task cannot loop indefinitely. The board's built-in dispatcher remains disabled so every dispatched run uses the sandbox.

Each run uses the same sandbox setup as the Qwen runs, with its own working copy and profile. It cannot see other models' profiles. It works against a clone of the PATANYX release repository and follows the same handoff rules: commit on its own branch after the pre-commit audit, announce the commit, and return the work to the coordinating Claude session.

Those rules also apply to dispatched Claude runs, which are separate workers. Hermes keeps no memory of its own; its workers read the shared store, starting with the table of contents.

Outside the task flow, a lighter Qwen model runs two regular maintenance passes. One reads recent learning signals and proposes lessons. The other proposes consolidating memory notes. Neither applies its own proposals.

Release remains with the coordinating Claude session. The harness has a single guarded release step, and today that step is simulated: it does not merge or publish anything. Claude handles merging and publishing outside it.

My involvement continues throughout development. I check changes against the intended behavior and revisit completed work after significant changes because a correction in one area can affect something that appeared finished. The task lists and original brief give those reviews a consistent point of reference.

The models bring different approaches to implementation and review. The workflow gives me a way to evaluate their contributions against code, tests, and released builds. I remain responsible for the product, its priorities, and the standards governing the work.

When something goes wrong, I want the lesson to change what happens next: a clearer requirement, a better test, or a control that catches the problem if it returns. That is how I keep improving both the software and the way I build it.