DEV Community

Cover image for Post-0001. LangGraph Learning Journal — Day 01: Code That Only Moves Forward Can't Think
KUNAL HORE
KUNAL HORE

Posted on

Post-0001. LangGraph Learning Journal — Day 01: Code That Only Moves Forward Can't Think

#ai #python #langgraph #beginners

Day 1 · by Kunal Hore (@KunalOnTech)

Quick Jump

Most code runs top to bottom, once, with no memory of where it's been. Real decisions don't move in a straight line — sometimes you loop back, sometimes you branch depending on what just happened. A script can't pause mid-run and reconsider. A graph can.

That single difference — code that can stop, decide, and circle back instead of just executing — is the entire reason LangGraph exists.

Over the next few days I'll cover all the topics to make you familiar with LangGraph. This is my first day of learning, and I'll share whatever I learn along the way. Today it's the three basics — what a graph remembers (state), what counts as one step (a node), and how those steps connect (an edge). We won't just talk about them — we'll build a small hands-on exercise with real code, because I've always believed you learn by building, not by theory alone.

Kunal's one-liner: "Code that only moves forward can't think. Code that can loop back, can."

That's the whole pitch for today. Everything else — TypedDict, function signatures, edge syntax — is just the mechanics of making that one idea real in Python.

Why I'm Learning This Publicly

I'm learning LangGraph from zero — one concept a day. No shortcuts, no pretending I already know it. Whatever I learn each day, I share the same day: the wins, the confusion, the "oh THAT'S what it means" moments, all of it.

My goal is simple:

  • One concept per day, explained with everyday analogies — no jargon walls
  • Real code every single day, because you learn by building, not by theory alone
  • Write it the way I wish someone had explained it to me

Your goal, if you learn alongside me: by the end of this series, we'll both be able to design and build stateful AI agents — the kind of systems that can decide, branch, retry, and loop, not just respond once.

And since I'm learning as I go, I might miss something or get a detail wrong. If you're reading and feel I've overlooked anything, drop it in the comments — it genuinely helps me grow, and it makes this series better for everyone following along.

No fluff. One bite a day.

Who this is for: Anyone comfortable writing plain Python functions who's curious how agent frameworks actually work under the hood. No prior LangChain or LangGraph experience assumed — we start from zero.

Do I need to know LangChain first? No. LangGraph is its own thing — a graph engine for stateful workflows. Familiarity with LangChain helps but isn't required for any page in this series.

Today's Map

  1. State — the fact; what your graph is allowed to remember
  2. Nodes — one action; a function that updates the state
  3. Edges — the order actions happen in; what runs after what
  4. Build & Run — wiring it together, compiling, and running your first graph

1. State

It's 8 PM. You feel hungry. That's the first thing on your mind right now: hungry. Your brain thinks, let me open the food app — now it knows one more thing: the app is open. You browse a bit, pick a restaurant. One more thing your brain is holding onto: which restaurant. You pick a dish — another thing added. You place the order — one more.

By the time you're done, your brain isn't holding one thought anymore — it's holding five, all at once: that you're hungry, that the app's open, which restaurant, which dish, and whether the order's placed.

That collection of things your brain is keeping track of — that's state.

It isn't a loose pile of facts. It has a fixed shape: a fixed list of fields, each with a fixed type — defined in code as a class, using TypedDict.

from typing import TypedDict

class FoodOrderState(TypedDict):
    mood: str
    app_opened: bool
    restaurant: str
    dish: str
    order_placed: bool
Enter fullscreen mode Exit fullscreen mode

Remember this:

  • What TypedDict actually does — TypedDict is a way to describe the shape of a dictionary using a class. It doesn't create a new kind of object — at runtime, your state is still a plain dictionary. What TypedDict adds is a contract: it tells Python (and you) exactly which keys must exist and what type each one holds.
  • Why that matters here — Every node uses the same shape for state. So TypedDict helps your editor and LangGraph check two simple things before the code runs: that you are not reading a field that does not exist, and that you are not putting the wrong type of value into a field.

2. Nodes

Your brain was holding five facts — hungry, app open, restaurant, dish, order placed. None of those facts filled themselves in. Each one was the result of something you did: you felt hungry, you opened the app, you picked a restaurant.

Each of those actions is what we call a node — a function that takes the current state in, changes one thing about it, and hands the updated state back out.

A node, in code:

def feel_hungry(state: FoodOrderState) -> FoodOrderState:
    state["mood"] = "hungry"
    return state
Enter fullscreen mode Exit fullscreen mode

Registering it:

graph.add_node("feel_hungry", feel_hungry)
Enter fullscreen mode Exit fullscreen mode

Remember this:

  • add_node takes two arguments — The first is a label, a string used to refer to this node when wiring edges. The second is the actual function that runs. They don't have to match, but keeping them identical is the convention, purely for readability.
  • A node is the only thing allowed to change state — A node can do anything a Python function can do — print, call an API, or write to a file. But the graph only passes along the state your node returns. Anything you don't include in that returned state isn't available to other nodes.

