AI Engineering
AI fluency isn't a resume line — it's the operating layer. Three production uses, each producing something concrete: a 100K-line Stanford platform built in 24 hours, MCP-based sales prospecting at JointCommerce, and an AI-assisted engineering standard for a 15-person team.
Four coding co-pilots, used every day.
These are the tools I open before email. Different strengths, redundant where it matters, used in rotation across daily JointCommerce engineering, Causal IQ automation work, and every project in the R&D lab.
Claude Code
Anthropic- Used to build the Stanford BIOE 230 platform — 100K lines in 24 hours
- Daily JointCommerce engineering and Causal IQ Python automation work
- MCP integration for sales prospecting workflows
Codex
OpenAI- Secondary code generation when an alternate perspective helps
- Cross-validation with Claude Code for tricky refactors
- Fallback for tasks where Claude struggles to land the change
Cursor
Anysphere- IDE-native AI pair programming — in-context across the file you're editing
- Multi-file refactoring with project-aware context
- Tab-completion and inline suggestions while writing code
Copilot
GitHub- Inline suggestions at commit-by-commit cadence
- Repository-aware context across pull requests and branches
- Used alongside Cursor for redundancy — two heads on each line
What ships in the product, not just the dev workflow.
AI in the dev loop is table stakes. AI in the user's hands — with streaming responses, structured outputs, and cost-aware model routing — is what makes the work production-grade.
Vercel AI SDK + Gemini
Powers the Stanford BIOE 230 contextual tutor. Streaming responses, structured outputs, and cost-optimized model routing so the platform answers student questions in real time without runaway inference cost.
Anthropic + OpenAI APIs
Production model orchestration at JointCommerce. Multi-model strategy for cost/quality tradeoffs — Claude where reasoning matters, GPT where it fits, fallback paths when either is degraded. Prompt engineering at scale.
Model Context Protocol
MCP-based sales prospecting workflows at JointCommerce. LLM agents match prospect data against ICP targeting parameters in an agentic loop: discover → score → surface → route to outbound.
Shipped artifacts, not slide decks.
The same AI stack, applied three different ways. Each one produced something concrete — a live platform a Stanford department adopted, an automated sales workflow inside a 15-person agency, and a team-wide engineering standard.
Stanford BIOE 230 in 24 hours
Professor Coleman needed an interactive learning platform for his Spring 2026 course. I scoped, built, and shipped it in 24 hours — 100K lines covering 180 D3.js visualizations, a contextual AI tutor, 960 practice problems, and a PWA install path.
- Stack: Claude Code for engineering, Next.js 16, D3.js, Vercel AI SDK with Gemini for the tutor, TypeScript, Tailwind, shadcn/ui
- Outcome: Adopted by Stanford Bioengineering for Spring 2026; department-wide rollout in progress with other professors picking it up
- Why it matters: Real users (graduate students), real evaluation, real institutional buy-in — not a demo
MCP sales prospecting at JointCommerce
The sales team needed faster ICP-matched lead generation. I built an MCP-based agentic workflow where LLM agents pull prospect data, match it against ICP targeting parameters, score the fit, and surface the highest-confidence accounts for outbound — daily, automatically.
- The loop: Discover prospects → score against ICP parameters → surface high-fit accounts → route to outbound
- Outcome: Reduced manual list-building time and tightened the account focus for outbound reps
- Why it matters: Production agentic work inside a 15-person company — not a hackathon project
Daily AI-assisted engineering as a team standard
At JointCommerce, AI-assisted development became the team-wide operating standard — not an experiment. Engineering and ops teams used Claude Code, Codex, Cursor, and Copilot daily, with shared workflow templates and a prompt library that anyone could pull from.
- What changed: Workflow templates and prompt libraries shared across the team so the leverage compounded
- Outcome: Productivity multiplier on a 15-person team without proportional headcount growth — how a small team managed 200+ accounts at 85% margins
- Why it matters: Tool adoption is the easy part. Workflow integration across a multi-discipline team is the hard part
Listing tools is easy. Shipping with them is the work.
Most candidates list AI tools in skills. I've shipped production work with these tools and made them an operating standard for a team. The difference matters.
Tool adoption isn't the same as workflow integration.
AI fluency is verified by shipped artifacts, not certifications.
MCP and agentic workflows are early — but production-ready when scoped well.
What AI does well, and what it doesn't replace.
AI is a force multiplier, not a replacement for engineering judgment. The candid version — because the gap between "uses AI" and "ships with AI" only narrows when you're honest about both sides.
What it does well
Rapid prototyping from a clear spec, scaffolding boilerplate at scale, refactoring across files when the pattern is consistent, and translating intent into a first draft fast.
What it doesn't replace
Production debugging where the bug is a cross-system race condition, system design judgment when the tradeoffs are organizational, and domain expertise you only build by running the operation yourself.
How I use it
As a force multiplier on the work I already understand. AI compresses the time between idea and working code. It does not compress the time between working code and a system that survives contact with real users.