Back to blog
11 min readEN

Frontend to frontend+AI: a 3-step field guide — learn, build, prove

Adapting is not optional. The job title didn't change, but the job did: frontend postings in 2026 still say "Angular" or "React" — and then they say "experience integrating LLMs", "familiarity with RAG", "comfortable working with AI tooling". If some of those words mean nothing to you yet, good — this guide explains every one of them, starting with the first: an LLM (large language model) is the technology behind ChatGPT and Claude — a model that reads and writes text, which you use in your app through an API. The numbers behind the shift are loud: postings for agentic AI — systems that don't just answer, but take steps and use tools on their own — grew 280% in one year, reaching roughly 90,000 open roles in the US alone, with AI Engineer ranked the fastest-growing job title (Stanford AI Index). There are more openings than engineers able to fill them.

You can read that as a threat or as an opening. This guide treats it as an opening, and organizes the whole transition into three steps: learn what actually matters, build projects that exercise it, and prove it with public evidence.

The market moved (and what it actually means)

Two things are true at once. First: simple UI assembly is getting cheaper. An AI can scaffold a form, a card grid, a landing section in seconds — the part of frontend that was "translate the mock into components" is being automated, and no honest analysis pretends otherwise. Second: frontend is not dying. The hard parts — state, accessibility, performance, browser reality, product trade-offs — are exactly the parts a prompt can't decide.

What changed is where the value concentrates. Industry surveys put AI-tool adoption around three in four developers, and "AI literacy" is heading the way of Git: not a differentiator, a baseline. The engineers in demand aren't the ones who type fastest; they're the ones who can integrate AI into products and supervise AI output with judgment. That's the widened profile — and frontend engineers are better positioned for it than most believe.

AI doesn't replace the frontend engineer. It replaces the frontend that only assembles UI. Judgment doesn't automate.

The profile companies are hiring for

Name it precisely, because the confusion costs people years: the market is not asking frontends to become ML engineers. Training models, fine-tuning, GPU pipelines — that's a different career. What postings call "AI engineering" is product-side AI: consuming models through APIs and turning them into features that work. The shift looks like this:

Frontend 2020 Frontend+AI 2026
Core craft Components, state, CSS Same — that doesn't go away
Data layer REST/GraphQL + LLM APIs, streaming, structured outputs
Hard UX Forms, tables, loading + chat, uncertainty, partial results
Backend touch Optional + serverless proxies, tool execution, RAG
Quality bar Tests, types, a11y + evals: tests for output that varies
Daily tooling IDE, Git, DevTools + coding agents, used with judgment

And the under-appreciated fact: half the value of an AI product is UX. Streaming that feels alive, states for "the model is thinking", graceful failure when it hallucinates (states things that aren't true, with full confidence), interfaces for correcting it — that's frontend work. Frontend isn't late to this field; it owns a critical piece of it.

Step 1 · LEARN what actually matters

The study path, in order. Each piece is small; the sequence compounds.

LLM APIs and serious prompting

Everything starts with calling a model — Claude or OpenAI, the mechanics transfer. Learn what a system prompt is (the standing instructions that set how the model behaves), how context windows work (the limit on how much text the model can consider at once), what temperature changes (the dial between predictable and creative output), and why prompts are code (version them, review them). One architectural rule is non-negotiable from day one: the API key never touches the browser. The frontend calls your endpoint — a serverless function is enough: a small piece of backend you deploy without managing a server — and that endpoint calls the model.

The UX of AI — where frontend plays at home

The highest-leverage skill on this list, because it's the one a frontend already half-has. Users won't wait 20 seconds staring at a spinner: you stream the response and paint it as it arrives. This is the pattern, end to end — a fetch, a ReadableStream, a signal:

// chat.service.ts — stream tokens from YOUR backend (the API key never leaves it)
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class ChatService {
  readonly reply = signal('');
  readonly streaming = signal(false);

  async send(prompt: string) {
    this.reply.set('');
    this.streaming.set(true);
    try {
      const res = await fetch('/api/chat', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ prompt }),
      });
      const reader = res.body!.getReader();
      const decoder = new TextDecoder();
      while (true) {
        const { done, value } = await reader.read();
        if (done) break;
        this.reply.update((text) => text + decoder.decode(value)); // paint as it arrives
      }
    } finally {
      this.streaming.set(false);
    }
  }
}

Bind reply() in the template and the answer types itself onto the screen. Around that core, design the states nobody teaches: model thinking, stream interrupted, answer wrong ("regenerate"), answer partially useful (let the user edit it). The Vercel AI SDK is worth studying here even without adopting it — its abstractions show what good AI UX plumbing looks like.

Structured outputs and tool use

Chat is the demo; the LLM as a reliable component is the job. Two mechanisms make that real. Structured outputs force the model to answer in a JSON shape you define. And tool use (function calling) lets the model request actions — your code executes them and returns results:

