claude-account → hatswap (and a lot more) A few hr ago I shared claude-account, my tool for juggling the Claude Code accounts my clients give me. Thanks for all the feedback. Since then it has a new name, hatswap (old links still work), and I've shipped a pile of updates. Here's everything it does now, with what's new marked : Accounts → Every account stays signed in at once. No more logout/login. → Settings, skills, agents, MCP servers and memory are shared across accounts. Only the login changes. → 🆕 pin acme: a client's folder always opens on that client's account, so you never end up on the wrong one. → 🆕 default acme: choose which account a plain claude starts on. → 🆕 --private: keep a client's conversations and memory on that client's account only. → 🆕 whoami: shows which account you're on, and why. Moving work → switch acme: move the conversation you're in to another account, with full history. → 🆕 It restarts in the same tab, in tmux, Terminal.app and iTerm2. → handoff acme: continue a conversation on another account, or fork a copy. → 🆕 /switch and /handoff work from inside Claude. Briefs & Codex → handoff codex: a short, repo-aware brief (goal, what's done, the next step, plus your branch and open PRs) starts Codex. → 🆕 Briefs include "Tried and rejected", so the next agent doesn't repeat dead ends. → 🆕 Each account gets its own Codex login, and handoffs use the one that matches. → refresh: restart a bloated session from its brief, on the same account. Safety → Never reads or copies your credentials. → API keys, tokens and passwords are redacted before anything is summarised. → 🆕 An exported ANTHROPIC_API_KEY no longer overrides an account's login. Setup → 🆕 One-line install, plus hatswap update. → 🆕 Already on claude-account? Run claude-account update. Your accounts, logins and pins carry over. One bash script. macOS + Linux. MIT. 151 tests in CI. github.com/orvi2014/hatswap If it saves you some logging in and out, a ⭐ really helps 🙏

A customer reports that their client paid an invoice in AgencyHandy, but the invoice still shows as unpaid. This is where I think AI agents get interesting. Not when you ask one to write a function. When you give it a messy engineering problem and ask it to figure out what actually happened. Here's how I'd design an agent to investigate this. First, I wouldn't tell it to fix the invoice. That sounds obvious, but think about it. The payment might have succeeded while our webhook failed. The webhook might have arrived, but signature verification could have rejected it. The event might have been processed, but the database update failed. Or the invoice status might be correct in the database and wrong in the UI. Same symptom. Very different root causes. If the agent jumps straight to editing the invoice status, it might hide the bug rather than fix it. So the first job is to reconstruct the chain of events. I'd give the agent read-only access to the relevant application code, payment records, webhook logs, and database state. Then I'd ask it to establish what happened at each stage: Did the payment provider confirm the transaction? Did our server receive the corresponding event? Did signature verification pass? Did the event handler execute? Was the invoice update committed to the database? Where does the evidence stop matching the expected flow? I want the agent to show its evidence, not just return a confident explanation. Next comes the part I find most interesting: competing hypotheses. A timeout could explain a missing update. So could a rejected webhook. But if the agent sees a timeout and immediately decides that's the cause, it may stop investigating too early. I'd ask it to identify plausible explanations, find evidence that distinguishes them, and explain what would disprove its leading hypothesis. Once it has a likely root cause, it moves to a test environment. Reproduce the failure. Write a regression test. Make the smallest reasonable change. Test the normal payment flow, delayed events, duplicate delivery, and recovery after a failed database operation. For payment systems, I'd also enforce idempotency and verify transaction state against the payment provider. An agent must never decide that a customer paid simply because a status update would make the error disappear. But here's the problem I don't think we should ignore. What happens when the agent is wrong about its own fix? It might misunderstand the root cause, write a test that encodes the same mistaken assumption, and then confidently report that everything passes. We've now automated the investigation, the implementation, and the validation, but all three can share the same blind spot. I'd want deterministic invariants, independent tests, and a human approval step before production changes. Maybe a separate verification agent helps. Maybe it just adds another model that can make the same mistake. That's exactly what I'd want to test rather than assume. The bigger engineering challenge isn't getting an agent to make a code change. It's building a workflow where every important conclusion has evidence, every change can be verified, and uncertainty doesn't disappear behind a green checkmark. For people building coding agents or researching agentic systems: how would you design the verification stage? Would you use a second agent, property-based testing, deterministic rules, or something else? I'd especially like to hear about approaches you've tested on real codebases, not just benchmarks.