3. Edges

The order those actions happened in — feel hungry, then open app, then browse — that sequence is the edge. An edge connects one node to another and defines the path the graph follows after a node finishes. If there are multiple possible paths, a routing step decides which edge to take before the graph moves forward.

An edge, in code:

# after feel_hungry finishes, run open_app next
graph.add_edge("feel_hungry", "open_app")
Enter fullscreen mode Exit fullscreen mode

4. Build & Run — The Full Exercise

Problem statement: Model a person ordering food as a graph — a shared state tracking five facts, five nodes that each update one fact, and edges running them in a fixed sequence, from feeling hungry to the order being placed.

Here's the exact path our graph will walk:

START
  │
  ▼
Feel Hungry
  │
  ▼
Open App
  │
  ▼
Browse Restaurants
  │
  ▼
Pick Dish
  │
  ▼
Place Order
  │
  ▼
 END
Enter fullscreen mode Exit fullscreen mode 
# Imports — the graph builder and the typed-dict base class
from langgraph.graph import StateGraph, START, END
from typing import TypedDict

# The backpack — five fields the whole graph shares and updates
class FoodOrderState(TypedDict):
    mood: str
    app_opened: bool
    restaurant: str
    dish: str
    order_placed: bool

# Nodes — each one reads state in, changes one field, returns state out
def feel_hungry(state):
    state["mood"] = "hungry"
    return state

def open_app(state):
    state["app_opened"] = True
    return state

def browse_restaurants(state):
    state["restaurant"] = "Biryani House"
    return state

def pick_dish(state):
    state["dish"] = "Chicken Biryani"
    return state

def place_order(state):
    state["order_placed"] = True
    return state

# Build the graph — create it, then register every node
graph = StateGraph(FoodOrderState)
graph.add_node("feel_hungry", feel_hungry)
graph.add_node("open_app", open_app)
graph.add_node("browse_restaurants", browse_restaurants)
graph.add_node("pick_dish", pick_dish)
graph.add_node("place_order", place_order)

# Edges — wire the nodes in the order they should run
graph.add_edge(START, "feel_hungry")
graph.add_edge("feel_hungry", "open_app")
graph.add_edge("open_app", "browse_restaurants")
graph.add_edge("browse_restaurants", "pick_dish")
graph.add_edge("pick_dish", "place_order")
graph.add_edge("place_order", END)

# Compile — locks the blueprint into something runnable
app = graph.compile()

# Run — start with an empty backpack and walk the graph end to end
initial_state = {
    "mood": "",
    "app_opened": False,
    "restaurant": "",
    "dish": "",
    "order_placed": False,
}

final_state = app.invoke(initial_state)
print(final_state)
Enter fullscreen mode Exit fullscreen mode

Output:

{
    'mood': 'hungry',
    'app_opened': True,
    'restaurant': 'Biryani House',
    'dish': 'Chicken Biryani',
    'order_placed': True
}
Enter fullscreen mode Exit fullscreen mode

Every node updated one piece of the shared state. Nothing magical happened — the graph simply walked through the nodes one by one, carrying the same dictionary from start to finish.

Kunal's Interview Corner

Four questions someone might actually ask about today's lesson — the kind that surface gaps a quiet read-through never does. These aren't definitions to memorise. Each one comes with an answer framework — the structure an interviewer wants to hear. Try answering before you tap.

Q1. What's the difference between a LangGraph workflow and a normal Python script?

 

· Answer Framework: Contrast the two → Give a mental picture

· Answer: In a normal Python script, things run one after the other in a straight line. With LangGraph, it's more flexible — think of it like a flowchart, where you can jump around and execute tasks in different orders.

Q2. What is State in LangGraph?

 

· Answer Framework: Plain-words definition → What it enables

· Answer: State is basically a shared notebook that all the nodes can access and update. It helps them talk to each other and remember what's going on.

Q3. What is a Node in LangGraph?

 

· Answer Framework: Define its job → Describe its behaviour

· Answer: A node is just a small task that does one specific thing. It looks at the current state, does its job, and then updates the state if needed.

Q4. What is an Edge in LangGraph?

 

· Answer Framework: Give the analogy → State what it controls

· Answer: An edge is like an arrow that connects two nodes. It determines the order in which they run.

"If you can answer these four without checking your notes, Day 1 actually stuck."

Today's Takeaway

If you remember only three things from today, remember these:

Term Meaning
State What your graph remembers
Node One unit of work that changes state
Edge The connection that says which node runs next

Everything else in LangGraph builds on these three ideas. Master them once, and the rest becomes much easier.

Next up → Day 2: Conditional Edges

Following along? Connect with me on LinkedIn · YouTube: @kunalontech

Top comments (0)