codev light?

[nharward]

Edit: my points about spheres 3-5 were in fact user error and should have explicitly used the SPIR protocol instead of ASPIR. Original comments below left in place but struck out.

I'm evaluating whether to contribute to codev or build a derivative tool. Before investing effort, I want to gauge whether the community would value the modifications I'm considering.

I've run into a few things that make using codev more difficult than I'd like. The first is expense, the second is codev's workflow assumptions.

Expense: not all enterprise budgets allow $100+/mo per seat to get access to Claude (required) plus Gemini and/or Codex. Free tiers leak IP and have restrictive limits. Multi-model consultation isn't feasible under these conditions.

Workflow: codev assumes GitHub-centric workflows and AFAICT doesn't support spheres 3–5, though that might be user error. There has been work to de-Github--some of it mine--but I learned the past 48 hours it needs more work.

codev needs significant updating if a) not using Github for everything and b) you need to operate in spheres 3 through 5.

Proposed modifications:

0. Develop protocols for users who need or want to operate in spheres 3 through 5. I want to operate in sphere 6 generally, but for certain cases I need to manually review plans and code where the AIs either do a poor job or I don't have multi-model consultation available.
0. Dive deeper to make codev as agnostic to different tools as possible. My initial contribution and reported issues seemed solid until I tried to use them with a repo in codeberg.org. I discovered numerous bugs, hidden gh usage in protocol files, etc. Getting this right will require significant cycles and careful consideration.
0. In a single-agent system (Claude only) experiment with ways to try to approximate multi-agent consulting. Perhaps more, narrowly defined agents that try to examine the problem from more angles? Need to think about this more.
0. (future) once Gemini/Ollama/etc. reach a sufficient level of subagent and skill capability, can codev be refactored to use them instead of requiring Claude? If codev were more "skill" based could any agent with delegation abilities become an architect?

I see these two paths forward:

0. Refactor codev to address these cases
1. Create a "codev light" fork that blatantly steals borrows protocols and core architecture, focusing on skills-heavy implementation with fewer features

Questions for the community:

0. Are the proposed modifications aligned with codev's direction?
1. Would platform agnosticism be prioritized over team collaboration features (sphere 7)?
2. If not, would you be interested in--or at least not opposed to--a "codev light" fork?

[waleedkadous]

My personal opinion is that I would like to see these incorporated into codev. The things is I can't lead these efforts myself because it's not the way I personally operate, but I am eager to support those who do. On the particular issues:

0. Open to this. But isn't this what most of the exsting toolchains like claude code already do? What would a protocol for one of these look like?
1. Very supportive of this. I've been seeing a lot of work of defining different agent skills rather than using different underlying models. So my guess is this would get us maybe 50% of the way of true multi-model agents.
2. Yes. I just wish I could do it myself -- someone has to live and breathe these tools and alternative to catch all the issues and optimize appropriately.

On your questions:

0. Yes they're aligned. You can see we just made a bunch of changes to make codev more flexible for different use cases. I see this as part of that.
1. It depends on what resources are brought to bear. I can't lead platform agnosticism myself, but if someone was to take the lead on it, I would love to support them.
2. Codev is already relatively small as a community and I think there's more benefit in us adding flexibility to one system than forking into two but if that's the direction you choose to go, I'll try to be as supportive as possible.

[nharward]

Thank you @waleedkadous - I'm interested to drive this but need to think for a day or two to decide if I have the bandwidth. I'm leaning towards yes but will reply back here by Wednesday.

As far as sphere 3-5 protocols go, I found my user error and need to retract this point. I read the protocols in detail and realized ASPIR was selected but I needed to specify to use SPIR. My project is written in Zig which has less training data than for Python/Java/TS/etc. and requires oversight. I'll try again with SPIR.

[waleedkadous]

Sounds good, thanks for the update. Spir is the default protocol you should generally use for new code unless it is a very trivial or linear task (eg Something like add HTML output instead of markdown), then use aspir.

…

On Mon, Mar 30, 2026, 9:11 AM Nathaniel Harward (Nat) < ***@***.***> wrote: Thank you @waleedkadous <https://github.com/waleedkadous> - I'm interested to drive this but need to think for a day or two to decide if I have the bandwidth. I'm leaning towards yes but will reply back here by Wednesday. As far as sphere 3-5 protocols go, I found my user error and need to retract this point. I read the protocols in detail and realized ASPIR was selected but I needed to specify to use SPIR. My project is written in Zig which has less training data than for Python/Java/TS/etc. and requires oversight. I'll try again with SPIR. — Reply to this email directly, view it on GitHub <#648?email_source=notifications&email_token=AAUXGUAXHLVRC5NCZZS7PCT4TKMC3A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTHAZTENJRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16383251>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUXGUEWZDJHJSLITBGZJF34TKMC3AVCNFSM6AAAAACXFK3EQKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZYGMZDKMI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nharward]

@waleedkadous I think I will take this on even if my pace isn't as fast as I'd like.