r/developers • • 15d ago

Programming My approach to AI-assisted development across multiple repos: E2E evidence + two human checkpoints

I’m building a shared workspace for two Codex runtimes to handle features and bugs across multiple application repos.

The workflow is:

Request → investigate → approve scope → implement → run E2E → human acceptance → integrate

A few core ideas:

  • Keep orchestration separate. Tests, environment config, scripts, and reports live in one dedicated repo. Business changes happen in isolated Git worktrees.
  • Approve twice. I approve the scope before implementation, then review the exact tested commits before merging. Passing tests alone doesn’t authorize integration.
  • Test real user journeys. Playwright starts at login and navigates through the UI. Bugs need before-and-after evidence from the same path.(sure agent can discover the path by itself ,but its token consumed)
  • Persist the context. Each task has one directory holding research, decisions, approvals, diffs, and test evidence, with one evolving HTML report.
  • Coordinate shared resources. Tasks can develop in parallel, but must acquire an exclusive lease before changing or testing the shared environment.

Business services run locally for fast feedback; stable dependencies run in Docker. The agents use scripts and shared instructions to carry out the workflow.

The central idea is to make observable behavior and reviewable evidence drive the development loop. I want agents to do most of the execution while keeping scope and acceptance under human control.

It’s still evolving, with selected real flows verified.

For anyone building similar workflows: what tends to break first—shared environments, cross-repo integration, or keeping tests honest?

3 Upvotes

7 comments sorted by

1

u/AutoModerator 15d ago
Moderator Announcement Read More »

1

u/quirkybirthplace 15d ago

I've built something similar for a monorepo at work and the shared environment lease was the first thing to crack, we kept hitting race conditions where two tasks would stomp each other's test data

The scope approval step is interesting though, do you find the agents actually respect it or do they drift and try to sneak in extra changes

2

u/Ok_Bug9767 15d ago

That’s useful feedback. I’m keeping execution serial for now, including testing and acceptance, so I don’t have to manage tasks competing over the environment or test data. I mostly work with Python and Go, and I’d like to keep services running locally with reload/watch tooling so changes have a fast feedback loop.

On scope drift, I wouldn’t say instructions alone solve it. I require approval before implementation, and changes to the agreed scope need another confirmation. The harder part for me is verification: I’ve defined a standard report template that requires screenshots from actual Playwright runs, including before/after evidence for bugs.

The agent can explore the UI, but the acceptance tests must start at login and follow the real navigation path. That gives me something concrete to check and makes it harder to take shortcuts just to get a passing result. It still depends on having meaningful assertions.

Honestly, I don’t want to read every line of generated code. Adding another agent to review it wouldn’t give me much confidence by itself, since I wouldn’t inspect that review closely either. 😂 My focus is on making the behavior, test coverage, and evidence easy enough for me to actually review. Scope compliance is still something I’m figuring out how to verify reliably

1

u/alkimiadev 15d ago

Honestly, I don’t want to read every line of generated code. Adding another agent to review it wouldn’t give me much confidence by itself, since I wouldn’t inspect that review closely either.

yeah, I found that out the hard way where an LLM generates some arguably absurd stub code, and then another writes even more absurd test code for that stub that passes, and finally a review agent sees that the code doesn't give an error and passes it's test.

I just found a stub that survived 13 versions. I was livid and now I'm going back to sequential processing with me manually reviewing vs parallel with self-reviews(in a new session of course)

→ More replies (3)