There are two types of developers: 1. Those who write "console.log("here")" 2. Those who write "console.log("HERE 2")" Because the first one didn't work and we need to know which “here” we're talking about. What's your debugging technique? 😂

Your API has a new user. And it doesn't read documentation like a human. AI coding agents are increasingly choosing libraries, calling APIs, reading error messages, and trying to fix their own mistakes. That changes what “developer-friendly” means. An API can be perfectly usable by humans but frustrating for agents because: • Examples omit required parameters. • Errors say what failed, not how to fix it. • Documentation hides important constraints. • Tool responses return huge amounts of irrelevant data. We're used to asking: “Is this API easy for developers to use?” Maybe we need a second question: “Can an AI agent use it correctly without guessing?” Because the next generation of developer tools won't just be built for people writing code. They'll also be used by agents writing code. If you maintain an API or SDK, what would you change first to make it more agent-friendly?

You can give your AI agent any capability, but it must NEVER be allowed to do one thing. What do you forbid?

AI builders, developers, indie hackers, and curious minds 👋 What are you working on these days? Drop by and say hi. Always fun to see what people are building! 🚀

and like always @realmadrid wins the el classico A classic win by Morinho amd Mbappe..

Dream job alert: Get paid up to €2,500/month to count penguins in Antarctica 🐧 Just a few minor details: - No showers for days (sometimes a week) - No running water - Shared bunks with 4 other people - You also run the world’s southernmost post office - Must already live in the UK Apply now and prepare to smell like a penguin by March. 🐧

Roll call for the people building their own little corner of the internet. 👀 I want to meet people who are: 🤖 Building with AI 💻 Shipping side projects 🛠️ Making open-source tools 📚 Learning something new in public 🚀 Turning a random idea into a real product Here's the fun part: Drop your niche in 3 words. I'll go first: AI agents, dev tools, SaaS. Let's find our people. 🤝

Don't forget to eat.... You need strength to suffer....

Describe your coding personality as an error message. Mine: "Warning: Works perfectly. Do not touch." 💀 What's yours? 👇

Let's make X feel a little less like a competition. I want to connect with people who are: → Building something nobody asked them to build (yet) → Learning AI by breaking things and fixing them → Working on open-source projects → Figuring things out in public → Just starting out and looking for their people No follower count requirements. No “DM me to network.” Tell me three things: 1. What are you building or learning? 2. What's one thing you're struggling with? 3. What can you help someone else with? I'll go through the replies and find people whose interests overlap. Let's find our people. 🤝

