Date: 2026-08-28
This document preserves the useful project content from the IDKMesh discussion about coordinating many human “vibe coders”, small coding models, laptops, and distributed agents on one evolving software project.
The project owner proposed a Git-like environment in which many people and laptops, each potentially using different free or local coding models, work on the same project. Small pieces of coding work would be completed independently and then integrated algorithmically into a larger application.
The discussion expanded into these questions:
The central conclusion is that:
100 small coding models do not automatically equal one strong model, and they cannot guarantee quality merely by voting or generating more code.
The potentially useful system is instead:
diversity
+ task decomposition
+ isolated execution
+ independent attempts
+ independent verification
+ selection
+ integration
+ architectural governance
+ durable memory
= potentially stronger collective engineering
The word “potentially” is essential. More agents can also create correlated errors, duplicated effort, inconsistent abstractions, security problems, review overload, integration conflicts, and architectural drift.
A useful conceptual structure is:
Product / research goal
|
v
Planner / decomposition layer
|
v
Task dependency graph
|
+-----+------+-----+
| | |
v v v
worker A worker B worker C
model/human model model
| | |
v v v
isolated Git branches / worktrees
|
v
independent tests + reviewers + security checks
|
v
selection / conflict resolution / integration
|
v
canonical main branch
Workers should receive bounded tasks with explicit allowed files, interfaces, contracts, tests, and acceptance conditions where possible. This reduces the amount of global context required by each small model.
Multiple workers can attempt the same task independently. Candidate solutions can then be evaluated for:
This is closer to competitive search and validation than to simple majority voting.
A large worker population should not necessarily perform identical roles. Candidate roles include:
Worker capability should be measured empirically by domain. A scheduler could learn that one worker is strong in Python debugging but weak in architecture, while another is strong in React or security.
A flat network of thousands of agents is likely to become unmanageable. Hierarchical or modular coordination may be necessary:
project-level coordinator
|
+-----+------+-----+
| | |
backend frontend QA/security leads
| | |
local task teams and workers
The precise hierarchy should remain an experimental question rather than a fixed assumption.
The discussion identified a need for stable architectural constraints that ordinary workers cannot casually modify. Examples include:
The purpose is not bureaucracy for its own sake; it is protection against thousands of locally reasonable changes that are globally incoherent.
The strongest principle from the discussion is:
Never trust an AI agent’s answer because it sounds intelligent. Trust externally verifiable evidence.
Software is unusually suitable for this because important properties can often be tested automatically: compilation, tests, API behavior, static analysis, fuzzing, performance, security scans, compatibility, and reproducibility.
Verification must itself be protected from manipulation. Workers should not be able to rewrite tests or evaluation logic merely to make their own patch pass unless that change is explicitly part of the task and independently reviewed.
A long-term IDKMesh network could resemble volunteer-computing systems:
volunteer laptop joins network
|
announces capabilities
|
receives bounded work unit
|
runs local model / tests / analysis
|
submits patch + evidence
|
independent validators reproduce or challenge result
|
accepted result contributes to canonical project
The network could eventually include heterogeneous participants: local small models, stronger remote models, humans, GPU machines, test runners, and specialized security nodes.
The discussion proposed contribution accounting based on verified usefulness rather than raw activity. Valuable contributions can include:
Reputation should be multidimensional and domain-specific. It should not become a simple popularity score.
The project should separate exploration from authority over the canonical branch. A large population can generate proposals and experiments, but integration should remain gated by tests, maintainers, subsystem ownership, and explicit governance.
Useful patterns include:
IDKMesh should not require universal agreement on a fully specified target. Instead it can maintain several layers:
Different interpretations can sometimes be implemented in parallel and compared rather than resolved entirely through discussion.
The recommendation from this discussion is:
Potentially useful ideas:
Ideas to avoid:
Assume workers can fail, disconnect, disagree, or be malicious. Important work can be replicated and independently validated before a canonical result is accepted.
Match work units to heterogeneous hardware and make joining the network easy. Visible contribution statistics can motivate participation, but technical correctness still requires verification.
Break a large object into independently handled pieces, verify integrity, distribute load, and avoid relying on a single source. IDKMesh can borrow the work-unit and swarm intuition, but software tasks are not interchangeable chunks and need dependency/semantic awareness.
Not every participant must have the same role. Better-connected or more capable nodes can coordinate, relay, validate, or integrate work for lighter nodes.
Scaling code generation without scaling maintainership, ownership, review, testing, and governance will fail. Technical and social architecture must evolve together.
Pieces of the idea exist in modern multi-agent coding systems and agent orchestration projects. Examples discussed include OpenHands-style isolated coding agents, MetaGPT-style software-company roles, and ChatDev-style multi-agent development. The distinct IDKMesh research direction is the combination of:
Do not begin by attempting a thousand-agent enterprise application. First test whether the core premise works.
Compare on the same controlled task set:
Measure:
The final intelligence may not reside in one model. It may emerge from the overall process:
decomposition
-> parallel attempts
-> criticism
-> testing
-> selection
-> integration
-> memory
-> iteration
Under this interpretation, the orchestrator, verification network, governance, and accumulated project memory together form the higher-level collective intelligence.