I used Claude to build a self-hosted AI agent you can text on WhatsApp. Here's what that process actually looked like.

I'm a radiologist and AI Research fellow. Not a full-time software engineer.

I've been writing

Python for years but I've never shipped an opensource project alone.

Six weeks ago I started building Pincer — a self-hosted AI agent for

WhatsApp, Telegram, and Discord. Today I open-sourced it.

Claude was my co-coworker for the entire build. I want to share what

that actually looked like — not the "AI wrote my app" version, but the

real process.

Why security had to be the foundation

So as I mentioned, I work in radiology in field of AI research for medical and clinical use. Clinical AI systems, patient data, audit trails —

in that environment, "move fast and break things" is not a philosophy

you survive with. When software does something unexpected, the consequences

are real. That shapes how I build everything.

Most personal AI agent tools are built the opposite way: features first,

security bolted on later (if at all). OpenClaw — the most popular option —

had 341 malicious community plugins discovered in their ecosystem. Users

waking up to $750 surprise API bills. 40,000+ exposed instances. A

200,000-line codebase no individual can realistically audit.

I needed something I could actually trust. So I built it with three

non-negotiables from day one:

Accountability for every action.

Pincer logs every tool call, every

LLM request, every cost. Nothing happens silently. If the agent reads

your email or runs a shell command, there's a full audit trail. You can

see exactly what it did and why.

Sandboxed plugins with declared permissions. Community skills run in

subprocess jails. Each skill declares upfront which domains it's allowed

to contact — at runtime, anything outside that list is blocked. AST scan

before install. A malicious skill has nowhere to call and nothing to touch.

This isn't sophisticated — but a real barrier beats no barrier.

Hard cost limits, not soft warnings. Set PINCER_BUDGET_DAILY=5.00.

At 80% it auto-downgrades to a cheaper model. At 100% it stops. Not a

notification. Not a dashboard to check. A hard stop in the architecture.

No one should get a surprise bill from software running on their behalf.

And everything stays on your hardware. Local SQLite, no telemetry, no

cloud dependency. You can grep your own memory. You control the data

entirely.

What Claude actually contributed to this

Architecture review was where Claude earned its keep. Before writing a

line, I'd describe a design decision and ask it to steelman the

alternatives. The subprocess-vs-Docker sandboxing debate, the

FTS5-vs-vector-DB memory question, the async multi-channel architecture

— in each case Claude surfaced tradeoffs I hadn't considered and helped

me reach a decision I could defend. Not by giving me the answer, but by

making the problem clearer.

Security review was the other high-value use. Before shipping any

security-sensitive component, I'd run it through a prompt like:

"Here is my subprocess sandboxing implementation. You are a security

researcher trying to bypass it. What are the attack vectors?"

It found two real issues I'd missed. Both fixed before launch. I'd

recommend this to anyone shipping code that has security implications —

Claude is a genuinely useful adversarial reviewer.

Debugging through unfamiliar internals. The WhatsApp integration (neonize)

broke twice during development — it reverse-engineers the multi-device

protocol and WhatsApp pushes updates. Both times Claude helped me trace

the problem through library code I'd never written faster than I would

have alone.

What still required me

Judgment calls are always yours. Claude gives you options. Choosing

between them — based on your constraints, your risk tolerance, what

you know about your own system — that's not something it can do for you.

Knowing when the output is wrong. Occasionally Claude produces code that

looks right and isn't — subtle async bugs, edge cases in sandboxing logic.

You need to understand the domain to catch these. Vibe coding without

comprehension is how you ship security vulnerabilities.

The security philosophy itself. Claude can implement a sandbox. It can't

decide that sandboxing matters, or why, or where the threat model starts

and ends. That came from working in an environment where I've seen what

happens when software isn't accountable for its own behavior.

The result

~7,800 lines of Python (core agent). Every file with a single clear purpose. The whole

codebase readable in an afternoon — because if you're going to let software

read your email and run commands on your server, you should be able to read

all the code that governs it.

Setup is four environment variables and docker compose up. Running in

under five minutes.

https://github.com/pincerhq/pincer

https://pincer.sh/docs

If the security-first self-hosted angle resonates with you — a star or

a watch on the repo means a lot for a solo project. And if you want to

contribute, there are labeled issues open. All skill levels welcome;

the codebase is intentionally small enough that new contributors can

actually understand it.

Curious how others in this community are using Claude for security-

sensitive development. Particularly the adversarial review approach —

has anyone else found that useful, and how do you structure those prompts?