I disagree with the assertion that the model gets it. Here’s a practical example I just tried with Fable 5.1. I gave it this prompt: “Write a Go function that can be used to establish secure communication to a remote system using a certificate. Keep it short, single function, and explain how to use it.” The output forced the use of a private key stored in a file even though that wasn’t specified anywhere as a requirement. The function Claude wrote takes a private key file argument and calls a Golang function that requires a private key file (tls.LoadX509KeyPair) even though Go has crypto.Signer which could support private keys in various other manifestations like HSM or KMS. I argue that a person who “gets it” (or who is reasonably experienced in security) would have opted for not requiring private key material for this to work.
For the record, this isn’t unique to Claude. ChatGPT and Gemini do the same, each with its own quirks. ChatGPT got extra credit for being the only one who allowed the function to also take a CA file for server authentication.
Don’t get me wrong: LLMs are the future (maybe even the present) of software development but I think there’s some way to go before they can be entirely hands-off in some areas. I still find myself having to course correct designs and plan mode helps me with that.
And of course, thank you for your work on Claude. :)
Whether or not a distinct "plan mode" is needed, upfront planning remains essential in my experience, even with Fable (albeit not the 5.1 version). I agree that, as the models get better, you can skip planning on increasingly complicated tasks.
But there is still a ceiling above which it is necessary to "preload" the context window before starting to call tools and get into the meat of the work. You want to establish domain language (especially with Claude models which otherwise will invent their own, and it will be inscrutable) and key requirements and assumptions. You want to do a Q&A iteration cycle with the LLM. You definitely should do a sanity check that the LLM actually "understands" what you were trying to achieve, and then make sure that understanding is coherently and plainly stated in the prompt. All of that seems to be necessary still for just about any serious task, if you actually care about the quality of the results and/or don't want to burn hundreds of thousands of tokens on flailing around to get to a good quality result.
So no, you don't "need" plan mode. But you do still need to do all of the things you would do with plan mode.
But in your example you never even asked it to plan so you could check the implementation before writing it you just asked it to write it directly, so this isn't even a comparison to plan mode
I'm hoping that by "gets it," he meant that if you start a discussion about the design, it doesn't misunderstand and immediately go off to do the work. Some models tend to do this.
Thank you for working on this, I love the idea. What surprised me was the way user identities is managed, I assumed you’d use whatever git uses. Would you mind elaborating on that?
Identities in git can barely be called that. You define your name and email, maybe sign your commit. Those signature can be checked but it's really optional and often left to another system (e.g. github or your git viewer). Access right in the git remote is also a completely different thing.
In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates. Any changes in the entities (bug, pr, ...) need to have an author and a clear logical time so that you can backtrack to which pubkey(s) was active at the moment. Note that if you accept external contribution from a webui, you still need those identities being created in the background, possibly later to be "adopted" when using the native tooling.
Identities in git-bug is a part that nearly didn't change since the inception, and it's time for an upgrade. At the moment they are a linear series of changes (that is, NOT a CRDT) and are stuck within one repo. You can push/pull around but you are really just making a copy that you need to maintain.
My plan is to split this concept in two parts: pubkey log, and how they anchor within the repo's logical time. It turns out that if you split that way, the first part is pretty much exactly what did:plc is. Additionally, for complicated reasons like allowing recovery without opening major weakness, that's the one thing where having a centralized reference is important, so relying on the public https://plc.directory/ makes sense.
> In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates.
I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
> so that you can backtrack to which pubkey(s) was active at the moment
I think GitHub solves this by simply checking at the time of the push and then never again (which is why you can change the keys without de-verifying older commits. Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
> I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
There is different pieces that solve part of the problem (name/email from the git config, key servers for *some* users), but everything is disconnected, unstable, incomplete. Git-bug needs a stable identifier, the full self-certified pubkey log ... Those solutions are not good enough.
> Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
It's not specific to git, but yes you get a chain of data blocks, content-addressed with signature support. That's what you want to build on, to have identities, roles, rules to enforce in a p2p system.
> Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
Agree! Note that if git-bug bring a solid identity primitive and publish pubkeys ... it can also carry the pubkeys that are *already* used to sign commits, publish them in the same public registry and verify code commits transparently, without relying on a third party to do so. Imho that's something missing in the current git model: if there is identities, there are segregated in third party systems like github. DIDs brings a lot to the table.
It's really hard (impossible?) to define a feature set that work for everyone. Every bug tracker is a bit different, and if you want to have everything you end with Jira, which I'm not sure is actually solving a problem.
However, git-bug's data model is designed in a way that you can add more "operations" on an entity (say: assign a bug) without every client having to implement it. You can also add your own entity type (pr, kanban, ...) the same way. Clients will just ignore that extra data and support what they want. This open the possibility for addons and so on.
For this specific case of the bug states, I want to add a config entity to configure that. You'd start with a reasonable default (open/close) but you could tune it for the needs of your project.
To me, there’s a difference between ads that help me learn about brands or products, or make me laugh or have some positive emotion (Super Bowl ads, billboard signs, and movie previews come to mind) and ads that take over search results, interfere with the content I want to consume on an already-small screen, or are just distasteful to me. I can’t say I like ads but I recognize that I specifically dislike some ads more than others.
That’s the important question. Someone else on the thread suggested it was to divert attention from one failure (AI) and now they have two. I wonder how Steve Jobs would react to this mess. Maybe he’d say he would not have been in such a mess in the first place. :)
I thought the same thing. Some of the commenters said this move might be related to stock price or appeasing shareholders, so I wonder if that, too, was directed at them, as in “we’re big and we plan on getting even bigger”
I agree, and I think the government’s incentive might also be a having strategic production capability in the US. Maybe they’re concerned about TSMC’s future with the tension between China and Taiwan?
That's all fine, but this is definitely heading into socialist territory. I guess they're out of ideas and this is how they incentivize. The free markets have failed?
My hypothesis is that this is government response (own stake in Intel) to another government’s action (hint take over of Taiwan) and as such is outside the free market. But I have no evidence to support it, it’s just an opinion and it could be that they view Intel as “too big to fail” or something like that as you suggest.
Encryption at Rest makes it easy to reason about data hygiene, since access to the data is gated through access to the keys.
You want to delete data? Toss the keys. You want to confidentially process data? Make the keys available to a TEE or such. You want to prevent yourself from having constant access to the data? Let the client provide the keys. And of course, you want to protect the keys? Use an HSM.
For the record, this isn’t unique to Claude. ChatGPT and Gemini do the same, each with its own quirks. ChatGPT got extra credit for being the only one who allowed the function to also take a CA file for server authentication.
Don’t get me wrong: LLMs are the future (maybe even the present) of software development but I think there’s some way to go before they can be entirely hands-off in some areas. I still find myself having to course correct designs and plan mode helps me with that.
And of course, thank you for your work on Claude. :)
reply