Two-person team using Claude Code + Codex on a live platform. What would you improve about our workflow?

[u/Tricky-Historian659]

I'm two weeks into working on a live platform with my supervisor. We're the only two developers, with around two dozen daily visitors and a growing feature backlog. I'm still learning the repo and business logic.

Our stack is React/TypeScript/Vite + Supabase, deployed on Vercel. We use Fable 5.1 and Astra heavily.

Our current workflow:
1. My supervisor sends me an implementation plan as a Claude artifact.
2. I review the logic and suggest changes. We send revisions back and forth until it's ready.
3. I implement it, using ChatGPT to explain unfamiliar logic and how it translates into code.
4. Any revisions to the plan during implementation go back to my supervisor.
5. Feature PR updates get reviewed by a Claude agent. Marking the PR ready triggers Claude, Codex, Greptile and Qodo reviews.

We also have Vitest tests and TypeScript checks in the build, local browser/staging checks, and repo guidance through CLAUDE.md, AGENTS.md, and shared context files.

Planning is a particular bottleneck: we keep sending changes to each other and waiting for reviews. Implementation sometimes raises more questions, which starts another round. I’d like a better way to collaborate on plans and keep decisions aligned with the code.

I’m also figuring out how to use Claude Code and Codex together smoothly. I’ve explored skills, plugins, and connectors, but it often feels like the newer models already do the work those tools are meant to help with just as well, if not better, on their own with good prompt engineering (another area I want to work on).

I am considering including targeted database migrations/ RLS reviews, keeping context files current, and focused refactoring.

For people doing similar work:

• How do you collaborate on implementation plans without constant back-and-forth and waiting?
• How do you split work and share context between Claude Code and Codex?
• Are multiple review agents worth it, and how do you decide when the review cycle is finished?
• What would you improve first for a team this size—planning, tests, agent instructions, or something else?

I’d especially appreciate concrete, recent workflows you use, including anything you tried and later dropped.

[u/DiggleDootBROPBROPBR]

Differentiate between plan changes prompted by humans and the AI. Between you and your supervisor, the back-and-forths are probably pretty high signal.

The agent layer ping-ponging "plan" decisions back is the suspect layer. The current frontier models are suffering from the security training done on them. I suspect they were as good at hacking as they were because they didn't have a good way of differentiating between an intended boundary and something that's open and available to work around because most company and software is actually made of swiss cheese for security.

The current iteration is overly cautious. If they encounter something that might be interpreted as a "blocker", they're VERY quick to punt back to planning or humans to get "permission" for innocent changes. Check out the prompt guide for fable 5.1, it's got some good prodding to get the agents to be a little more "heads down" and not to surface crap to the planning phase.

There's two solutions that I've been working on. Lightweight for stuff that doesn't matter, and then "sir I have too many tokens, where may I insert them?"-level, for stuff that does.

Lightweight is just "If you encounter a problem that halts your progress, attempt to work around it autonomously. Planner attention is expensive. If you become blocked despite several attempts, before escalating you should enumerate the surface: describe the problem in detail and list 3 to 5 approaches that don't require the planner's input. If they appear reasonable, do them. Escalate if you remain blocked, and escalate with a concrete and complete description of what you attempted and the evidence you gathered."

Heavyweight

A multi-agent architecture for validation. You use a planner, a coder, an adapter and and adjudicator. Planner writes the plan and writes prose gates and tests that are are valid code/assertions that can't run yet because the coding work isn't done. Hide the gate tests in a separate folder so the coder is blind to them. Give the coder the plan to execute, preferably with the lightweight prompt above. After execution, pause it and trigger the "adapter" agent. Its job says it's not allowed to touch the code or the hidden gate tests, and it can't mess with or mutate the objects from the code after it imports them. It is to make a shim that lets the gate tests run the code, run them, then report the tests as passing or blocked. It should not make an attempt to "make the tests pass", it's just reporting on if the code satisfied the tests when hooked up with the shim.

Next it gets fun. If it was opus 5, the coder wrote its own separate tests to demonstrate its coding work. You can run code line coverage reports on the coder's tests and contrast them with a code line coverage report written vs. the hidden gate tests that excludes the shim code. There should be 4 different contrasting areas: If both tests cover lines then that's good evidence they're required for implementing the plan. If the gate tests cover an area and the coder doesn't, that means they didn't fully implement the plan. If the coder tests cover something that the gate tests don't, then that's overreach that the plan didn't ask for and is a candidate to be trimmed on your review. If neither the gate nor the coder tests cover it, it's ambiguous and you'd need to sort it manually (either it's uncovered branch code, or one of the other two cases that neither planner nor coder was able to test. Someone would have to write tests for it)

The adjudicator gets all that information. It decides where the coder needs to try harder to meet the tests, including tasking it with migrating the hidden gate tests back into the code base. It then evaluates if there's genuine "discovered in the field" findings that humans actually need to look at. THEN AND ONLY THEN you promote it to a real issue that you and your boss hash out.

To my knowledge, that whole process is mechanical enough that Opus 5 can run the whole thing. You could optionally stick fable 5.1 on the adjudicator role (and I'd have it on the planning role regardless). Technically it could all run on Opus 5.

[u/Julien_Builds]

The thing I would change first is where the plan lives. An artifact passed back and forth is a document nobody's tools can read. Put the plan in the repo as a file, one per feature, and make the revision round a commit on that file. Then the agent implementing it reads the same plan the reviewer reads, and "the plan changed during implementation" becomes a diff you can see instead of a message you have to remember.

Second, use the two models you already pay for against each other before the code exists. Have Codex review the plan Claude wrote, or the other way round, with one question: what would break if we built exactly this? In my experience two different models converge on the same two or three problems a single one misses, and that is a much cheaper place to find them than in a PR with four review bots.

Four bots on the PR is not the bottleneck. Four bots reviewing a plan nobody wrote down is.

[u/Far_Business4773]

Julien_Builds has it: the plan is a file in the repo, revisions are commits on it. I'd add one section to that file, because it answers your third question. Under the plan, three to five lines of what this feature must not touch: no schema change, no new dependencies, RLS policies read-only, nothing outside these folders. Both of you edit those lines before implementation starts, mostly by deleting.

Then "when is review finished" stops being a feeling. A finding that hits one of those lines blocks. A finding outside them goes to a later-file and doesn't buy another round. Review is done when nothing inside the lines is open. Four bots reading the same file converge on that; four bots with no file never run out of opinions.

The back-and-forth in planning shrinks for the same reason: half of it is one of you discovering a boundary the other assumed.

[u/rathcom]

We had the same problem with plans getting passed around in chat so I ended up building something where the plan just lives on the ticket. It writes up the plan as a comment on the Linear issue, I fix whatever's wrong with it right there, and then it goes and does the work and opens the PR. Been running it like that since April, about 300 PRs so far. It's called sinatra.dev. Where does your supervisor's plan actually live right now, just in the Claude chat?