Building Reliable AI Features in TypeScript
Treat the model as an engineering dependency through schema-validated outputs, evaluations in CI, evidence-based model selection, and production tracing.
Full day · Half-day version available
TypeScript engineers building AI features that need to move from plausible demos to dependable product behavior.
Comfortable with TypeScript and model APIs; no machine-learning background needed.
Getting a model to answer is easy. Shipping an AI feature you can change without guessing is the real work. AI engineering begins after the first successful model call: when output needs a contract, prompt changes need tests, models need evidence-based selection, and production failures need a trace.
The model is an engineering dependency with unfamiliar properties. Its output is probabilistic, usage is priced per token, providers update it, and failures can arrive in a perfectly plausible shape.
In this hands-on workshop, we start with a TypeScript feature that works in the demo and fails like production. We then add each layer in turn: schema-validated output, an evaluation suite, deliberate context, model comparison and routing, production tracing, and a release gate.
By the end, every prompt or model change has evidence behind it before it ships, and every production failure leaves enough information to investigate.
Define AI engineering at the application layer, distinguish AI-enhanced engineers, engineers building AI products, and engineers building autonomous agents, and establish that this workshop trains the second. Map the path from demo to feature to product, then run the seeded feature and record the evidence it lacks before changing any code.
Break the seeded feature on purpose and catalogue malformed output, hallucination, refusal, format drift, and prompt injection.
Use Zod schemas, structured tool calls, fail-closed validation, bounded retries, and typed streaming so malformed answers are rejected instead of rendered.
Build a golden set, deterministic assertions, calibrated automated grading, counter-examples, and one suite that compares model quality, cost, and latency.
Decide what earns a place in the context window and manage retrieval, compaction, memory, per-request cost, and latency as explicit design choices.
Turn evaluation evidence into routing policy, trace every call, monitor provider drift, defend against injection, and investigate incidents by adding failures back to the suite.
Take one feature from a fragile demo to a release-gated implementation whose output is schema-valid, evaluated, budgeted, and traceable.
Athens · 21–23 October 2026
View the CityJS workshopTell us what your team is working with and what should be different afterwards.