Case Study · AI Application Engineering
Ask A.J. demonstrates how AJ designs intelligent, resilient user experiences from product framing through server-side AI integration, streaming UI, safeguards, and graceful degradation.
It is not a generic chatbot. The browser receives an application-owned NDJSON event stream, while TanStack Start server code owns secrets, validation, model calls, fallback behavior, and structured logs.
The implemented system is intentionally small: a React conversation interface, a TanStack Start server route, curated approved context, OpenAI Responses API streaming, layered fallbacks, and a server-side recruiter contact flow. Future RAG, vector search, LangGraph, MCP, and persistent conversations are roadmap items, not current claims.
Architecture flow
The successful path from recruiter question to streamed answer. The browser receives application events, not raw provider objects.
The React interface captures the question, preserves native form behavior, and supports Enter to send with Shift + Enter for a newline.
The TanStack Start API route reads limited JSON, validates the request shape, checks origin, rate limits, and duplicate in-flight questions.
Server code constructs approved instructions and context, calls the OpenAI Responses API with store:false, and translates provider deltas into NDJSON message.delta events.
The browser parses NDJSON, updates status and answer text progressively, handles aborts, and announces completion for assistive technology.
Architecture flow
Before giving up, the server tries bounded recovery paths that keep user-facing errors safe and understandable.
Content type, body size, schema, origin, rate-limit, and duplicate-request checks reject unsafe or noisy requests before provider work begins.
The primary OpenAI model gets a bounded timeout and transient retries for retryable provider statuses before the first text delta.
Eligible failures move to a fallback model, then curated cached answers, then a static graceful fallback if no cache match exists.
Circuit breaker state, structured logs, safe user errors, and abort handling keep failures diagnosable without exposing secrets or raw provider internals.
Architecture flow
Recruiter contact stays server-side, validates the form, and sends through Resend with the recruiter's email as reply-to.
The integrated contact form validates name, work email, optional role/company, message, and a hidden honeypot field.
The contact API parses the payload, applies local rate limiting and duplicate-submission protection, and loads server-only email configuration.
Resend sends from the verified server-owned sender to AJ's configured inbox with the recruiter's email set as replyTo.
The UI shows accessible success or safe error messaging without exposing provider diagnostics or recruiter message content.
The decisions below are visible in the current implementation: server-only provider calls, streamed NDJSON, bounded provider recovery, Storybook documentation, semantic tokens, and keyboard behavior that matches modern AI tools.
Why
Provider keys, instructions, request validation, token limits, and fallback behavior belong behind the TanStack Start boundary.
Tradeoff
The browser cannot call the model directly, so the server route has to own streaming translation and error handling.
Result
The client receives only application-owned stream events and never sees secrets, raw provider events, or protected instructions.
Why
A recruiter should see progress quickly, and the UI should own stable events rather than provider-specific payloads.
Tradeoff
The client must parse partial chunks safely and handle malformed stream events.
Result
Ask A.J. can show waiting, writing, completion, abort, and error states with one browser-facing contract.
Why
A credible AI product needs useful behavior when the primary provider path is slow, rate limited, or unavailable.
Tradeoff
Cached and static answers are narrower than live generation and must not pretend to be retrieval.
Result
The system can degrade from primary model to fallback model to curated answer to static fallback without fabricating citations.
Why
Streaming, waiting, error, aborted, long-content, mobile, and contact states are hard to reason about from a single happy path.
Tradeoff
Stories add maintenance overhead when the UI contract changes.
Result
The important visual states are deterministic, independently renderable, and safe from real network calls.
Why
The contact form success state should communicate completion without borrowing the site's coral-red accent or warning tone.
Tradeoff
The design token surface grows slightly.
Result
Success, error, accent, and neutral states now have clearer visual roles in light and dark themes.
Why
Enter to send and Shift + Enter for a newline are now expected in AI chat composers.
Tradeoff
Textarea key handling must respect native forms, pending states, and IME composition.
Result
Ask A.J. and the contact message textarea submit predictably while preserving multiline input and accessibility.
Interview the engineer
Start with Ask A.J. to explore AJ's work, architecture decisions, and engineering philosophy before the first conversation. The experience is both a recruiter tool and a working demonstration of his software judgment.
Start with Ask A.J.Ask A.J. starts from a recruiter problem: understanding AJ's judgment quickly. The model integration exists to serve that product moment, not to prove a tool choice.
The model generates language, but the application owns validation, permissions, context, output limits, fallback behavior, and the user-facing contract.
The interface preserves labels, status announcements, keyboard submission behavior, reduced-motion support, safe focus return, and readable long-form answers.
Storybook documents deterministic states for streaming, waiting, long content, mobile sticky behavior, contact success, validation, and error handling.
Retries, fallback model behavior, cached answers, static fallback, circuit breaking, rate limits, request guards, and safe errors are part of the current implementation.
AJ's enterprise design-system experience shows up in the portfolio platform through reusable components, semantic tokens, consistent states, and accessible interaction patterns.
These are implementation milestones from the current repository and project notes, intentionally shown without fake dates.
Ask A.J. became the flagship way to explore AJ's work, positioning, and engineering philosophy through a product experience.
The UI gained NDJSON parsing, visible waiting and writing states, abort behavior, long-answer rendering, and follow-up conversation support.
Provider calls, instructions, output limits, retries, fallback model behavior, and safe provider errors moved behind TanStack Start server code.
Request guards, rate limiting, duplicate protection, cached/static fallback answers, circuit breaking, and structured logging were added.
The contact form now validates locally and server-side, sends through Resend, and uses the recruiter's email as reply-to.
Storybook coverage, semantic success styling, mobile wrapper fixes, keyboard behavior, and this architecture case study make the product easier to inspect.
These are repository-verifiable signals, not live operational metrics. The product does not claim uptime, conversion, latency, token-cost, or accessibility scores that are not measured here.
React and TypeScript presentation components render the recruiter experience.
TanStack Start server routes own secrets, request validation, provider calls, and NDJSON framing.
The browser receives only application-owned stream events, never provider-specific events.
The contact form is server-only and sends through Resend with the recruiter's email as replyTo.
In-memory rate limits and circuit state are no-cost MVP safeguards, but they are per server instance.
Cached answers reduce failure impact for common questions, but they are not a replacement for retrieval.
The current knowledge source is curated content, not vector search or embeddings.