AI features inside real product workflows
AI is a supporting capability in my product-engineering work, not a separate professional identity. I use it when a specific workflow benefits from voice interaction, drafting, retrieval, or structured automation, then build the interface, fallbacks, and operational controls around that behavior.
- Define the user task before choosing a model or interaction pattern
- OpenAI Realtime and Twilio voice flows with measured latency
- Tool calls and structured outputs for actions inside the product
- Human review and handoff for actions that should not be automatic
- Product states for latency, failure, uncertainty, and retry behavior
- Cost and usefulness signals that can be reviewed after release
Where this capability shows up in the work.
- 2026Phone Assistant: voice-support demoA working OpenAI Realtime and Twilio demo for FAQ resolution, call routing, ticket creation, and human handoff. The current build records 640 ms median and 880 ms P95 turn latency.OpenAI RealtimeTwilioNext.jsPostgres
- 2025CVLeap AI: assisted resume editingPlaced AI assistance inside a resume-editing workflow with onboarding, account state, storage, and PDF export rather than presenting a separate generic chat surface.Next.jsOpenAISupabaseTypeScript
- 2026Scheduler: publishing workflow in developmentAn in-progress product exploring assisted drafting and channel-specific formatting. The editor, review states, and scheduling model are still being developed.Next.jsOpenAISupabase
The interface around the model determines whether the feature is usable.
Model output is only one part of the product. Users also need to know what the system is doing, how long it may take, what they can edit, and what happens when the result is incomplete or wrong.
I design those states alongside the integration. For voice, that includes latency and handoff behavior. For drafting, it includes review and revision. For tool use, it includes confirmation and a clear fallback when the action cannot complete.
Scope, evidence, and how I apply this work.
Are you positioning yourself as an AI or machine-learning engineer?
No. I am a product engineer with hands-on experience implementing AI-assisted workflows. My strongest layer remains the product interface and frontend architecture around the feature.
Is the Phone Assistant running in production for a customer?
It is a demo-ready independent build, not a claimed customer deployment. It demonstrates the full call flow, operations interface, latency measurements, ticket creation, and human handoff.
When is AI a poor fit?
When a deterministic rule can solve the task more cheaply and predictably, or when the product cannot tolerate uncertainty without a review step. I would rather narrow or remove the AI portion than force it into the product.
What can you own on an AI feature?
The user workflow, interaction states, frontend, model/API integration, tool calls, fallbacks, and measurement hooks. Specialist model training or advanced ML infrastructure would need a dedicated engineer.
Tell me where the workflow is stuck.
Share the product, the people using it, and what needs to become easier or faster. I will tell you whether my product and frontend experience fits the problem.