I built it because I was tired of keeping the orchestration logic in my head - spawning a separate session for a blind review, switching back to the implementing session to evaluate results, deciding what to build next. I had plugins for the individual pieces but the sequencing was still on me. I wanted a harness that handled the full loop, and one that was generally useful across projects, not hardcoded to a specific codebase.

You give it a specification - a prompt, a plan file, a PRD - and eforge assesses complexity against your codebase, selects a workflow (simple changes get a fast path, complex ones decompose into a dependency graph of sub-plans), builds in isolated git worktrees, reviews, and validates - all without supervision.

The way I actually use it: I plan a feature interactively in Claude Code, then run `/eforge:build`. The plugin picks up the plan, enqueues it, and a daemon takes over. eforge pulls plans off the queue, understands dependencies between them, executes in parallel where possible, and merges in topological order. Queued work is re-assessed before execution so changes from earlier builds are accounted for, not blindly applied to a codebase that has moved on. I check the results when builds finish - a web monitor dashboard tracks progress, cost, and token usage in real time. eforge builds itself this way.

Each build phase gets its own agent - planner, builder, reviewer, evaluator, fixer. The reviewer runs in a fresh context with no knowledge of how the code was written. Anthropic's engineering team independently arrived at the same pattern (https://www.anthropic.com/engineering/harness-design-long-ru...) - their finding: solo agents approve their own work; adversarial evaluation dramatically improves quality. An evaluator then applies per-hunk verdicts, accepting strict improvements while rejecting anything that alters intent.

Comments URL: https://news.ycombinator.com/item?id=47519996

Points: 3

# Comments: 0

     - The club would meet either once or twice per week for an hour for the entire school year.
     - Expected attendance between 5 and 10 kids.
     - I will be providing / directing purchase of hardware, and am imagining purchasing 10 Raspberry Pi's along with monitors and keyboards.

I want to reinvent the wheel as little as possible and am asking if anyone has suggestions for curriculum for this sort of club. Possibilities I've thought briefly about so far: some sort of game (though I have not experience in developing games) and building websites that we gradually make more sophisticated (this is more up my alley).

I'm asking for pointers to help me develop a curriculum. If you've done something like this before, I'd love to hear what sort of wins and challenges you experienced as well.

Thanks in advance!

Comments URL: https://news.ycombinator.com/item?id=17545990

Points: 2

# Comments: 1