kleyd

Exactly, the whole fence analogy is ridiculous. A better analogy would be an open door inside a public building and saying: "there were no signs allowing access to that door"

If you currently use a 7 day cooldown on a 0 day default. You can just use a 10 day cooldown on a 3 day default. But don't tell anyone...

The wording in the declaration may be a bit romanticized. But the points are valid:

Is an 80 year old unsolved problem maybe unsolved because it was never prioritized? Some problems stay unsolved because few people consider them worth working on.

Who is going to validate the results? Or do we skip that, with the risk of flooding the literature and collective understanding with unverified proofs?

Your conclusion touches on this, but I think the brain analogy is stronger than the hardware/software dichotomy.

It is also my very uninformed intuition: https://news.ycombinator.com/item?id=44910353

Also interesting to think about: could a single system be generally intelligent, or is a certain bias actually a power. Can we have billions of models, each with their own "experience"

The main benefit of using XML here seems to be that it forces clearer thinking and formulation from the user.

The cooldown is to allow vulnerabilities to be discovered. So auto update on passing tests, which should include an npm audit check.

Thought experiment: strip a forge down to what plain Git can't do: identity (who?), attestations (signed claims about a ref or actor), and policy (do these claims allow this ref update?).

With just those primitives, CI is a service that emits "ci/tested." Review emits "review/approved." A merge controller watches for sufficient attestations and requests a ref update. The forge kernel only evaluates whether claims satisfy policy.

Vouch shifts this even further left: attestations about people, not just code. "This person is trusted" is structurally the same kind of signed claim as "this commit passed CI." It gates participation itself, not just mergeability.

All this should ideally be part of a repo, not inside a closed platform like github. I like it and am curious to see where this stands in 5 years.

Ha, that's certainly a way to build things fool-proof.

I believe this only works when there are no other uncommitted changes.

So you would need to stash after the fixup commit and pop the stash after rebase. Or use autostash.

It's not a trade-off of clarity just to save developers some extra typing. It's actually improving the clarity by bringing the thing you care about to the foreground: the getting started page having a table of contents with specific items.

I wouldn't dare say XML is better in this regard, but a good reason to be conservative with the use of annotations is exactly that cmd+clicking them doesn't easily lead to where the behavior is implemented.

Current LLMs look a lot like a very advanced 'old brain' to me. While context engineering looks like optimizing the working memory.

What's missing is a part with more plasticity that can work in parallel and bi-directionally interact with the current static models in real-time.

This would mean individually trained models based on their experience so that knowledge is not translated to context, but to weight adjustments.

That matches exactly my experience. Now there are a couple of prototypes to be finished, which still takes time. And higher priority tasks get delayed instead of sped up.

Does anyone else find themselves starting projects that wouldn't otherwise be worth the time investment, while avoiding Claude Code for the tasks that actually have high priority?

Who has had success using Claude Code on features in older, bigger, messier projects?