I built a production system through months of synthesis coding — sustained, context-rich collaboration with Claude Code. The codebase had deep architectural consistency because one person held all the context. Then a colleague started contributing features on branches.
Their code was good. The features were real. But when I looked at the PRs, I realized I couldn’t just merge them. The codebase had moved. Patterns had evolved. Security safeguards had been added. Conventions existed that weren’t written down anywhere because I’d been the only one writing code. A standard merge would have regressed things I’d spent weeks getting right.
This is the multi-contributor problem in synthesis coding, and I’ve written a runbook for how to solve it.
Why standard merges don’t work
In synthesis coding, the lead developer — the “lead synthesist” — builds and evolves the system through continuous AI collaboration. The result is a codebase with properties that make standard merge workflows dangerous:
Deep architectural consistency. Decisions compound across sessions. The AI assistant carries context about why things are structured a certain way, and the lead synthesist’s judgment shapes every choice. The codebase isn’t just functional — it’s coherent.
Implicit conventions. Not all standards are documented because one person held them all. Naming patterns, error handling approaches, security practices, the way components compose — these emerged through the work, not through a style guide.
Rapid evolution. AI-accelerated development means the codebase moves fast. A branch that’s a week old may be dozens of commits behind. The contributor built against a snapshot of a system that no longer exists in that form.
When someone branches off and builds a feature, they’re working against that snapshot. Meanwhile, the lead may have introduced new patterns, added security layers, refactored subsystems, or raised the quality bar. A blind merge risks regression — undoing improvements. It risks inconsistency — introducing patterns that conflict with evolved conventions. It risks security gaps — missing safeguards added after the contributor branched.
The standard open source answer — “submit a PR, we’ll merge it” — doesn’t account for this.
Adopt-and-adapt: the integration pattern
The solution is neither a merge nor a rewrite. It’s selective integration with improvement.
- Adopt the intent, the design, and the valuable implementation work
- Adapt the code to meet current standards, architecture, and quality bar
The contributor’s work is the foundation. The lead synthesist brings it up to production standard. This respects the contributor’s effort — their design thinking, feature concept, and implementation are preserved. But it maintains the quality and consistency that synthesis coding produces.
Practically, this means: create a fresh branch off current main. Selectively bring in changes file by file, function by function. Fix identified issues during integration, not after. Test the integrated result. Then merge to the canonical main.
The lead synthesist never merges the contributor’s branch directly. They adopt the intent and adapt the execution.
Roles matter
Lead synthesist
The person who holds the architectural vision, maintains the quality bar, and has the deepest context on the system. In a synthesis-coded project, this is the person who built the system through sustained AI collaboration.
They define and evolve project standards. They review all external contributions. They perform adopt-and-adapt integration. They control production deployments. And critically — they document standards as those standards emerge through the integration process.
The lead synthesist’s standards ARE the project’s standards. Integration is the forcing function that makes those standards explicit.
Contributors
Developers who build features on branches or forks. They may or may not use synthesis coding themselves.
Their goal is to make integration easy. The closer a contribution is to the project’s standards, the less adaptation is needed. This means: read the contributor guide before building. Sync to latest main. Submit complete features — both frontend and backend, with tests. One feature per branch.
The full integration process
When the lead synthesist receives a contribution:
Assess. Fetch the branch and review the diff. Identify what the contribution does, what it changes, what assumptions it makes. Check how far main has moved since the contributor branched. Check whether the contribution touches sensitive areas — auth, security, data model, user-facing text.
Review. Evaluate against quality gates. Produce written feedback covering what’s strong (acknowledge good work — contributors who feel respected produce better work), what must change (security issues, broken functionality, standards violations — be specific), and what should change (code quality improvements, architectural suggestions — distinguish “must fix” from “should fix”).
Integrate. Create a fresh branch off current main. Selectively bring in changes. Fix issues during integration — don’t merge first and fix later. Test the integrated result. Merge to canonical main. Sync mirrors and forks so contributors have the latest code.
Communicate. Share the integration review with the contributor. Explain what was changed and why. This is how standards transfer. Note lessons that should update the contributor guide to prevent recurrence.
Quality gates
Every contribution must pass four gates before integration:
Completeness. Feature is fully implemented — not half-frontend, half-backend. No dead code, no references to methods that don’t exist, no dependency on unreleased work. Tests exist for new backend logic.
Security. Privileged operations produce audit log entries. Auth tokens are handled correctly. Rate limiting on sensitive endpoints. No hardcoded credentials. Input validation at system boundaries.
Architecture. One feature per branch. Follows existing codebase patterns. Uses framework features properly — not fighting the framework with workarounds. No regression of existing functionality.
Project-specific standards. These vary — brand compliance, UI terminology rules, deployment safety, database migration approach, performance expectations. The contributor guide should document these. If a standard isn’t documented and a contributor violates it, that’s the lead’s responsibility to document it, not the contributor’s fault.
Lessons from the first integration
Several patterns emerged that are worth naming.
The blind merge is the primary anti-pattern. Merging a contribution without reviewing it against current standards. Even if CI passes, the code may introduce conflicting patterns, miss security requirements, or regress quality. Every external contribution goes through adopt-and-adapt. No exceptions.
Bundled features create unnecessary pain. Multiple unrelated features in a single branch make review harder, create merge conflicts, and mean you can’t accept feature A without also accepting unfinished feature B. One feature per branch — enforce it as a contribution requirement.
Orphaned half-features are dead code waiting to confuse someone. Frontend code that calls backend endpoints that don’t exist ships dead code that misleads future readers. Require complete features — both sides of the stack, tested together.
Integration is when standards get documented. The act of reviewing external contributions forces the lead synthesist to make implicit standards explicit. Every integration review should leave the contributor guide more comprehensive than before. The contributor guide is a living document — it grows with every integration.
Auto-deploy without approval removes the quality gate. CI/CD pipelines that deploy to production on push to main with no manual approval gate remove the lead’s control over production. Production deploys always require explicit human approval.
The runbook
I’ve published the full methodology as an open-source runbook: Multi-contributor Synthesis Coding
It covers everything in this article plus the detailed contribution workflow (before building, while building, submitting), communication principles for productive review feedback, and guidance for applying the pattern to new projects. MIT licensed, part of the Ragbot.AI open-source project.
If you’re synthesis coding solo today but expect to involve contributors in the future — read it before the first PR arrives. The precedent you set with the first contribution defines the culture.
This article is part of the synthesis coding series.
Rajiv Pant is President of Flatiron Software and Snapshot AI, where he leads organizational growth and AI innovation. He is former Chief Product & Technology Officer at The Wall Street Journal, The New York Times, and Hearst Magazines. Earlier in his career, he headed technology for Condé Nast’s brands including Reddit. Rajiv coined the terms “synthesis engineering” and “synthesis coding” to describe the systematic integration of human expertise with AI capabilities in professional software development. Connect with him on LinkedIn or read more at rajiv.com.