This document turns the broad IDKMesh vision into a concrete hierarchy of goals. The project is intentionally uncertain about its final product, but it should not be uncertain about what it is trying to learn and enable.
Build an open collective software-engineering system in which large numbers of humans, AI agents, and heterogeneous computers can collaborate on useful projects and produce verified useful work that improves as participation grows.
The project should eventually scale conceptually from one laptop to very large distributed communities without requiring every participant to share the exact same model, hardware, skill level, or interpretation of the goal.
IDKMesh exists to discover and implement the coordination rules that can transform many imperfect contributors into a reliable collective engineering system.
A working relationship is:
collective value = f(competence, diversity, independence, verification, specialization, coordination)
The project must experimentally determine how each term matters and where scaling breaks down.
Design and test mechanisms under which many smaller or heterogeneous coding agents can collectively match or exceed a stronger single-agent baseline on real software-engineering tasks.
This includes:
Key question: When does adding more workers produce more verified value rather than more noise?
Allow a project to progress even when the final target is not fully specified and different contributors understand the objective differently.
IDKMesh should represent:
The system should turn disagreement into structured exploration rather than forcing premature consensus.
Create a portable worker protocol in which laptops, workstations, servers, GPUs, humans, and AI agents can accept bounded Work Units and return verifiable artifacts.
Suitable early Work Units include:
The initial architecture should favor asynchronous, weakly coupled work rather than attempting to emulate one tightly coupled supercomputer.
The network must not trust output simply because it came from a capable model, experienced developer, or highly rated participant.
Verification should combine, where appropriate:
Enterprise quality should emerge from the validation and integration process, not from assuming every contributor is enterprise-grade.
Build a community in which newcomers, researchers, professional engineers, domain experts, AI-agent operators, and compute donors can all contribute meaningfully.
The project should support a progression such as:
observer -> reproducer -> contributor -> reviewer -> maintainer -> subsystem steward
Recognition should reward durable value such as bugs found, regressions prevented, experiments reproduced, reviews performed, security issues discovered, and long-lived improvements—not only commit count.
IDKMesh should not depend permanently on one coding model, vendor, forge, or hardware architecture.
GitHub is currently the public front door and canonical project record, but the underlying Work Unit, provenance, verification, scheduling, and reputation protocols should eventually be portable across GitHub, GitLab, self-hosted forges, and decentralized transports.
IDKMesh should produce reusable scientific knowledge, not only software.
Important research outputs include:
The current leading system-level metric is:
Verified useful work per unit of human attention and compute.
No single scalar is sufficient for the whole project, so this KPI must be accompanied by a multi-objective scorecard including:
IDKMesh should not claim success at planetary scale before succeeding at small scale.
A coordinator can assign the same bounded repository task to multiple local workers, isolate their changes, evaluate them, and select or reject results reproducibly.
A small heterogeneous network completes real Work Units and demonstrates measurable gains—or clearly measured failure modes—relative to a single-agent baseline.
The project can accept work from a larger community while preserving provenance, security boundaries, review quality, and understandable governance.
Scheduling, state management, verification, and community governance remain functional without requiring one central human to understand or approve every contribution.
The architecture can federate or decentralize major functions while maintaining useful quality, security, incentives, and interoperability.
The first implementation is not trying to:
The first claim we should attempt to test is:
For at least some repository-level software tasks, a coordinated set of heterogeneous smaller coding agents using independent generation, testing, criticism, and selection can achieve a higher rate of accepted regression-free changes per unit of human attention than a single-agent baseline.
If experiments reject this claim, that result is valuable and should change the architecture.