← Back to context

Comment by nunez

1 day ago

This matters for big engineering teams who want to put _some_ kind of guardrails around Claude that they can scale out.

For example, I have a rule [^0] that instructs Claude to never start work until some pre-conditions are met. This works well, as it always seems to check these conditions before doing anything, every turn.

I can see security teams wanting to use this approach to feel more comfortable about devs doing things with agentic tools without worrying _as much_ about them wreaking havoc (or what they consider "havoc").

As well, as someone who's just _really_ getting started with agentic dev, spending time dumping how I work into rules helped Claude not do things I disapprove of, like not signing off commits with my GPG key.

That said, these rules will never be set in stone, at least not at first.

[^0]: https://github.com/carlosonunez/bash-dotfiles/blob/main/ai/c...

4 comments

nunez

Reply
bisonbear  1 day ago

I'm also thinking on how we can put guardrails on Claude - but more around context changes. For example, if you go and change AGENTS.md, that affects every dev in the repo. How do we make sure that the change they made is actually beneficial? and thinking further, how do we check that it works on every tool/model used by devs in the repo? does the change stay stable over time?

  • nunez  15 hours ago

    Given the scope that AGENTS has, I would use PRs to test those changes and discuss them like any other large-impact area of the codebase (like configs).

    If you wanted to be more “corporate” about it, then assuming that devs are using some enterprise wrapper around Claude or whatever, I would bake an instruction into the system prompt that ensures that AGENTS is only read from the main branch to force this convention.

    This is harder to guarantee since these tools are non-deterministic.

dominotw  1 day ago

NO EXCEPTIONS!!!!!!!!!!!!!!!!!!!!!!!!

cute that you think cluade gives a rat ass about this.