We found that they used between 2 and (almost) 6 x the input tokens and were never faster on any task we timed.

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

Points: 1

# Comments: 0

1) We have added a repository reproducing the methods.

2) We have commented on output quality in the post (in addition to tokens/cost).

3) Per a previous update, we now handle Fable 5 in the post.

After reading PUSH_AX's valid comment: ``` This is like saying contractor (A) asked for $33,000 to undertake the work and contractor (B) asked for $7,000 Are we measuring and caring about the right thing? ``` We will update the post to include:

1) A more in-depth task. 2) Qualitative results comparison. 3) As soon as possible, a reproduction of the inputs and outputs.

Suspect that many have covered the "Comparing agentic coding tools" angle before, and that the differentiator is depth of analysis + conclusions.

Cost, mainly. The runs went through a Claude Max subscription rather than metered API billing, and pinning an older stable snapshot kept run-to-run comparisons clean and cheap. The fixed harness payload (system prompt plus tool schemas), so the headline numbers shouldn't change too much.

That said, happy to re-run the matrix on Fable and publish the diff; payload figures should barely move, tool-calling behaviour might.

Gateway:

Meridian (github.com/rynfar/meridian); proxy that bridges the Claude Code SDK to a standard Anthropic endpoint so a Claude Max subscription can drive OpenCode-et-al.

It's the auth route for all agent traffic on the machine, not something built for the benchmark.

This was the initial anecdotal evidence, but we undertook this small study to collect empirical data:

We added logging between the agentic coding tool (Claude Code and OpenCode) and Anthropic's endpoint, and captured all requests (and the returned usage blocks).

With one caveat (toward the end of the post) we found unambiguously that Claude Code was far more inefficient in terms of its cache strategy and its harness token usage than OpenCode.

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

Points: 706

# Comments: 395

* Shaping: MEDDIC qualification, ROM estimate, SoW draft

* Mobilisation: Charter, RACI, governance, kickoff

* Planning: Plan, capacity, budget baseline, estimate challenge

* Execution: Weekly status, RAID, standup digests, blocker triage

* Governance: Steering packs, exec summaries, stakeholder updates, escalation memos

* Risk and change: Risk deep-dives, change requests, mitigation, escalations

* Technical-quality oversight: SDLC, QA, systems engineering, secure-SDLC health checks

* Commercial: Budget tracking, margin analysis, change orders, invoice backup

* People: Team health, attrition risk, ramp plans, one-to-one prep

* Closure: Checklist, retrospective, lessons, case study, handover

Outputs are audit-ready markdown, each linked back to its charter revision, source documents, model, and prompt hash.

The engagement charter is a 'living constitution' that every artifact reconciles to.

Anything leaving your machine (steering decks, exec memos, change orders, SoWs) passes through an adversarial red-team gate first.

Local-first, and engagement data never leaves your disk.

npx @systima/project-delivery-framework

https://github.com/systima-ai/project-delivery-framework

We built this because the "AI for project management" space is almost entirely tooling for product management.

The framework is for the person running the multi-month, multi-stakeholder engagement (budget, the client, the team, and the contract, etc).

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

Points: 2

# Comments: 0

I recall the Beeper Mini debacle not so long ago, and fear that this may be a house built on sand.

The engineering-focused findings have been covered extensively (fake tool injection, Undercover Mode, KAIROS, etc).

This piece focuses on what these findings mean if you're using Claude Code to build AI systems subject to the EU AI Act.

TL;DR / spoiler:

Claude Code isn't a high-risk AI system in and of itself.

The EU AI Act regulates your deployed system and your process, not your tool vendor's internal engineering practices.

What caused the switch was that we're building AI solutions for sometimes price-conscious customers, so I was already familiar with the pattern of "Use a superior model for setting a standard, then fine-tuning a cheaper one to do that same work".

So I brought that into my own workflows (kind of) by using Opus 4.6 to do detailed planning and one 'exemplar' execution (with 'over documentation' of the choices), then after that, use Opus 4.6 only for planning, then "throw a load of MiniMax M2.5s at the problem".

They tend to do 90% of the job well, then I sometimes do a final pass with Opus 4.6 again to mop up any issues, this saves me a lot of tokens/money.

This pattern wasn't possible with Claude Code, thus my move to Open Code.

Hugely grateful for what they do.

In my experience, this correlates more with soft skills and “one man band” founder/maker companies that tend to sell training products or (if they do exist in a company environment at all) invariably work in DevRel and aren’t pushing code.