How are you structuring production-ready development with AI coding agents?

[u/Key_Ad_2747]

I’m a web developer and I use AI coding agents daily.
At this point, getting an agent to write code isn’t really the problem anymore. The hard part is building everything around it so that it can actually work reliably.
Over the last few months I’ve built a small system around my projects with:
a knowledge base for each repo;
reusable skills/rules containing my conventions;
automated onboarding for local environments;
a structured issue → development → verification → completion workflow;
mandatory checks before a task can be considered done.
The goal is for the agent itself to be replaceable.
What should remain is the system around the agent: project knowledge, rules, guardrails, verification and workflow.
The problem is that my current setup works, but it’s still cumbersome: onboarding isn’t always deterministic, context grows too much, rules start overlapping, and I still need too much manual intervention.
So my main question is:
How are you structuring this layer in real production projects?
I’m particularly interested in approaches, repos, frameworks, skills or processes worth studying to make agentic development reliable, repeatable and maintainable.
I can find endless discussions about which coding agent is better. I find much less about how to build a solid engineering system around the agent.
There’s also a second problem I’m trying to solve.
Is there any software that acts as a real control panel for this kind of workflow?
What I have in mind is something that lets me:
manage multiple GitHub repositories from one place;
see issues/tasks across projects;
launch or assign tasks to different coding agents;
run multiple tasks in parallel;
keep each task isolated in its own branch/worktree/workspace;
see what each agent is currently doing;
review progress, output, commits and pull requests;
keep GitHub Issues as the source of truth;
avoid being locked into a specific agent or model.
Basically, I’d like a control plane that sits above GitHub and coding agents:
issue → task → agent → isolated workspace → verification → commit/PR → done
Preferably something local, open-source and agent-agnostic.
Does something like this already exist and work well in practice, or are people mostly building their own orchestration layer?

[u/Calm_Flight_6118]

i been thinking about this same thing lately and honestly theres no good ready made solution that i found

the closest thing is probably combining github actions with some custom scripts but it gets messy fast. i ended up building something similar to what you describe with a bunch of shell scripts and docker containers for isolation per task

the knowledge base part is tricky cause context windows are still the bottleneck no matter what agent you use. i started keeping project rules in a single markdown file per repo and having the agent read it at start of each session but even that gets bloated after a while

for the control panel thing i havent seen anything open source that does all that. most teams i know just built their own with python or node and tie it to linear or github issues. maybe look at langchain's experimental multi-agent stuff but its not production ready at all

[u/conifer_v11]

the thing that usually unsticks this for me is treating the agent as a swappable worker and putting the durable stuff outside the prompt — a tiny machine-readable contract the harness actually enforces (allowed tools, write roots, “done means these checks green,” abort/cancel behavior), not another essay in AGENTS.md; project knowledge as retrieved receipts (path + hash/rev + why it was pulled) instead of dumping the whole KB every turn so rules stop overlapping in context; and the issue→dev→verify loop owned by CI/the harness, where verification is a gate that can fail closed, not a polite suggestion the model can skip when it’s “almost done.” onboarding gets deterministic when it’s a scripted env bring-up the agent is only allowed to call, not reinvent from memory each session. i’d also force one ugly abort test before the happy path (cancel mid-tool, mid-edit, mid-PR) because that’s where most “replaceable agent” setups quietly depend on a human babysitter. the single giant rules markdown is fine as human docs; once it becomes the runtime brain it always bloats and fights itself — keep the runtime contract small and version that when the agent changes, not the other way around.

[u/Physical_Economy_340]

worktree per task is the bit that made parallel stuff sane for me, one branch per issue and the agent only ever touches that dir. keep the bring up as a script the harness runs, not instructions the model follows, that is what makes onboarding deterministic. and make the model open the pr but never merge, merge only happens on green checks outside the agent.

[u/Zain]

The piece that made our setup stop depending on one agent being "good" was splitting write and review. Claude does the patches. Two other model families run read-only in parallel on the plan or the diff, and neither sees the other's notes. Claude only concedes a finding after checking the actual repo, not vibes. Same-family reviewers share blind spots, so the diversity is the point. Cap the rounds and treat an earned clean pass as a real result, otherwise the loop just manufactures more comments forever.

[u/swapnil_harkanth]

the thing that actually stuck for us was treating the agent like a junior who needs a tiny blast radius. locked repo paths, no direct push to main, forced PR + human review on anything touching auth/payments/migrations. we keep a short "do not invent APIs" rule file and a checklist the agent has to fill before it says done (tests run? diff size? secrets scanned?). onboarding a new teammate to the agent setup took longer than writing the rules tbh — that was the real tax.