Coding agents

Take · The biggest worry about letting coding agents run freely has always been what they can touch on your machine. I'd set the team default to: write only to the current repo, no access to Git credentials, network via an allowlist, with local MCP servers included. That beats reviewing every command after the fact, and teams on other coding agents should hold their isolation to the same bar.

Take · With agents committing at every step, the odds of a secret slipping into history only go up, and blocking it at push time is far cheaper than rotating it later. I'd pilot push protection on repos that already have GHSP and set a budget cap on AI Credits, since checks bill even when nothing is blocked. GitHub's note that agents shouldn't enable credit-consuming features without explicit authorization is worth copying straight into a team's agent rules.

Take · Skills are becoming how cloud vendors compete for the coding-agent entry point: whoever's deployment know-how lives inside the agent gets picked more often. I like that it produces code rather than opaque actions, but benchmarks spin up real endpoints and real bills; give the agent a separate account with a budget cap before letting it run.

Take · With an API, AI review can plug into your own release flow, for example raising the effort only when a change touches payments or permissions. The default effort changed, so review time and usage may shift too; check your bill and PR wait times this week. I wrote on the blog about how to split review work when AI writes most first drafts.