Work

AI Agent Chat - Slack-First Engineering Assistant

Status: Deployed in private production environment

Designed and built an AI workflow assistant to streamline engineering operations inside Slack.

Role and ownership

Owned architecture and implementation end-to-end, from API design and workflow orchestration to deployment and security hardening.

Timeline

Built from scratch and promoted through staged execution modes from intake-only behavior to active workflow automation.

Problem

Engineering teams often split context across chat, pull requests, CI logs, and ad hoc notes, which slows execution and creates visibility gaps.

What I built

A Slack-first assistant that captures ideas and tasks, opens GitHub draft PRs from Slack messages, monitors CI status, gates merges behind passing checks, summarizes failed checks with AI, and supports freeform GPT-4o conversations.

Security design

• Verified all Slack and GitHub webhook endpoints with HMAC-SHA256 signatures
• Blocked replay attacks with a strict 5-minute timestamp validation window
• Disabled API documentation routes in production deployments
• Applied prompt-injection hardening so user input cannot override system instructions
• Enforced per-task LLM spend caps to prevent runaway cost events

Key engineering decisions

• Event deduplication cache prevents duplicate responses from Slack retry behavior
• Two-layer routing separates deterministic command workflows from freeform LLM chat
• Execution-worker budget guardrail halts runs before exceeding cost thresholds
• Execution modes (intake_only, simulate, apply) support safe progression from observer to active editor

What this shows

• Production-minded AI workflow engineering with strong operational controls
• Ability to integrate LLMs into deterministic software systems without losing reliability
• Applied security and cost governance in real deployment conditions

Tech stack

Python 3.12, FastAPI, SQLite, GitHub REST API, Slack Events API, Slack Slash Commands, Slack Interactions API, OpenRouter (GPT-4o), Render

Public artifact

The sanitized architecture above documents the system boundary and implemented guardrails described here; it is not independent production verification. The deployment remains private, and a deeper implementation walkthrough is available in an interview or portfolio review.

Back to top

Flowtrack - Local-First AI Productivity

Status: Active build

Built a local-first productivity tracker that uses AI-assisted dashboard behavior without requiring cloud account dependency.

Role and ownership

Owned product and engineering delivery across backend logic, AI integration points, and user workflow design.

Problem

Most productivity tools depend on cloud-heavy workflows even when users only need fast local control and privacy-first behavior.

What I built

A local-first tracker with AI-assisted dashboard interactions designed for low-friction daily use.

What this shows

• Product engineering beyond a single AI niche
• Ability to design around privacy and practical user constraints
• Execution from idea to usable product workflow

Tech stack

Python, local storage patterns, AI integration workflows, product UI iteration

Back to top

Tenslam Gym

Status: Live / prototype / actively developed

Real-time AI personal trainer Android app using pose estimation, posture correction, rep counting, Firebase, and computer vision.

Role and ownership

End-to-end ownership across CV logic, app behavior, and product loop.

Timeline

Active build phase, iterating through production-minded prototypes.

Problem

Most fitness apps record activity, but do not help users understand movement quality while they are training.

What I built

An Android prototype that detects pose in real time, tracks reps, and gives feedback on posture and movement execution.

Current evidence

• Latency envelope for on-device feedback loop
• Rep-count reliability on selected movement classes
• Failure conditions: occlusion, camera angle, and tempo changes

What this shows

• Applied computer vision in a user-facing product
• Real-time feedback loops under mobile constraints
• Bridging model output to useful product behavior

Tech stack

Android, Kotlin/Java, MediaPipe, Firebase, Computer Vision, Pose Estimation

Public evidence

Demo walkthrough and architecture brief available on request during private iteration.

Back to top

Tenslam Vision Motion Engine

Status: In development

A video-to-skeleton motion intelligence system for fitness, sports, digital twins, and physical AI.

Role and ownership

Owned architecture and implementation across data representation and pipeline behavior.

Timeline

Core pipeline phase with ongoing representation and quality improvements.

Problem

Raw video is easy to store but hard to use in downstream systems that need structured motion data.

What I built

A pipeline that extracts human movement signals from video and turns them into structured motion features.

Current evidence

• Landmark stability under camera and lighting variation
• Feature extraction consistency across repeated clips
• Downstream usability for analytics and feedback products

What this shows

• Designing structure from noisy real-world video input
• Thinking beyond demos toward reusable motion infrastructure
• Connecting vision pipelines to downstream product use cases

Tech stack

Python, Computer Vision, Pose Estimation, OpenCV, AI, Digital Twins

Current signal

Pipeline and representation quality are under active validation for wider release.

Back to top

Local LLM Learning Lab

Status: Learning / experiments

Experiments running and fine-tuning small open-source language models locally on Ubuntu with limited hardware.

Role and ownership

Independently designed and executed local inference experiments under constrained hardware.

Timeline

Ongoing applied research cycle focused on practical deployment tradeoffs.

Problem

I wanted to understand the practical limits of local inference and how model size, quantization, and memory constraints affect real usage.

What I built

Small-scale local inference and fine-tuning experiments on consumer hardware.

Current evidence

• Tokens-per-second across selected model sizes and quantization levels
• Memory and VRAM usage by configuration
• Usability thresholds for local-first product workflows

What this shows

• Curiosity grounded in hardware and system constraints
• Hands-on understanding of quantization, memory, and inference tradeoffs
• Practical evaluation instead of abstract model hype

Tech stack

Python, PyTorch, Hugging Face Transformers, Linux, LoRA, Qwen

Current signal

Selected notes are published in Writing while benchmark summaries are still in progress.

Back to top

Django + Next.js Product Systems

Status: Multiple prototypes

Full-stack product experiments with REST APIs, authentication, dashboards, wallets, and MVP deployment.

Role and ownership

Owned backend API design, frontend integration, deployment path, and delivery scope.

Timeline

Multiple build cycles across different product hypotheses.

Problem

Many ideas need a fast path from backend logic to a usable product surface.

What I built

Product prototypes that combine Django APIs with a modern frontend and deployable infrastructure.

Current evidence

• MVP delivery time from idea to deployable build
• API surface and reliability checks used during iteration
• Feature-to-feedback loop speed in prototype cycles

What this shows

• Ability to move from backend logic to usable product surfaces
• End-to-end ownership across APIs, frontend, and deployment
• Bias toward shipping MVPs instead of isolated code exercises

Tech stack

Python, Django REST Framework, Next.js, React, PostgreSQL, Firebase, Koyeb, Vercel

Current signal

Selected implementation breakdowns are available and being consolidated into cleaner public case studies.

Back to top

AI Research Platform Experiments

Status: Research / product engineering experiments

Experiments around AI agent workflows, observability, token control, structured logging, API governance, retries, and reliability.

Role and ownership

Designed and implemented workflow orchestration experiments with reliability as a first-class goal.

Timeline

Iterative platform experimentation aligned to practical AI product operations.

Problem

AI systems need more than prompts; they need predictable, observable, and debuggable orchestration.

What I built

Workflow experiments focused on failure handling, telemetry, and operational clarity.

Current evidence

• Failure-mode taxonomy and retry behavior under common error classes
• Tracing and logging coverage for debugging and incident review
• Token and cost control patterns for repeatable operations

What this shows

• Systems thinking around reliability, observability, and control
• Interest in the engineering layer around AI, not just model calls
• Comfort working on product-facing infrastructure problems

Tech stack

Python, FastAPI, LangGraph-style workflows, logging, APIs, dashboards

Current signal

Internal reliability notes and architecture patterns are being condensed for public release.

Back to top