LangChain 101: Chains, Prompts and the First LLM App

Let us talk about your first week on a new AI project. You pull down the repository. You open the main orchestration file. You see LangChain.

I wrote previously about why you do not always need a framework. I stand by that entirely. But software engineering is a team sport. Whether you chose it or not, LangChain is the dominant orchestration layer in the ecosystem right now. You need to know how to read it. You need to know how to write it. More importantly, you need to understand how it actually thinks.

People get intimidated because the documentation is massive. They see dozens of modules for vector stores, document loaders, memory management, and callbacks. Ignore all of that for now.

When you strip away the outer layers and the marketing hype, every single application boils down to three distinct steps. You format a string. You send that string to a computer in the cloud. You parse the string that comes back.

LangChain simply provides a standardized, composable interface for those three steps. Once you understand the core loop, the rest of the framework is just a variation on a theme.

The Architecture of a Data Pipeline

When you are just messing around in a single script, you format your text with basic string interpolation. You use native Python tools. It is fast and it works beautifully.

But production prompts rarely stay simple. You eventually need to pass in system instructions to define the persona. You need to inject a rolling window of chat history so the model remembers the last question. You need to separate the user’s current query from the background context pulled from a database.

Doing this with raw dictionaries gets messy quickly. You end up writing complex mapping functions just to keep the dictionary keys aligned with the API requirements.

LangChain introduces the concept of prompt templates to solve this. They act as reusable blueprints. You define the structure of the conversation once, leaving explicit placeholders for the dynamic variables. When the pipeline runs, the framework handles the mechanics of assembling those variables into a clean payload. It abstracts away the difference between a system message, an AI response, and a human input. You just pass a dictionary of values, and the template builds the exact array format the provider expects.

Next comes the model itself.

This is arguably where LangChain provides its most immediate and tangible value. The provider landscape is incredibly fragmented right now. OpenAI expects a specific JSON schema. Anthropic expects a different one. Google requires its own unique SDK syntax.

If you write raw API calls, swapping from GPT-4 to Claude 3 requires rewriting your entire request layer. You have to learn a new authentication pattern. You have to map your input variables to a new nested data structure. It makes benchmarking different models against your own data a tedious chore.

LangChain abstracts this entirely. It wraps every major provider in a unified interface.

You change a single import statement. You change the class name instantiation. The rest of your code remains completely untouched. That alone is often worth the price of admission when you are prototyping. You can write your logic once and run it across six different foundation models in the span of an afternoon.

The final piece of the core loop is the output parser.

Language models generate unstructured text. Software applications expect structured data. This is the eternal friction of AI engineering.

If you ask a model for a JSON response, it might give you perfect JSON. It might also give you perfect JSON wrapped in markdown code blocks. Or it might add a polite conversational greeting at the beginning of the string, which immediately breaks standard parsing libraries.

An output parser handles this friction. It sits at the very end of your pipeline, catching the raw text as it returns from the API. It strips away the markdown formatting. It drops the polite greetings.

The real power unlocks when you combine parsers with a data validation library like Pydantic. You can define a rigid schema for your expected output. You pass that schema to the LangChain parser, and the framework will automatically generate the dense formatting instructions required by the LLM. It literally appends a hidden block of text to your prompt explaining exactly how the JSON must be structured.

When the string returns, the parser casts it directly into a native Python object. It forces the chaotic output of a neural network back into the predictable types your application actually expects.

Wiring It Together With LCEL

Let us build a mental model of an actual application using these three components.

Suppose we want to build an internal utility that takes a messy, technical git commit log and translates it into a polished release note for a marketing email.

We need our three pieces. A prompt template to instruct the model on the tone and format. A chat model to execute the reasoning. A parser to clean up the final text and return a structured object containing a title and a summary paragraph.

In the early days of LangChain, connecting these pieces required wrapping them in a cumbersome Chain class. It felt rigid. It felt like writing enterprise Java.

The maintainers realized this and introduced the LangChain Expression Language. You will see it referred to everywhere as LCEL.

LCEL uses the pipe character to chain components together. If you have ever written a shell script, the syntax will feel immediately familiar. You take the output of the left side and pipe it into the input of the right side.

Your pipeline becomes a single, readable line of code. Prompt pipe model pipe parser.

It looks a bit like magic at first glance. Python does not naturally use the pipe operator for function composition. The framework overrides the underlying bitwise operator to make this syntax work. I am usually highly skeptical of overriding core language features, but here it serves a genuine architectural purpose. It makes the data flow incredibly explicit.

When you execute this pipeline, you pass in a dictionary containing your raw git log string.

The pipeline takes that dictionary and feeds it to the prompt template. The template injects the string into its placeholders and compiles a list of formatted messages. The template automatically pipes those messages to the chat model. The model serializes them, handles the network request, and waits for the response.

The model receives a raw message object from the provider and automatically pipes it to the output parser. The parser extracts the content, validates the schema, and returns a clean Python class.

You never have to manually pass the output of one function into the next. The chain handles the execution context silently.

This becomes immensely powerful when you realize that every step in LCEL returns a standardized runnable interface. Because they all share the same base class, you get advanced features for free. You can invoke the chain synchronously. You can run it asynchronously. You can stream the output token by token without changing a single line of your business logic.

Streaming is notoriously painful to implement with raw API calls. You have to handle generator functions, chunk assembly, and buffer management. With LCEL, you simply call the stream method on your pipeline, and the framework handles the underlying chunking mechanics perfectly.

This is the exact moment where LangChain clicks for most developers.

You are no longer writing HTTP requests. You are snapping together modular blocks of logic. You can swap out the prompt template to tune the tone of the release notes for a different audience. You can swap out the model to reduce inference costs. You can add a new parser to return an array of bullet points instead of a single paragraph.

The architecture of your application remains entirely stable while the underlying components evolve.

Of course, this modularity comes with a steep learning curve in debugging.

When an LCEL chain breaks, the stack trace can be intimidating. You will see layers of internal routing logic that have nothing to do with your specific code. You have to learn how to read through the framework noise to find the actual point of failure.

Often, the bug is just a simple type mismatch. You passed a string where the pipeline expected a dictionary. The prompt template failed to find a placeholder key because of a typo.

This is why I recommend building your pipelines iteratively. Do not write a massive, five-step chain on your first try.

Define your prompt template and test it in isolation. Print the output. Make sure it formats your data exactly how you expect. Then attach the model and test the partial chain. Log the raw model output. Only when those two pieces are working perfectly should you append the strict output parser.

Treat your chains exactly like pure functions. They should be deterministic, testable, and isolated from your main application state.

If you keep your components small and your pipelines tightly focused, LangChain stops feeling like a bloated framework. It starts feeling like a sharp utility belt. You are still just passing strings back and forth to a server. You just have a cleaner desk to work on.

Mastering this core loop is the foundation of modern AI development. Once you understand how prompts, models, and parsers flow together gracefully, everything else in the ecosystem makes sense. Autonomous agents, conversational memory, and retrieval augmented generation all build upon this exact same pattern.

Start here. Keep it incredibly simple. The rest will follow.