The art of refining the complex into the intuitive.
I'm James Huschle — 25 years of Fortune 500 technology leadership, now applied to cloud architecture, machine learning, and AI-native systems. I've managed engineering teams, built greenfield platforms, and delivered on roadmaps that crossed departments, continents, and budget cycles. The rarest thing in technology isn't technical skill — it's someone who can translate fluently between the engineering team and the people writing the checks.
"Syntactic sugar" is a programming term for a layer of elegance added to a language — it doesn't change what the machine can do, but it profoundly changes how the human feels working with it. That idea sits at the center of everything I build. Technology should be intuitive. Systems should make sense to the people who fund them, build them, and use them.
We are at an inflection point that rewards an unusual combination of skills. Large language models are, at their core, the marriage of computation and language — and applying them to real business problems requires someone who understands all three fluently. I didn't pivot to this moment. I've been building toward it for 25 years.
I came to technology through an unusual door: a BA in English, a BS in Computer Science, and an MBA from the Carlson School at the University of Minnesota. That combination wasn't accidental. Language shapes how people understand systems. Business shapes which systems are worth building. Engineering determines whether they hold together under pressure.
At IBM I built tools that crossed international development teams and localization pipelines. At St. Paul Companies and Travelers I spent 15 years moving from systems engineer to Senior IT Director — managing organizations of 25 engineers, delivering $4.5M–$11M programs, rolling out platforms to 25,000 users across global operations. Since 2023 I've been building with the current generation of tools: serverless AWS architecture, ML pipelines on SageMaker, and AI-native systems that go well beyond chatbot wrappers.
If you need someone who can sit in the architecture review and the budget meeting and the engineering standup and speak credibly in all three rooms — that's the job I've been doing for 25 years.
These projects represent hands-on work from the last few years — built independently, architected from scratch, and deployed to real infrastructure. I'm releasing them publicly over the next month or two as I get each one to a standard I'm comfortable putting my name on. Two are live. One is open source with no hosted demo. One is coming.
Serverless ML-powered learning — built to understand meaning, not match strings.
A web application that turns terminology-heavy subjects into interactive learning experiences. Users define a knowledge domain and its terms; the system evaluates answers semantically — understanding what you meant, not just what you typed — using a custom cross-encoder model quantized for low-latency inference without a PyTorch dependency.
The architecture is a six-stack AWS CDK deployment — network, database, auth, backend, frontend, and monitoring — each independently deployable. Auth runs through a custom Cognito registration gate with pre-signup Lambda approval. CI/CD via GitHub Actions includes security scanning on every push: Bandit, Checkov, TruffleHog, and pip-audit.
If you'd like to explore it, you can register for an account at the link below. Accounts aren't provisioned automatically — registration lands in a review queue and access is granted manually. Why the gate? Two reasons, both honest: bots are a real nuisance, and the free-tier cost model depends on keeping traffic predictable. Automated signups solve neither problem and create new ones. So a human reviews each request. If you're a real person who wants to poke around, you'll hear back.
Paste text. Get an audiobook. The API is serverless in Oracle Cloud Infrastructure (OCI); the GPU is a home-lab box — wired together by a WireGuard tunnel and a webhook.
A hybrid cloud/on-premises audiobook service. The interesting part isn't the conversion — it's the architecture that makes a serverless cloud function and an on-premises GPU cooperate seamlessly across the internet. When a job is submitted, an OCI Function stores it and immediately POSTs a webhook to a worker running in a home-lab Kubernetes (k3s) cluster, delivered over a WireGuard VPN that routes through an OCI ARM instance. The worker claims the job, chunks the text, and runs inference locally using an open-source English Text-to-Speech (TTS) model (Qwen3-TTS-12Hz-1.7B-Base at 1.24% WER on the Seed-TTS benchmark, for those who care about such things). The result lands in OCI Object Storage as a downloadable Opus file.
Push for speed, poll for reliability. The webhook wakes the worker immediately; a 10-second polling loop runs as a fallback in case the webhook is missed. Either path arrives at the same place.
JSON Web Token (JWT) verification happens inside the OCI Function without an outbound network call — Cognito's public keys are embedded directly in the function, which matters when running in a private subnet with no internet gateway. Text preprocessing strips the artifacts PDF extraction leaves behind (citation brackets, DOI strings, footnote markers) before chunking, so the audio sounds like a human read it.
Same account gate as Know-It-All Tutor — and the same account works for both. Registration lands in a review queue and access is granted manually. If you're a real person who wants to try it, register once and you're in on both apps.
A distributed IoT and edge AI system — inference runs where the data is, not in the cloud.
63 milliseconds end-to-end — from motion detected to alert delivered — on local hardware with no cloud service in the loop. The cloud alternative is 500ms to two seconds and roughly $100/month per camera at scale, with your video stream on someone else's infrastructure. Edge AI makes that happen.
The system is three tiers. ESP32-S3 microcontrollers handle the camera layer: custom firmware manages JPEG streaming, MQTT (Message Queuing Telemetry Transport) control over TLS, and over-the-air (OTA) firmware updates. A Jetson Orin Nano handles inference — YOLOv8n person detection at 8ms per frame on CPU, InsightFace face recognition at 15ms per frame on GPU. A workstation runs the command module: FastAPI, LangGraph state-machine orchestration, and PostgreSQL with pgvector for face embeddings.
The IoT engineering is where the depth is. Cameras self-register on boot — no manual provisioning. Commands carry nonces with an 8-minute replay window, so the cameras can't be spoofed by a replayed packet. Over-the-air updates use versioned firmware channels per board type; cameras poll on boot and every five minutes, checksum-verify before applying. The same patterns you'd build in an industrial deployment, on $200 of hardware.
One interesting engineering lesson actually came in the form of a failure. The original design ran TFLite inference on each ESP32-S3 as a detection gate — true AI at the bleeding edge in the microcontroller layer, only transmitting frames when something was moving. That didn't survive contact with the hardware and only delivered 0.6 fps — too slow for a gate. The solution was to move that inference to the Jetson. The lesson: edge AI isn't about pushing inference as close to the sensor as possible. It's about matching the compute requirement to the hardware that can actually deliver it. Microcontrollers handle networking and streaming. The Jetson handles computer vision. That's the right split.
There's no live demo — the production system runs on my home network with my family's biometric data. That's the point. The code is the portfolio piece.
A local-first knowledge pipeline with anonymous search, LLM-assisted triage, and human review — wired via Model Context Protocol.
Source available on GitHub at release.
These are the problem spaces I keep coming back to — the intersections where technical depth and organizational complexity get interesting at the same time.
The opportunity isn't chatbots. It's systems that act — that reason across tools, data sources, and workflows in ways that actually change how work gets done. What draws me to this space is the genuine novelty of it: for the first time, the distance between "what a system can do" and "what a business needs" is being closed by language, not by more code. The problems here are mostly still unsolved, which is exactly why I keep building.
Large language models are the first technology in decades that rewards linguistic fluency, engineering depth, and business judgment simultaneously. That intersection doesn't feel accidental to me — it feels like what I've been building toward.
Serverless and distributed systems design appeal to me partly for the technical elegance, but mostly for what they force: you have to think clearly about boundaries, ownership, and failure modes before you write a line. I hold current AWS certifications in solutions architecture and machine learning and keep building hands-on because the only way to have real opinions about infrastructure is to run it.
The problems I find hardest — and most interesting — are the ones where the technical answer is obvious and the organizational answer isn't. Rebuilding a platform a business depends on, without stopping the business, requires thinking in organizational physics as much as systems design. I've run programs like this and I still find the problem genuinely fascinating.
The place I've always felt most useful is between what a technical team is actually building and what leadership thinks they're buying. That gap is expensive when it's wide. I find the problem interesting enough that I've spent 25 years trying to close it — and I still don't think it gets enough deliberate attention.
Whether you have a role in mind or just want to connect, I'm happy to have the conversation.