How I build

AI is how I build, not just what I build.

Claude Code is my main development tool. As the only engineer at a construction company, it's how one person ships 30+ internal tools in a year, and it's how this website was built too. The skill isn't typing prompts. It's scoping work so an agent can do it, checking what comes back, and deciding what an agent should never be allowed to do.

My daily loop

  • Scope: I write down the change, the constraints and how I'll know it works before any code exists.
  • Delegate: Claude Code implements it: reading the codebase, editing files, running the build and tests.
  • Verify: I review the diff, run it, and check anything version-sensitive against the real documentation.
  • Ship and own it: I deploy, watch it in use, and fix what breaks. The agent writes code; the outcome is still mine.

Where it goes wrong

AI tools confidently produce stale or invented APIs, especially on fast-moving Microsoft platforms like SharePoint Framework, PCF and the Graph SDK. I treat every output as a draft, test against the real service, and keep architecture and review in my own hands.

Guardrails

How I design agent systems

A person keeps the final step

My job-search agent drafts every application but can't submit one or send an email. That's a rule in the system, not a habit.

Hard limits the agent can't override

In my trading-desk experiment, agents debate trades, but a separate rule-based layer places orders and enforces risk limits the agents can't touch.

Private data stays local

The meeting assistant transcribes on my own GPU, so no audio goes to a third-party speech API.

Structured data, not guesses

Agents work best from stable identifiers and controlled vocabularies. I design the data first so an agent never has to infer what a free-text field meant.

Agent systems I've built

In practice

Let's build something.

I'm open to full-time and contract roles in AI/agent engineering, mobile, and full-stack TypeScript, remote or hybrid around NYC and Philadelphia.