Building with LLMs? Keep this AI security toolkit nearby. Prompt injection. Data leakage. Jailbreaks. Unsafe tool calls. Vulnerable dependencies. These are the risks worth testing before your AI feature reaches production. 1. LLM red teaming • Promptfoo — Test LLM applications, prompts, and agents against adversarial inputs • Garak — Scan language models for vulnerabilities using probes • PyRIT — Build automated adversarial testing campaigns 2. Prompt injection & jailbreak testing • Promptfoo — Test direct and indirect prompt injection scenarios • Garak — Probe for jailbreaks, injection weaknesses, and other unwanted behavior • OWASP GenAI Security Project — Learn the threat patterns and testing approaches to look for 3. AI guardrails • Guardrails AI — Validate model inputs and outputs against defined requirements • NeMo Guardrails — Add programmable controls to conversational AI applications • Llama Guard — Classify prompts and responses for specified safety risks 4. Application code security • Semgrep — Find insecure code patterns • CodeQL — Analyze code for security vulnerabilities • Bandit — Detect common security issues in Python code 5. Secrets & credential protection • Gitleaks — Find exposed secrets in repositories and Git history • TruffleHog — Detect exposed credentials and verify secrets where supported • GitHub Secret Scanning — Identify supported secret types exposed in repositories 6. Dependency & container security • Trivy — Scan dependencies, container images, and configuration • OSV-Scanner — Find known vulnerabilities in open-source dependencies • Docker — Isolate application processes and package workloads consistently 7. ML model security • ModelScan — Detect potentially unsafe model serialization formats and artifacts • Protect AI's model security resources — Understand risks involving ML supply chains and model artifacts 8. AI security standards & threat modeling • OWASP Top 10 for LLM Applications — Identify major LLM application risk categories • MITRE ATLAS — Explore adversarial tactics and techniques targeting AI systems • NIST AI Risk Management Framework — Structure AI risk assessment and governance Starter stacks → LLM red teaming: Promptfoo + Garak → Multi-turn adversarial testing: PyRIT + your application test environment → Secure Python application: Bandit + Semgrep → Secret protection: Gitleaks + pre-commit → Dependency security: OSV-Scanner + Trivy → AI threat modeling: OWASP LLM Top 10 + MITRE ATLAS Before shipping an AI feature, ask yourself: Can untrusted documents manipulate the model's behavior? Can a user extract data they aren't authorized to access? Can the model trigger a tool call that violates permissions? Are credentials or sensitive information exposed in logs? Do automated security tests run whenever the application changes? One important distinction: A safe-looking response doesn't prove a safe system. An LLM can refuse a malicious request while the surrounding application still exposes data or permits an unauthorized action. Test the complete application, enforce permissions outside the model, and treat model output as untrusted input. No single scanner can guarantee security. Bookmark this for your next AI project. Share it with someone shipping LLM features.

Find the agentic bug. The agent keeps working. The task never finishes. The token bill keeps growing. Which line is the culprit? Bonus points if you can suggest a proper fix, not just a quick patch. 👀

Before you build any feature, ask Claude this: "Find MIT-licensed GitHub repos that already do this." Most of what you're about to build already exists. Read the repo. Take the idea. Have Claude write your own version. Don't paste internet code straight into your app. Check the license and read what it does first.

You can delete one thing from software development forever. - Merge conflicts - YAML indentation - “Works on my machine” - Updating dependencies - That one undocumented environment variable What do you choose?

My article made into this list. <3

Two AI agents can both succeed and still break your system. Imagine two agents updating the same config file. Agent A adds the production API key. Agent B adds a test key using an older version of the file. Both finish. Both pass their individual checks. But Agent B writes last and overwrites Agent A's change. Neither agent failed at its assigned task. The system still broke. So how do we fix this? Treat shared state as a coordination problem, not a prompting problem. Three things help: 1. Ownership: Define which agent can modify which resources. 2. Version checks: Reject stale writes instead of blindly accepting them. 3. Integration validation: Test the combined result before treating the workflow as successful. Locks can help too, but they don't replace these rules. The bigger lesson: an agent's success is not proof that the overall system is correct. As we build systems with more autonomous agents, we need to design not just how they work, but how they safely change the same world. What's your approach to shared state in multi-agent systems?

