Banks are finding AI agents inside customer accounts that nobody at the bank authorized. According to Axios, major U.S. banks are detecting third-party agents in customer accounts, and some are taking actions the customer never asked for. Executives say they struggle to tell a human from an agent. Most of these agents got in the simplest way possible: customers shared their own logins. Same week, Microsoft said China-linked attackers used an open-source AI security tool to break into IT firm ConnectWise, then tried to log into 2,250+ customer environments. At some, they had high-level access within three hours. The fix isn't banning agents. It's never giving them the password. 1Password just announced 1Password for Agents: 1- The agent reaches a sign-in form 2- It requests a credential from your vault 3- You approve 4- 1Password fills it in on the site. The agent never sees it. It works with Claude, OpenAI, Grok Bot, Meta's Muse, Perplexity, Browserbase, Browser Use and more. It's free and opt-in for personal and family accounts. If you build agents for clients, copy this pattern: give the agent access to do the task, never possession of the secret. Would you let an agent log into your bank, even with an approval step?

AI now writes about 90% of Claude Code's own code. So who reviews it all? Not one human reading line by line. That stopped working as a gate a while ago. Anthropic just published how its team replaced it. The results from June to September: → Merged PRs more than doubled → The share of PRs needing a revert fell by more than 40% → PRs passing after one review round went from 65% to 78% What changed was the review system, not the reviewers. It works in six layers: 1- Verify before the PR exists. The agent runs tests, build and lint and shows the output, instead of just saying it worked. 2- AI review on every PR. Several agents look for bugs in parallel, and the findings get voted on before any are posted. 3- A security review that can block the merge. 4- Required CI. 5- Human approval scaled to the risk: 0, 1 or 2 people depending on what the change touches. 6- Feature flags and staged releases, with one-step rollback. The rule I'm copying first: cap review rounds at 3. Agents will happily fix each other's nitpicks forever. One PR ran more than 50 overnight rounds before its author stopped it. What humans still own: judgment, direction, the risky code paths, and the outcome of every change that ships. The full breakdown is in the carousel. Anthropic's full write up is in the comment.

Running Claude Code on max effort for every task? You're paying for verification you don't need, and waiting longer for it. Anthropic engineer Thariq Shihipar tested effort levels on real builds and on Terminal-Bench 3.0. His rule of thumb: Low → quick, in-the-loop work: brainstorming, sketches, easy changes Medium → most everyday engineering, like new features High → when edge cases and verification matter, like fixing a bug in an older codebase Max → when Claude should work fully on its own: end-to-end builds, hunting security bugs What higher effort actually buys you: more testing, more edge cases, more decisions made on its own. What it doesn't buy you: higher effort reduced failures from missed edge cases. It did not fix failures where Claude took the wrong approach. His loop for new features: 1. Give Claude a spec and let it interview you for the gaps 2. Build on low/medium effort 3. Review, and iterate on low/medium 4. Verify and test on high Switch anytime with /effort, even mid-conversation. On the newest models, changing effort doesn't break the prompt cache. The 3 prompts for his loop: Interview (low effort): "Here's my spec. Before writing any code, interview me about anything missing or ambiguous, one question at a time. When we're done, write the final spec to SPEC.md." Build (low effort): "Implement SPEC.md. Keep it simple. Don't add anything the spec doesn't ask for." Verify (high effort): "Review the implementation against SPEC.md like a strict reviewer. List the edge cases, write tests for them, run them, and report every failure before fixing anything. You can use medium effort using Opus 5.5 for Interview and Build , and verify using high effort.

Running Claude Code on max effort for every task? You might be paying 3x for answers you didn't need. An Anthropic engineer, Thariq Shihipar, put Claude Code's /effort settings to the test. The results changed how I think about AI coding costs. What higher effort actually does: → Claude verifies more → Tests more edge cases → Makes more decisions on its own What it costs: → Roughly 3x the tokens per attempt (highest vs. lowest setting, Terminal-Bench 3.0) Where it paid off: - Security: 64% → 87% - Hardware: 34% → 75% - Rulebook work (operations filings): 12% → 22% The pattern: effort pays off when there's real complexity to verify. And the line that stuck with me: More effort never fixed a wrong approach. So his workflow is "build low, verify high": 1- Start with a spec, and let Claude interview you for the gaps 2- Build on low effort while it's still easy to steer 3- Keep iterations light while you figure out the shape 4- Turn effort up for testing, once the direction is right Bonus: Opus 5.5 at medium effort reportedly outscores Fable 5.1 at max effort on Terminal-Bench 4, at $2.94 per run instead of $20. Multiply that across a team, and your effort setting becomes a budget decision. The full framework and a cheat sheet are in the carousel. Save it for your next session. What's your default effort level, and has it ever surprised you?

A startup just deleted more than 800,000 lines of unit tests. On purpose. The founder of an AI observability startup argues that now that coding agents write so much of the code, unit tests can do more harm than good: → They lock in bad AI-generated code → They create "busy work" for agents → They slow down CI pipelines → They drive up token bills A Coinbase engineer agreed: lean on full end-to-end, integration, and golden tests instead. Not everyone is convinced. Veteran engineer Bob Martin ("Uncle Bob") says he still relies on unit tests to keep his agents honest. Here's how I see it: Unit tests written by agents, for code written by agents, can turn into the AI grading its own homework. But tests that capture real business rules are the guardrails that stop an agent from "fixing" your code into the wrong shape. So maybe the question isn't "delete or keep?" It's "which tests protect behavior, and which only protect implementation details?" Where do you stand? A) Delete most of them and test behavior end-to-end B) Keep them, because they're the agent's guardrails