← All posts

From Front-End to AI-Powered Products: My Learning Path

Why a 10+ year front-end/full-stack developer is deliberately upskilling into LLMs, agents and RAG, and what the actual learning path has looked like.

careerai-engineeringlearning

Why now

I've spent 10+ years building front-end and full-stack products: React and TypeScript UIs, Node.js APIs, the integration work that connects the two. That work hasn't stopped being interesting to me, and it's still the work I want to keep doing. But over the last year, the tools I use every day changed enough that I wanted to understand what's actually happening under the hood, instead of just consuming an API response from a model.

That's the honest starting point. Not a dramatic pivot, not "front-end is dead," and not a decision to stop being a full-stack developer. Just a decision to add a new layer of engineering skill on top of a stack I already know well, so I can go for full-stack roles and AI-leaning roles with the same amount of confidence.

What I actually did

I didn't try to learn everything about machine learning. I picked a path that builds on what I already have: API integration experience, systems thinking, and the habit of shipping working software instead of reading about it indefinitely.

Concretely, that meant working through three structured courses:

  • Complete AI Engineer Training: Python fundamentals for AI work, NLP basics, transformer architecture, LLM concepts, LangChain, Hugging Face, and calling LLM APIs directly.
  • AI Engineer Agentic Track: agents and the Model Context Protocol (MCP), how tools get exposed to a model, how an agent decides what to call and when.
  • AI Engineer Core Track: LLM engineering fundamentals, retrieval-augmented generation (RAG), QLoRA/fine-tuning basics, and agent design patterns.

Alongside the coursework, I made Claude and Claude Code part of my daily workflow rather than treating them as a novelty. Using a tool daily teaches you things a course can't: where it's genuinely useful, where it gets confidently wrong, and where the interesting engineering problems actually live (context management, tool design, evaluation).

What transfers directly from front-end/full-stack work

A lot, honestly:

  • API integration: calling an LLM API is still an API call: auth, retries, rate limits, versioning, error handling. The shape of the problem is familiar even when the payload is a prompt instead of a form submission.
  • Systems thinking: a RAG pipeline or an agent loop is a system with data flow, state, and failure modes, not a single magic function. Years of full-stack architecture work is directly applicable here.
  • Product sense: knowing what makes an interface (or an agent) actually usable, not just functional, doesn't disappear when the "interface" is a tool-calling loop instead of a button.

What's genuinely new

I want to be precise about this: I do not have production experience shipping AI features to real users yet. What I have is structured coursework, personal projects, and daily hands-on practice with AI coding tools. Those are real and current, but they're a foundation, not a track record, and I'd rather say that plainly than oversell it.

Where this is going

This blog exists partly to make that learning visible. Writing down what I actually understand about MCP, RAG, and agentic workflows forces me to be honest about what I know versus what I'm still fuzzy on. I'm planning to go deeper on each of those topics as I keep building, tied to personal projects rather than abstract theory.

To be clear about where I'm at: I'm not looking to trade in a decade of full-stack work for an AI-only title. I'm looking for roles, full-stack, front-end, or AI-leaning, where shipping real products and this newer AI engineering skill set can both be useful.