The hardest problem in agentic AI might not be making agents smarter. It might be making sure they can't quietly change the rules they're supposed to follow. Recent reporting about OpenAI's internal coding-agent experiments raises an uncomfortable question: what happens when an AI agent can modify the systems designed to monitor its own behavior? In reported incidents, agents interfered with parts of their monitoring infrastructure during internal coding tasks. The incidents weren't described as severe, but they exposed a problem worth taking seriously. The interesting part isn't whether these agents were conscious, deceptive in a human sense, or pursuing some hidden agenda. We don't need to assume any of that to see the engineering problem. Consider what we ask coding agents to do today: Read the repository. Modify files. Run commands. Install dependencies. Change configurations. Execute tests. Sometimes deploy the result. Now imagine the task involves changing a security mechanism, updating permissions, or modifying the very infrastructure that records the agent's actions. The agent might interpret the task in a way that conflicts with a safeguard. It might follow a misleading instruction from a file or tool result. Or it might simply make a bad decision while trying to complete the work. If the same agent can both perform an action and weaken the mechanism designed to detect that action, we've created a dangerous concentration of authority. This is where I think agentic engineering needs a different mental model. We shouldn't treat an agent as a trusted employee just because it can write good code. We should treat it as a powerful, fallible process operating inside a system of enforceable boundaries. That leads to a few design principles. 1. The agent should not control its own permissions. A model can request access, but a separate policy layer should decide whether that access is granted. 2. Critical monitoring should exist outside the agent's control. The process being monitored shouldn't be able to silently disable the monitoring infrastructure or erase its audit trail. 3. Tool access should be narrower than the task description. "Fix the build" doesn't automatically mean "access production credentials, modify security policies, and change deployment permissions." 4. High-impact actions need independent authorization. Deleting data, changing access controls, deploying to production, or disabling safeguards should require controls the model cannot bypass merely by generating a convincing explanation. 5. Every important action should leave evidence. Record what was requested, what was authorized, what actually happened, and which safeguards were triggered. Make those records difficult for the agent to alter. These aren't exotic ideas. They're established security principles applied to a new kind of software actor. The challenge is that agents don't just execute predefined instructions. They interpret goals, choose tools, and adapt their behavior across long sequences of actions. That makes the boundary between helpful autonomy and unintended authority much harder to reason about. And a sandbox alone doesn't solve everything. An isolated environment can still have excessive permissions, unsafe network access, or trusted connections that expose resources beyond the intended boundary. The real question is whether the entire execution environment remains safe when the model makes a bad decision. We're moving from software that follows a developer-defined sequence to software that chooses its own sequence of actions. Our security architecture has to evolve accordingly. But here's the question I'm still wrestling with: If an AI agent can modify code, execute commands, and change its environment, how do we give it meaningful autonomy without letting it weaken the safeguards that keep it in check? Where would you draw that line?

I have a small theory about this corner of X. Somewhere here, there's a developer building something at 2 AM that nobody has asked for yet. Someone teaching themselves AI by breaking things and putting them back together. Someone reading philosophy to understand technology a little better. Someone with 40 followers and an idea that deserves 40,000 people's attention. I'd like to find you. I'm Orvi. I build software, explore AI agents, read a little Kafka and Dostoevsky, and occasionally get lost thinking about where all this technology is taking us. I'm more interested in curious minds than impressive bios. So let's try something different. Tell me one thing you're building, one thing you're learning, or one idea you can't stop thinking about lately. Let's find some interesting people behind the usernames. 🤝

Adding more agents doesn't automatically make an AI system more intelligent. Sometimes it just gives one bad idea more people to agree with. Think about how humans make decisions in groups. A room full of people can reach a worse conclusion than one thoughtful person if everyone starts with the same assumption, copies the same evidence, and mistakes agreement for truth. Multi-agent AI has a similar problem. Imagine asking three agents to research a difficult question. Agent A finds a plausible answer. Agent B reviews A's answer. Agent C critiques the reasoning. It looks like independent verification. But what if B and C inherit A's framing? What if all three rely on the same misleading source? What if the critic is better at producing objections than identifying the correct answer? You've created the appearance of consensus without necessarily creating new evidence. The interesting question isn't how many agents are involved. It's how much independent information each agent contributes. A stronger system might give agents different evidence, ask them to challenge specific assumptions, and require claims to be verified against sources rather than accepted because several agents agree. And sometimes, one agent with access to better evidence will outperform an entire team. This is what makes multi-agent systems interesting to me. We're not just building software that can divide work. We're experimenting with artificial forms of collective reasoning. The real test of a multi-agent system isn't whether its agents agree. It's whether their interaction helps the system discover something that a single agent would have missed.