Free lesson · AI Engineering
The Modern AI Landscape
The Modern AI Landscape
Why You Need a Map
When I joined Meta's AI Infrastructure team, I spent my first two weeks just trying to understand the landscape. Not the code - the landscape. Which models existed. What each was good at. What inference infrastructure was available. Which tools were mature and which were held together with duct tape and optimism. Who the key players were and what their incentives looked like.
I wish someone had given me a map.
The AI landscape in 2025-2026 is enormous, fast-moving, and occasionally contradictory. New models launch every month. New tools appear every week. Blog posts declare revolutions every day. For someone entering AI Engineering, the noise-to-signal ratio is brutal.
This topic is the map. Not an exhaustive directory of everything that exists - that would be outdated before you finished reading it. Instead, it is a structural understanding of the landscape: the categories that matter, the players worth knowing, and the dynamics that will still be true six months from now even if the specific tools have changed.
The Foundation Model Landscape
Foundation models are the engine of AI Engineering. Every application you build in this course uses one or more foundation models. Understanding who makes them, what they are good at, and how they differ is essential context for every architectural decision you will make.
Closed-Source Models (API-Only)
These models are available only through APIs. You cannot download the weights, host them yourself, or inspect how they work internally. You pay per token and you trust the provider's infrastructure.
OpenAI (GPT-4, GPT-4o, o1, o3). OpenAI defined the current era of AI. GPT-4 set the capability bar that every other model is measured against. GPT-4o added multimodal capabilities. The o-series models (o1, o3) introduced structured reasoning - the model explicitly thinks through problems in steps before answering. OpenAI's strength is raw capability on complex tasks. Their weakness is cost - GPT-4 is one of the most expensive models per token - and opacity. You cannot see inside the model, and OpenAI's roadmap is famously unpredictable.
Anthropic (Claude 3.5, Claude 4, Claude Opus). Anthropic builds Claude, and I say this with genuine respect - Claude is the model I personally use most for complex technical work. Claude's strength is instruction-following, long-context handling (up to 200K tokens), and careful, well-structured responses. Anthropic's focus on AI safety means Claude tends to be more conservative than GPT-4 on edge cases, which is sometimes a feature and sometimes a limitation. Claude's system prompt adherence is best-in-class, which matters enormously for production applications where consistent behaviour is non-negotiable.
Google (Gemini 1.5, Gemini 2.0). Gemini's differentiator is context length - Gemini 1.5 Pro handles up to 2 million tokens, which is an order of magnitude beyond most competitors. That context length unlocks use cases that are architecturally different from what you can build with shorter-context models. Gemini's multimodal capabilities are also strong. The weakness is that Gemini's API ecosystem is less mature than OpenAI's, and developer experience has historically lagged.
Open-Source and Open-Weight Models
These models are available for download. You can run them on your own infrastructure, fine-tune them, and inspect (some of) their internals. "Open-source" and "open-weight" are different - open-weight means you can use the model but may not have access to training data or training code. The distinction matters legally but not much for practical AI Engineering work.
Meta (Llama 3, Llama 3.1, Llama 4). I am biased here - I work at Meta and I have seen Llama's development from the inside. Llama is the most widely adopted open model family. Llama 3.1 405B matched GPT-4 on many benchmarks. The smaller variants (8B, 70B) offer remarkable capability-per-dollar for self-hosted inference. Llama's license is permissive for most commercial use cases. If you are considering self-hosting, Llama is usually the first model to evaluate.
Mistral (Mistral Large, Mixtral, Mistral Small). Mistral, based in Paris, has consistently punched above its weight. Mixtral introduced the mixture-of-experts architecture to the open model world, achieving strong performance at lower inference costs than dense models of similar capability. Mistral's models are particularly good for European language tasks and for applications where you need a balance of capability and cost.
Qwen (Qwen 2, Qwen 2.5). Alibaba's Qwen models are strong across the board and particularly capable for multilingual applications, especially those involving Chinese and other Asian languages. Qwen 2.5 Coder is one of the best open-source code models available. If you are building for a global audience, Qwen deserves a spot on your evaluation list.
Others worth knowing: Cohere (strong enterprise focus, good embedding models), DeepSeek (competitive reasoning models from China), Phi (Microsoft's small but capable models, excellent for on-device use).
Tip: How to think about model selection: Do not pick a model and stick with it forever. Different tasks benefit from different models. A common production pattern is to use a capable but expensive model (GPT-4, Claude Opus) for complex reasoning tasks and a cheaper, faster model (GPT-4o-mini, Claude Haiku, Llama 8B) for simpler tasks like classification, extraction, or reformatting. We cover this in depth in the model selection and routing module.
The Three Things That Changed Everything
Interactive animation: Three changes in roughly 18 months - models got good enough, APIs made them accessible, and the ecosystem matured.
The AI landscape did not arrive here gradually. Three developments, each occurring within a roughly 18-month window, created the field of AI Engineering as it exists today.
Change 1: Foundation Models Became Good Enough
Before GPT-3.5 (November 2022), language models were useful for narrow tasks - classification, entity extraction, sentiment analysis - but they could not reliably follow complex instructions, maintain coherent conversations, or generate content that felt genuinely useful. GPT-3.5 and its successors crossed a threshold. They became good enough that building applications on top of them was not a research project anymore. It was an engineering project.
That crossing point matters because it changed who could build with AI. Before: you needed ML expertise to extract value from AI. After: you needed software engineering expertise and the right API calls. The audience shifted from ML researchers to software engineers. That audience shift is what created AI Engineering as a discipline.
Change 2: APIs Made Models Accessible
Foundation models are trained on thousands of GPUs over months of compute. Running inference on them requires significant infrastructure. The API layer - OpenAI's API, Anthropic's API, Google's Vertex AI - abstracted all of that away. Suddenly, using the most powerful AI models in the world required nothing more than an HTTP request and a credit card.
This is the equivalent of what AWS did for infrastructure in the 2000s. Before AWS, running a web service at scale required buying servers, racking them, managing networking, and hiring operations engineers. After AWS, it required an API call. The API layer transformed who could build at scale and how quickly they could do it.
The same transformation happened for AI. Before APIs, using a powerful language model required ML infrastructure expertise. After APIs, it required the ability to make an HTTP POST request. The infrastructure complexity did not disappear - it moved behind the API. And a new discipline emerged to work at the layer above the API: AI Engineering.
Change 3: The Ecosystem Matured
Models and APIs created the possibility. The ecosystem created the productivity. Between 2023 and 2025, the tooling layer for AI Engineering went from nearly nonexistent to remarkably mature:
Vector databases (Pinecone, Weaviate, Qdrant, Chroma) made semantic search practical. Before dedicated vector databases, storing and querying embeddings required custom solutions built on top of general-purpose databases. Now it requires a few API calls.
Orchestration frameworks (LangChain, LlamaIndex, Semantic Kernel) provided patterns for common tasks like RAG, agent loops, and multi-step workflows. These frameworks have their critics - and some of those criticisms are valid - but they dramatically reduced the time to first working prototype.
Evaluation tools (RAGAS, DeepEval, Braintrust, Langfuse) made quality measurement tractable. Early AI applications had no systematic way to measure whether they were working well. Now there are frameworks specifically designed for evaluating LLM outputs at scale.
Deployment infrastructure (vLLM, TGI, Ollama) made self-hosting practical. Running open-source models in production used to require deep infrastructure expertise. Now it requires a Docker pull command and a GPU.
This ecosystem is still maturing. Some categories have clear winners. Others are still shaking out. I will point you to the tools I trust throughout the course, but more importantly, I will teach you how to evaluate tools in a category so you can make your own choices as the landscape evolves.
The Current State of Things
Interactive animation: What is settled - LLMs in production, RAG, evaluation, cost - and what is still open, from agent autonomy to regulation.
Let me give you a snapshot of where the landscape sits right now - the settled questions and the open ones. This snapshot will age, but the structure beneath it will not.
What Is Settled
LLMs are useful for production applications. This was an open question two years ago. It is not anymore. LLMs power search, customer support, content generation, code assistance, document processing, and dozens of other production use cases at companies ranging from startups to FAANG. The question is no longer "can we use LLMs in production?" but "how do we use them reliably and cost-effectively?"
RAG is the dominant pattern for knowledge-intensive applications. When your application needs to answer questions about specific documents, products, or domain knowledge, the standard approach is retrieval-augmented generation. The specific retrieval techniques are still evolving, but the RAG architecture pattern is established.
Evaluation is non-negotiable. The early era of "ship it and see if users complain" is over. Production AI applications need systematic evaluation - both offline (before deployment) and online (after deployment). Companies that skip evaluation ship unreliable products and eventually pay the cost in user trust.
Cost management is a first-class engineering concern. LLM API calls are expensive relative to traditional compute. A production application making thousands of calls per day can generate thousands of dollars in monthly costs. Cost-aware architecture is not optional.
What Is Still Open
Agents: how far can autonomy go? AI agents that take actions autonomously - browsing the web, writing code, making API calls - are technically possible but reliability is inconsistent. The industry is actively debating where the autonomy boundary should sit for production applications. The answer is probably "it depends on the use case," but the frameworks for making that decision are still being developed.
Open versus closed models: which wins for production? Open models have closed the capability gap significantly. Llama 3.1 405B matches GPT-4 on many benchmarks. But closed models still lead on the hardest tasks and offer simpler operational models (no infrastructure to manage). The trade-off between capability, cost, data privacy, and vendor lock-in is genuinely unresolved and may remain context-dependent.
Fine-tuning versus long-context prompting: when does each win? Models with million-token context windows can hold entire knowledge bases in their prompt. That might make some RAG use cases unnecessary and some fine-tuning use cases redundant. The cost-performance trade-offs are still being worked out.
Regulation: what is coming? The EU AI Act is in effect. US regulation is evolving. Industry-specific requirements (healthcare, finance, legal) are tightening. The regulatory landscape will shape what AI Engineers can and must do over the next several years. I will cover the engineering implications of regulation in the safety module, but the regulatory landscape itself is a moving target.
Important: My approach to unsettled questions: When the answer is genuinely unknown, I will tell you. I will give you the trade-offs, the arguments on each side, and the framework for making your own decision. I will not pretend there is a settled answer when there is not. That intellectual honesty is part of what makes this course different from content that oversimplifies for the sake of sounding confident.
The Infrastructure Ecosystem
Interactive animation: Five infrastructure categories - embeddings, orchestration, observability, inference and guardrails - and the module that covers each.
Beyond models and APIs, AI Engineering relies on an infrastructure ecosystem that you will encounter throughout this course. Here is a quick orientation to the major categories.
Embedding Models and Vector Storage
Embeddings - numerical representations of text that capture semantic meaning - are fundamental to search, RAG, and classification. You will work with embedding models from OpenAI, Cohere, and open-source providers (BGE, E5, GTE). You will store and query those embeddings in vector databases. Module 5 covers this in depth.
Orchestration and Workflow Tools
Tools for chaining LLM calls, managing prompts, and building multi-step workflows. LangChain and LlamaIndex are the most widely known. Newer entrants like LangGraph (for agent workflows), DSPy (for automated prompt optimisation), and Instructor (for structured output) are gaining traction. I will teach you the underlying patterns so you can evaluate these tools critically rather than adopting them uncritically.
Observability and Monitoring
Tools for understanding what your AI application is doing in production. Langfuse, Braintrust, Arize, and Weights & Biases offer LLM-specific observability. Traditional monitoring tools (Datadog, Grafana, Prometheus) remain relevant for the non-AI parts of your stack. Module 15 covers production monitoring in depth.
Inference Infrastructure
If you choose to self-host open-source models, you need inference infrastructure. vLLM is the leading open-source inference engine - it handles batching, KV-cache management, and GPU memory optimization. Text Generation Inference (TGI) by Hugging Face is another option. Ollama simplifies local development with open-source models. Module 16 covers self-hosting decisions.
Guardrails and Safety Tools
Tools for ensuring your AI application behaves safely. NeMo Guardrails (NVIDIA) and Guardrails AI provide frameworks for input/output validation, topic restriction, and content safety. These are covered in Module 14.
The Landscape Is Not the Course
I want to end this topic with a calibration note. The landscape is context, not curriculum. I have given you the map so you know where things are and how they relate to each other. The course itself will take you through each region of this map systematically, with depth, with code, and with production-grade examples.
You do not need to memorise the landscape. You need to know it exists and roughly where things sit. As we move through the course, I will reference this mental model repeatedly. "We are now at Layer 2, in the orchestration section, working with RAG" - that kind of signposting will help you keep the bigger picture in view as we go deep on individual topics.
The landscape will change. Models will get better and cheaper. New tools will appear. Some of the players I have mentioned will become dominant; others will fade. That is the nature of a young field moving fast.
What will not change is the structure: foundation models at the bottom, orchestration in the middle, applications on top. The techniques: prompt engineering, retrieval, fine-tuning, evaluation. The engineering concerns: reliability, cost, safety, scalability.
Those are what this course teaches. The landscape is the context in which you will apply them.
Tip: A practical suggestion: Bookmark the release pages or blogs for the major model providers - OpenAI, Anthropic, Google, Meta AI. Spend 15 minutes per week scanning them. Not to chase every new announcement, but to maintain situational awareness. The best AI Engineers I know are not early adopters of every new tool. They are informed observers who adopt selectively and with clear reasons.