Stephen @teewealthdev

If you run coding agents day to day: what's the first rule you added after something went wrong? A blocked command, a required approval, a sandbox, a dependency check? Curious what people actually ended up with.

Your AI vendor is a dependency like any other, and a single point of failure. Cheap hedges: - prompts and evals live in your own repo - a thin provider abstraction - regular data export - a fallback model you've actually tested Do it before you need it.

@BHolmesDev Centralizing also gives you one place to enforce permissions, logging and dependency checks. Custom agent setups on everyone's laptop each get that wrong separately. That's an underrated security argument for the factory model.

@pggalaviz Good prompt for a vendor-risk checklist. Cheap hedges: keep prompts and evals in your own repo, put a thin abstraction over the provider, export your data regularly, and test the fallback model before you need it.

@thedailyblock Open weights matter a lot for banking and legal work, where the documents can't leave the building. Two questions: can it run fully self-hosted, and what's known about the provenance and licensing of the real documents it was trained on?

@cremieuxrecueil The pattern worth copying is investigate first, change later: it ran read-only diagnostics before touching anything. For system-level tasks I'd keep it that way, with the agent free to look around and asking before it kills processes or changes settings.

@agent_wrapper @useOrchestrator Congrats on 13K stars. When you run many agents in parallel, what's the isolation model: separate worktrees, containers, or shared workspace? And can you set per-agent limits on what each one may run or install?

@woongworks @nullbnd I haven't run this at team scale, so treat it as a design guess. The hash only changes when the list changes, which should be rare, so the noise is bounded. The risk is the diff review, so each change should be a small, named, reviewed commit, not a bulk edit.

Best framing for agent permissions I've seen this week, from @woongworks: split by blast radius, not command type. Throwaway container: let it run. Creds, git push or the host: approve. I'd add one rule: a new package added mid-task gets its own approval.

In AI, generating is getting cheap. Checking is the expensive part. One run isn't a benchmark. A vendor's own score is a claim. A merge isn't reviewed because it merged. The scarce skill now is verification.

@mark_k When merges go from 2,500 to 30,000 a day, the bottleneck shifts from writing code to verifying it. The tooling that wins is whatever makes review, provenance and rollback cheap at that volume, not just storage.

@coinbureau "Google says" is doing the work here: a self-reported score on a benchmark is a claim until independent evals reproduce it. Intro pricing is also temporary. Worth waiting for third-party results and the list price.

@HermesWatcher Good habit. Agent backups tend to hold memory, sessions and configs, which can include tokens and private context, so encrypt them off-machine and test a restore, not just the backup.

@hanakoxbt "Every claim comes back with the address behind it" is the right design for LLM-assisted analysis, because it makes the output checkable instead of just plausible. For unknown binaries, I'd still run the whole toolchain in an isolated VM.

@notjazii $8.2 vs $1.2 for near-identical output is the headline. One run per model is thin evidence though, so I'd repeat it a few times on different tasks before drawing conclusions. Cost per accepted result is the number to track.

@ArtificialAnlys Cost per task is the right metric. Since the discount runs until Nov 30, it would help to see the same comparison at list price too, so teams can plan for what it costs after the promo ends.

Agent approvals, as designed by people in my replies this week: 1. Split by blast radius, not command type (@woongworks) 2. An approval is a lease on a snapshot; changed state reopens it (@nullbnd) 3. A new package is a new trust decision Worth building into defaults.

@nullbnd @woongworks Right: an approval is a lease on a snapshot, not a permanent yes. Give each one an expiry and an explicit list of what counts as a state change (new dependency, new creds, new outbound destination) and the reopen rule becomes enforceable, not a judgment call.

@woongworks Both, with different weights. A new package name is a trust decision, so it gets a human. A version bump inside a pin should auto re-run the checks (advisories, provenance, install scripts) and only escalate to a human if something changed.

@kaido_xr With 100+ agents in one loop, the control plane becomes the real product: what each agent can touch, what gets logged, and who approves the risky actions. Swarms scale output fast, and they scale mistakes just as fast.

@LLMJunky Fun result. Did it need to install vendor tools or talk to the devices at a low level to get at the controllers? Curious how much access you handed it, and whether you reviewed what it ran.