// A tool the model can call — the JSON Schema IS the contract
const tools = [
  {
    name: 'search_products',
    description: 'Search the catalog by text query and optional max price.',
    input_schema: {
      type: 'object',
      properties: {
        query: { type: 'string' },
        maxPrice: { type: 'number' },
      },
      required: ['query'],
    },
  },
];
// The model replies: { name: 'search_products', input: { query: 'trail shoes', maxPrice: 80 } }
// Your code runs the real search and sends the result back; the model writes the final answer.

Notice what this really is: an API contract, typed data, validation — skills a frontend already has, pointed at a new consumer. This is the step where "played with ChatGPT" becomes "builds with LLMs".

RAG: give the model your data

Models don't know your product's docs or your user's content. RAG (retrieval-augmented generation) fixes that: split documents into chunks, convert each chunk into an embedding — a list of numbers that captures its meaning, so texts about the same thing end up numerically close — store them in a vector database (one that searches by similarity instead of exact match), and at question time retrieve the most relevant chunks and paste them into the prompt. That's the whole trick — retrieval quality, chunking strategy and knowing when RAG is the wrong answer (small corpus? just put it all in context) are where the craft lives. Study the concepts before any framework; the AI engineer roadmap sequences this well.

Agents and MCP: the panorama

An agent is a loop: the model reasons, calls a tool, reads the result, repeats until done. Multi-step, stateful, powerful, and failure-prone — which is why frameworks (LangGraph, the Claude Agent SDK) exist to add checkpoints and human-in-the-loop controls (planned pauses where a person approves the next move). Alongside them, the Model Context Protocol is emerging as the standard for plugging tools and data sources into models — worth knowing at the "what it is and why" level. Mastering agents isn't required to be hireable; understanding the loop and having built one small one is.

Evals: the most underrated skill on the list

How do you test a feature whose output is different every run? Evals — the unit tests of AI engineering, and the skill that appears in nearly every senior AI posting while almost no tutorial teaches it. The shape: a golden dataset of real inputs with expected qualities, run on every prompt or model change, scored automatically (assertions for what's checkable, LLM-as-judge — another model grading the answers — for what's subjective). If you bring one differentiating skill to an interview, bring this one — Hamel Husain's writing on evals is the reference. Nothing says "ships AI seriously" like an eval suite that catches regressions.

And learn to develop with AI

The other half of the profile: using coding agents (Claude Code, Copilot, Cursor) as a professional instrument. Three habits separate the engineers who multiply from the ones who ship AI-flavored bugs: specify before delegating (the quality of the output tracks the quality of the brief), review like it's a junior's PR (AI code is confident, plausible and sometimes wrong — the accountability didn't move), and know where it's weak (novel architecture, subtle state bugs, performance trade-offs, business context). What postings reward is not "uses AI" — everyone does — but judgment supervising it.

Step 2 · BUILD projects that exercise it

Reading grants zero credibility; building does. Three real projects, in ascending order — worth more than any certificate:

  1. An app with RAG. Upload a handful of PDFs or markdown files, embed them, answer questions with sources cited. A weekend of work, and it exercises the single most demanded production pattern. Proves: embeddings, retrieval, prompt assembly — RAG end to end.
  2. An agent that uses tools — with an eval suite. Two or three tools (search, calculate, save), a visible reasoning loop, and a golden dataset of ~20 cases scoring it on every change. The eval suite is what separates this repo from the ten thousand agent demos on GitHub. Proves: tool use, the agent loop, and the discipline of measuring it.
  3. A full-stack product with AI. Auth, a database, an AI feature with streaming UX, deployed behind a real URL. A BaaS — backend as a service — keeps the backend honest without a server to run: Firebase, for example. Proves: you can ship a complete product, not just a feature — the profile, integrated.

Step 3 · PROVE it with evidence

Skills that can't be seen don't exist in a hiring pipeline. If you know how to do it, you can show it — and the proof stack is cheap:

  • A public repo with an honest README — what you built, the errors you hit, and what you learned. The decisions and trade-offs are worth more than the code: "why one-shot retrieval instead of an agent here" signals real experience.
  • Deployed demos. A link someone can click beats any description — and deploying is the frontend's home turf.
  • A portfolio that documents the path. A write-up per project: what broke, what you'd do differently. Writing is how strangers discover you think clearly.
  • In interviews, talk trade-offs, not hype. "RAG was wrong for that corpus size" says more than any framework name-drop.

Going deeper

The resources to study, per step:

The checklist

The three steps, compressed:

Learn

  1. Keep the fundamentals sharp — state, a11y, performance. They're the moat, not the past.
  2. Call an LLM through your own endpoint — key server-side, always.
  3. Master streaming UX; treat the model as a typed component (structured outputs, tools).
  4. Understand RAG conceptually — and when not to use it.
  5. Build one small agent loop; write evals for it.

Build

  1. Ship the three projects: a RAG app, a tool-using agent with evals, a full-stack AI product.

Prove

  1. Public repos with honest READMEs — errors and learnings included — plus deployed demos.
  2. Document the path in a portfolio; in interviews, lead with trade-offs.

This is not a matter of weeks — it's months. But the frontends who adapt aren't starting over: they're pointing years of UX judgment at the most UX-starved technology of the decade. That's not a threat. That's an opening.

© 2026 Aaron Chacón — All rights reserved