DEV Community: Javi Palacios

Docker port mapping: connect your containers to the outside world

Javi Palacios — Tue, 04 Aug 2026 07:26:12 +0000

In the previous lesson you launched an Nginx container in detached mode. docker ps showed it as Up, the PORTS column said 80/tcp, everything looked fine. You opened the browser, typed http://localhost:80, and got... nothing. Blank screen. Or a connection refused error.

Is the container not running? It is. Is Nginx broken? No, it's fine. Is it your network? Your machine? The universe conspiring against you?

No. It's Docker's network isolation doing exactly what it's supposed to — and you just didn't know about it yet.

Containers live in their own network bubble

Every Docker container has its own network interface, its own IP address, its own ports — completely separate from the host it runs on. If you're like me when I started, this seems like unnecessary complexity. Why can't it just listen on localhost like any other process?

Because that would break the isolation that makes Docker useful. If containers could bind to host ports freely, two containers trying to use port 80 would collide. You couldn't run multiple services on the same host without constant conflicts.

Think of it this way: each container is like an apartment in a building. It has its own windows (ports), its own internal address, its own doorbell. But from the street, if there's no visible unit number, nobody knows that apartment exists. The 80/tcp you see in docker ps is the window facing the interior courtyard — nobody outside the building can see it.

To make it accessible from the street, you need to map it to the building's front facade. That's exactly what -p does.

Publishing ports with `-p`

# host_port:container_port
docker run -d -p 8080:80 --name my-nginx nginx

Now http://localhost:8080 shows Nginx's welcome page. Traffic flows like this:

Your browser → localhost:8080 → Docker → container:80 → Nginx

Docker intercepts traffic arriving at port 8080 on the host and forwards it to port 80 inside the container. Nginx doesn't know it's listening on 8080 — from its perspective, it's always been on port 80. Works on my machine, because you're literally remapping which machine "your machine" is.

Syntax variants

# Different ports on host and container (most common)
docker run -d -p 8080:80 nginx

# Same port on both sides (simpler, but watch for conflicts)
docker run -d -p 80:80 nginx

# Bind only to localhost — not exposed on external interfaces
docker run -d -p 127.0.0.1:8080:80 nginx

# -P (uppercase): Docker auto-assigns random host ports
docker run -d -P nginx

The uppercase -P is handy for quick experiments, but in production it's a nightmare — ports change on every container restart and nobody knows what to connect to. Don't use -P in production. Yes, that includes the staging environment that's "basically production."

Multiple ports

docker run -d \
  -p 80:80 \
  -p 443:443 \
  --name my-app \
  my-image

Repeat -p as many times as you need.

Checking active port mappings

docker ps

CONTAINER ID   IMAGE   COMMAND                  CREATED         STATUS        PORTS                  NAMES
a1b2c3d4e5f6   nginx   "/docker-entrypoint.…"   3 seconds ago   Up 3 seconds  0.0.0.0:8080->80/tcp   my-nginx

The PORTS column now shows 0.0.0.0:8080->80/tcp. Read it like this:

0.0.0.0 → listening on all host interfaces
8080 → host port
->80/tcp → forwarded to port 80 inside the container

If you see just 80/tcp without the arrow — like at the beginning — the port is exposed internally but not published. Nobody outside can reach it.

To see the mappings for a specific container without the noise of docker ps:

docker port my-nginx

80/tcp -> 0.0.0.0:8080

Inspecting the network with `docker inspect`

When you need to understand exactly how a container is connected — internal IP, gateway, full port mappings — docker inspect has everything:

docker inspect my-nginx | jq '.[0].NetworkSettings'

{
  "IPAddress": "172.17.0.2",
  "Ports": {
    "80/tcp": [{ "HostIp": "0.0.0.0", "HostPort": "8080" }]
  },
  "Networks": {
    "bridge": {
      "IPAddress": "172.17.0.2",
      "Gateway": "172.17.0.1"
    }
  }
}

The container has its own IP (172.17.0.2) inside Docker's bridge network. The gateway (172.17.0.1) is the host — Docker acts as a router between the container's internal network and the outside world.

Technically you could reach the container from the host using that internal IP directly, no port mapping needed. But that IP changes every time you restart the container and isn't accessible from outside the host. Port mapping is the stable solution.

Multiple containers on the same host

Here's where it gets interesting. What happens if you launch two Nginx containers at the same time?

docker run -d -p 8080:80 --name nginx-1 nginx
docker run -d -p 8080:80 --name nginx-2 nginx  # ❌

docker: Error response from daemon: driver failed programming external connectivity
on endpoint nginx-2: Bind for 0.0.0.0:8080 failed: port is already allocated.

Feeling confused? Good — this is actually the system working correctly. Port 8080 on the host is already taken by nginx-1. The host only has one port 8080, the same way a city only has one Main Street.

What containers can share are their internal ports — Docker's network isolation means port 80 in nginx-1 and port 80 in nginx-2 are completely independent. The only thing that can't repeat is the host port:

docker run -d -p 8080:80 --name nginx-1 nginx  # ✅
docker run -d -p 8081:80 --name nginx-2 nginx  # ✅

CONTAINER ID   IMAGE   PORTS                  NAMES
a1b2c3d4e5f6   nginx   0.0.0.0:8080->80/tcp   nginx-1
b7c8d9e0f1a2   nginx   0.0.0.0:8081->80/tcp   nginx-2

http://localhost:8080 → nginx-1. http://localhost:8081 → nginx-2. Same service, two instances, zero conflicts.

What if containers need to talk to each other?

One thing that trips people up: port mapping (-p) is for communication from outside — your browser, an external API, a client. For containers to communicate with each other, using their internal IPs works technically but is fragile (IPs change on restart). The right solution is Docker networks, which let containers discover each other by name instead of IP. We'll cover that properly in the networking module later in the course.

For now: -p is for the outside world, Docker networks are for internal container-to-container communication. Don't mix them up.

With port mapping you complete the fundamental container cycle: starts isolated, does its work internally, and exposes to the world exactly what you decide — nothing more. It's one of those Docker design decisions that feels like friction at first and becomes one of the things you most appreciate once you've debugged a port collision in production at 2 AM.

In the next module we jump into Dockerfiles: so far you've been using official images as-is; starting from L6 you'll learn to build your own from scratch.

Never stop coding!

💡 Challenge: Launch two Nginx containers on different host ports (8080 and 8081). Verify with docker ps that both are running and that you can reach each from the browser. Then use docker inspect with jq to extract the internal IP of each. Are they different? Are they on the same bridge network?

Finding bugs with git bisect

Javi Palacios — Mon, 03 Aug 2026 11:16:44 +0000

There's a bug in production. It wasn't there yesterday. Someone introduced it in one of the last two weeks of commits, but the log has 200 entries — "fix", "wip", "refactor auth", "more fixes", the usual suspects. You could check out commits one by one going backwards, testing each time. You could also read every changed line of code looking for the culprit, or try to guess based on commit messages and gut instinct. All of that is brute-force debugging: slow, exhausting, and dependent on luck in a way that should be illegal.

git bisect does binary search on your commit history. Instead of reviewing 200 commits, you review 8. Git picks which one to test each time, you tell it whether the bug is there or not, and in a few steps it points a finger at the exact culprit commit. It's one of those tools where you find out it exists and immediately wonder how you've been debugging without it.

How binary search works here

Same idea as finding a word in a dictionary: you don't start at page one. You open to the middle, decide whether the word comes before or after, and discard the irrelevant half. Repeat with the remaining half. Seven steps covers a 128-page dictionary.

Git applies that exact logic to your commit history. You say: "I know the bug didn't exist at v2.0.0, and I know it exists right now." Git checks out the middle commit, you test, you say good or bad, it discards the wrong half. Keep going until only one commit remains — that's the one that introduced the problem.

With 200 commits, bisect needs at most 8 steps. With 1,000, around 10. The math doesn't lie.

Basic usage

Before starting, make sure your working tree is clean. Bisect is going to do several automatic checkouts and doesn't want to find half-finished changes in the way.

git stash          # save any work in progress
git bisect start

Now tell it which state is bad (current) and which was known good:

git bisect bad          # current commit has the bug
git bisect good v2.0.0  # this tag/commit was clean

Git calculates how many commits sit between the two points and checks out the middle one:

Bisecting: 99 revisions left to test after this (roughly 7 steps)
[a3f9c12] Refactor authentication middleware

Now you test. Does the bug appear? If yes:

git bisect bad

If no:

git bisect good

Git discards the wrong half, checks out the next candidate, and waits for your verdict. Repeat. After a few steps you'll see something like this:

a3f9c12 is the first bad commit
commit a3f9c12
Author: Ana García <ana@example.com>
Date:   Mon Apr 14 11:23:01 2026 +0200

    Refactor authentication middleware

 src/auth/middleware.ts | 47 ++++++++++++++++++++++++++-----------
 1 file changed, 33 insertions(+), 14 deletions(-)

Git hands you the exact commit: hash, author, date, message, and changed files. What you do with that information is up to you — bisect has done its job.

When you're done, whether you found the bug or just want to exit:

git bisect reset

This puts you back exactly where you were before starting. Clean slate.

Using references instead of hashes

You don't need to know the exact hash of the "good" commit. Any reference Git understands works:

git bisect good v2.0.0          # a tag
git bisect good main~30         # 30 commits before main
git bisect good 2026-04-01      # approximate date
git bisect good origin/release  # a remote branch

The approximate date is particularly handy when you know "it worked last week" but don't remember which commit you were on. Git interprets it and finds the nearest commit.

Automating bisect with a script

This is where bisect goes from "useful" to "unreasonably powerful." If you have an automated test that reproduces the bug, you can tell Git to run that test at each step and classify commits on its own. You walk away to get coffee and come back to a solved mystery.

git bisect start
git bisect bad HEAD
git bisect good v2.0.0
git bisect run npm test

Git runs npm test on each candidate commit. Exit code 0 means the commit is good. Exit codes 1–127 mean bad. Bisect advances on its own until it finds the culprit.

The script can be anything: a specific test, a bash script that checks a particular behavior, even a curl against a local endpoint. The only rule is that the exit code must honestly reflect whether the bug is present:

#!/bin/bash
# check-bug.sh

# Start the app in background
node server.js &
SERVER_PID=$!
sleep 1

# Test if the bug is present
RESULT=$(curl -s http://localhost:3000/api/user/1 | jq '.name')

# Clean up
kill $SERVER_PID

# Exit 0 = good (no bug), exit 1 = bad (bug present)
if [ "$RESULT" = "null" ]; then
  exit 1   # bug present — name should not be null
else
  exit 0   # all good
fi

git bisect run ./check-bug.sh

There's one special exit code worth knowing: 125. If your script exits with 125, bisect treats that commit as untestable — it skips it without marking it good or bad. Use this when a commit doesn't compile, has broken dependencies, or otherwise can't be tested. It keeps that commit from contaminating the result.

# Example: skip if the project doesn't compile
if ! npm run build; then
  exit 125   # skip this commit, can't test it
fi
npm test

Checking bisect progress

If you lose track of where you are in the search:

git bisect log      # full history of verdicts so far
git bisect view     # visual representation of the remaining range

git bisect log is also useful for reproducing a session later. Save its output and use git bisect replay if you need to repeat the same search from scratch.

When bisect isn't the right tool

Bisect is spectacular for regression bugs — something that worked before and stopped working. That's exactly what it was designed for.

But there are cases where it doesn't help as much:

The bug was always there: if no "good" commit exists, bisect has no starting point.
The bug is intermittent: if behavior changes between runs, good/bad verdicts become unreliable and bisect will lead you astray.
Tests take too long: if each step takes ten minutes, automation loses most of its appeal. Bisect is still useful in manual mode, but the "walk away and come back to an answer" magic evaporates.

For those cases, git log -S "string" (finds commits that added or removed a specific string) and git blame are more direct alternatives. We'll cover both in the next lesson.

Bisect is one of those commands that looks like magic the first time you see it work. You have 300 commits, five minutes of back-and-forth, and Git hands you the commit, the author, and the changed files. It's genuinely satisfying — especially if the commit author turns out to be someone else (or past-you from three weeks ago, which is practically the same thing).

In the next tutorial we cover git blame and the history exploration toolkit: how to find out who touched which line, when, and why — everything you need to make sense of a codebase you've been staring at for five minutes.

Never stop coding!

Recovering lost work with git reflog

Javi Palacios — Fri, 31 Jul 2026 17:21:02 +0000

If you're like me when I started, you've done a git reset --hard at least once and immediately felt that specific kind of dread. Did my commits just disappear? Where's the branch I deleted? Can I get it back or did I just nuke two days of work? The short answer is: almost always, yes, you can get it back. The long answer is this lesson.

Git has a safety net that almost nobody knows about until they desperately need it. It doesn't show up in intro tutorials, it's not mentioned in project onboarding docs, and nothing about the Git interface hints at its existence. It's called reflog, and once you know it's there, doing "destructive" operations stops being scary.

What is the reflog

The reflog (short for reference log) is a private journal that Git silently keeps of every movement made by any reference in your repository. Every commit, checkout, reset, rebase, merge — anything that moves HEAD — gets logged with a timestamp and the hash it was pointing to at that moment.

Think of it as your code editor's undo history, except it covers the entire repository. That Ctrl+Z you can mash twenty times to get back to how things looked ten minutes ago? That's the reflog, but for your whole Git state.

One thing to be clear about upfront: the reflog is entirely local. It doesn't get pushed, your teammates can't see it, it's not on GitHub. It belongs to your machine. By default, Git keeps entries for 90 days before the garbage collector cleans them up. If the disaster happened yesterday, you're fine. If it was four months ago — well, here's where it gets interesting.

Viewing the reflog

git reflog

The output looks like this:

a3f9c12 (HEAD -> main) HEAD@{0}: commit: Add user authentication
7b2d8e4 HEAD@{1}: rebase (finish): returning to refs/heads/main
7b2d8e4 HEAD@{2}: rebase (pick): Fix null pointer in payment service
3c1e9f6 HEAD@{3}: rebase (start): checkout main
f4a7b3d HEAD@{4}: reset: moving to HEAD~3
9e8c2a1 HEAD@{5}: commit: WIP: refactor login flow
b1d4f8e HEAD@{6}: commit: Add password validation
c2e5a9b HEAD@{7}: checkout: moving from feature/auth to main

Each line has three parts: the hash HEAD was pointing to at that moment, the relative reference (HEAD@{n}, where n is how many positions back), and the description of what caused the move. Your entire movement history, readable at a glance.

You can filter by branch or time if the reflog gets long:

git reflog show feature/auth       # reflog of a specific branch
git reflog --since="2 days ago"    # only recent entries

Recovering commits lost after a reset

The classic scenario: you ran git reset --hard pointing at the wrong commit. Or the right one, but without saving what you had. It feels like emptying the recycle bin and remembering three seconds later what was in it. The key difference: Git doesn't actually empty that bin right away.

git reflog

f4a7b3d (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
9e8c2a1 HEAD@{1}: commit: WIP: refactor login flow
b1d4f8e HEAD@{2}: commit: Add password validation
c2e5a9b HEAD@{3}: commit: Add login form

The reset is at HEAD@{0}. The commits you "lost" are sitting at HEAD@{1}, HEAD@{2}, and HEAD@{3}. Hash 9e8c2a1 is the last state you had before things went sideways. Two paths forward:

Restore the full state

git reset --hard 9e8c2a1

Your branch points back to the last commit you had. The three commits are back. Git had kept them all along — you'd only lost the reference, not the data.

Create a branch from that point (the cautious route)

If you'd rather not move your current branch until you're sure:

git branch recovered-work 9e8c2a1
git switch recovered-work
git log --oneline

Inspect, verify everything's there, then decide whether to merge or cherry-pick. No rush.

Recovering a deleted branch

You deleted feature/new-api with git branch -D, convinced everything had landed in main. Then you check main and a commit is missing. The branch is gone — but its commits aren't.

git reflog

a3f9c12 (HEAD -> main) HEAD@{0}: checkout: moving from feature/new-api to main
e7b3c9d HEAD@{1}: commit: Add rate limiting to API endpoints
d6a2b8f HEAD@{2}: commit: Implement new API versioning
c5f1a7e HEAD@{3}: checkout: moving from main to feature/new-api

Just before the final checkout (HEAD@{0}), you were at HEAD@{1} with hash e7b3c9d — the last commit on the deleted branch. One line to bring it back:

git branch feature/new-api e7b3c9d

The branch is back with all its commits. Git doesn't delete commits when it deletes branches; it only deletes the pointer. The reflog gives you the pointer back.

Recovering from a bad rebase

This is where things get genuinely gnarly. Interactive rebase is one of Git's most powerful operations, and also one of the most creative ways to end up in a state you don't fully understand. Commits squashed that shouldn't have been, messages rewritten incorrectly, content mixed between commits. You're not the first. You won't be the last.

The reflog captures the exact state from the moment the rebase started. Find it:

git reflog | grep "rebase (start)"

3c1e9f6 HEAD@{8}: rebase (start): checkout main

That hash is the snapshot from just before the rebase began. Return to it:

git reset --hard 3c1e9f6

⚠️ If you already pushed the branch after the rebase, you'll need git push --force-with-lease to overwrite the remote. Only do this on branches that are exclusively yours — force-pushing main or a shared branch would export your problem to everyone on the team.

The ORIG_HEAD trick

Git, being Git, quietly saves a special reference called ORIG_HEAD every time it makes a drastic move: a merge, a rebase, a reset. No announcement. No prompt asking if you want it. It just does it (this time, thankfully).

# Undo last merge
git reset --hard ORIG_HEAD

# Undo last rebase
git reset --hard ORIG_HEAD

The limitation: ORIG_HEAD gets overwritten by each new drastic operation. It's perfect for immediate regret — you just did the merge/rebase and don't like the result — but useless if you've done more things since. That's what the reflog is for.

Finding a commit by its content

Sometimes you don't know exactly when you lost something. You just have a vague clue: a filename, a partial commit message, a rough date. The reflog pairs well with git log to track down the exact commit.

If you remember part of the message:

git log --all --oneline | grep "rate limiting"

e7b3c9d Add rate limiting to API endpoints

The --all flag is the key here. It includes commits no longer referenced by any active branch — exactly the "orphan" commits that appear when you delete a branch or do a reset. If that commit ever existed on your machine, --all will find it. Don't stress about scrolling through the reflog line by line if you have any clue about the message — git log --all is faster.

To inspect any reflog entry before restoring it:

git show HEAD@{5}           # content of that entry
git show HEAD@{5} --stat    # just the changed files

Practical cases

"I dropped the wrong stash"

Stashes have their own reflog. If you ran git stash drop by mistake:

git reflog show stash

9a1b2c3 stash@{0}: WIP on main: current stash
f8e7d6c stash@{1}: WIP on feature/auth: login work

If it was recent, it's probably still there. Recover it with:

git stash apply f8e7d6c

"I just force-pushed to main"

This is a genuine emergency (it should not have happened). First, find in the reflog the commit main was pointing to before the force push:

git reflog

Find the hash from before the mistake, reset to it, and push again:

git reset --hard <hash-before-the-mistake>
git push --force-with-lease origin main

Then tell your team to git fetch and realign their local branches. This is one of those situations where the time between "I realized" and "I fixed it" genuinely matters.

The reflog is proof that Git is, in practice, nearly impossible to use in a truly unrecoverable way. "I lost my work" in Git almost always means "I lost the reference to my work" — the commits are still there, waiting to be found.

The rule that would have saved me several scary moments early on: when something goes wrong in Git, the first thing you do is git reflog. Before panicking. Before opening Stack Overflow. Before telling anyone what happened. Open the reflog, find the state you want, go back to it. Almost every time, it's that simple.

In the next tutorial we'll cover git bisect, which lets you run a binary search through your commit history to find exactly which commit introduced a bug — and yes, you can automate it with a script so Git does the bisecting while you drink your coffee.

Never stop coding!

AI Limitations and How to Detect Hallucinations

Javi Palacios — Thu, 30 Jul 2026 17:40:18 +0000

This has either already happened to you or it's going to. You ask the AI to help with something concrete — parsing a JSON response using a library you've been using for years. It gives you the code. The syntax looks right, the names make sense, the comments are clear. You copy, paste, run.

AttributeError: module 'requests' has no attribute 'get_json'.

requests.get_json doesn't exist. It never existed. But the AI served it up with the same confidence it would use for response.json() — the function that's actually real — with no warning, no footnote, no "hey, I'm not totally sure about this one."

That's a hallucination. And here's where it gets fun.

Why AI lies with such conviction

In tutorial 2, we established that LLMs predict the next word. Hallucinations flow directly from that mechanic.

The model doesn't have access to a database of verified facts. It doesn't consult the official documentation before answering you. There's no internal module that says "wait, is this actually true?" What it has is a statistical model trained to generate text that sounds coherent and plausible.

When you ask about a function that doesn't exist, it isn't deliberately lying — it generates text that has the shape of a correct answer. It's seen thousands of responses about library functions and it "knows" what a correct answer looks like. The content may be invented. The form is always impeccable. That's the trap.

# What you asked for:
# "How do I parse a JSON response body with requests?"

# What the AI might give you (invented with full confidence):
import requests
response = requests.get("https://api.example.com/data")
data = requests.get_json(response)  # ❌ Does not exist

# What's actually correct:
import requests
response = requests.get("https://api.example.com/data")
data = response.json()  # ✅ Method on the Response object

Both versions have the same structure, the same descriptive names, the same "this works" energy. Only one of them actually works. And the one that doesn't — if you're like me when I first started using AI for code — is exactly the one you copy without blinking because it looks so reasonable.

The three types of AI error

Not all hallucinations are the same. Recognizing the type gives you a clue about where to look.

Invented information

The model generates something that never existed: a function, a parameter, a class, an endpoint. Like requests.get_json. This is the friendliest type — it fails fast and loudly. The code doesn't run, the error is obvious.

The typical pattern: names that sound right but don't appear in the official documentation. If a function name the AI gave you doesn't show up in your editor's autocomplete or in the docs... suspect it.

Outdated information

This one is more complicated. The model has a training cutoff date — the point when they stopped feeding it new data. Anything that happened after that date simply doesn't exist for it. It's not ignoring it — it genuinely doesn't know.

That includes:

APIs that went through a major version change (Flask 2.x → 3.x, Django 4.x → 5.x)
Deprecated methods that were removed in recent versions
Security patterns that turned out to be vulnerable
New approaches to things that used to be done differently

What makes this dangerous is that the code works — just on an older version of the library. On your project, with your current requirements.txt, it might fail silently, behave differently, or introduce a known vulnerability. Works on my machine™ taken to its logical extreme.

# What the AI might recommend (older Flask, perfectly valid in its day):
from flask import request

@app.route('/login', methods=['POST'])
def login():
    data = request.get_json(force=True)

# What you might want to be using today:
from flask import request

@app.route('/login', methods=['POST'])
def login():
    data = request.get_json()  # force is no longer needed in Flask 3.x for JSON content-type

Neither throws an error. But one can produce unexpected behavior depending on your version. The AI doesn't know — it genuinely doesn't know which version you're running unless you tell it.

Context blindness

This is the subtlest, the most common in real work, and the hardest to catch. The model doesn't know your codebase, your team's conventions, your architecture's constraints. It makes assumptions — the most statistically reasonable ones. Which aren't necessarily yours.

Imagine asking for help adding authentication to an endpoint. The model assumes:

You're using JWT (reasonable — it's the most common approach)
You have a users table in your database (reasonable)
The token header is called Authorization (it's the standard)
You have an authentication middleware available (might not be true)

If any of those assumptions doesn't apply to your system, the generated code might compile, pass a quick review, and fail in production in non-obvious ways.

# What the AI assumes:
@require_auth          # Do you have this decorator? Is that what it's called in your project?
@app.route('/api/v1/users/profile')
def get_profile():
    user_id = g.current_user.id  # Do you have g.current_user? With that exact name?
    ...

# What your project might actually have:
@login_required        # Your decorator has a different name
@app.route('/api/v1/users/profile')
def get_profile():
    user_id = session['user']['id']  # Your project uses sessions, not JWT
    ...

The error here isn't that the AI is "wrong" in the abstract. It's answering your question while assuming a context that isn't yours.

The warning signs to learn

Over time, you develop a nose for this. How do I know this output is suspicious? How do I tell what it knows from what it's inventing? In the meantime, here are the most common red flags:

Names you don't recognize. If the AI gives you a function, method, or class name that doesn't show up in your autocomplete or the official docs, stop before going further. It's not that you're behind — it might be straight-up invented.

Maximum confidence on specific or poorly-documented topics. The more obscure the topic, the higher the risk. The AI has far more training data about Flask than about your internal company library, or about the standard ORM versus the tuned version your team has been running since 2019 (and nobody ever properly documented, let's be honest).

Specific version numbers without a source. "This works since version 3.2" — where did that number come from? If it can't cite a source, treat the claim as unverified.

Code with the right shape that fails at runtime. ModuleNotFoundError, AttributeError, ImportError after running "looks-correct" code — classic signature of an API hallucination.

Answers that shift when you rephrase the question. If you ask the same thing two different ways and get contradictory answers, the AI doesn't have certainty — it's generating plausible versions, not verified facts.

The verification checklist

This isn't theory. It's what keeps AI-generated code from becoming a production problem. Five steps, in order, before merging any block you didn't write yourself.

1. Does it execute without errors?
   → Run it. An immediate stack trace = start hunting for the invented name

2. Do the functions it uses exist in the official documentation?
   → Search for the exact name in the docs for your version, not the latest

3. Is the syntax valid for your version?
   → Check the changelog if something looks "weird" or suspiciously new

4. Do the edge cases work?
   → Null, empty string, empty list, negative number — test the ones that matter to you

5. Do the assumptions it makes apply to your context?
   → Naming conventions, project structure, available libraries

Step 2 is the most commonly skipped — and the one that lets the most hallucinations through. "It works" doesn't mean "it uses real functions." It might work in your environment with your version of the library and break in CI, in production, or on another developer's machine. Don't ask me how I know.

Verification doesn't need to be exhaustive for every line. For a 10-line block doing something familiar, a quick glance is enough. For authentication code, for code that touches the database, for code that handles money or permissions — careful verification, no exceptions.

The "show me the documentation" tactic

When you suspect a hallucination, there's a move that works surprisingly well: ask the AI to cite its source.

"Which version introduced the strict_mode parameter for json.loads()?
Can you give me the exact link to that section in the official documentation?"

When it's hallucinating, it usually can't give you a valid URL — or it gives you one that 404s. If it can give you the exact URL and the correct version number, the information is probably real.

Fair warning: it's not foolproof. Newer models can generate URLs that look completely legitimate and aren't (because inventing a plausible-sounding URL is also just predicting coherent text). But it adds a useful friction layer.

You: "Can you cite the section of the requests docs that covers get_json()?"
AI:  "My information may be outdated. Let me check..."
     [invented URL that 404s]
     → Stop. Verify before continuing.

How to compensate for context blindness

The antidote is giving it context. This sounds obvious, but the practical difference between a context-free prompt and a context-rich one is enormous — not because the model gets smarter, but because it has to make fewer assumptions.

# ❌ No context:
"Help me add caching to this database query function"

# ✅ With context:
"""I have this function in Python 3.12 with SQLAlchemy 2.0:

[function code]

I want to add caching with Redis. In our project we already use redis-py 5.x
and have a client available as redis_client (injected singleton via DI).
We follow the repository pattern — caching should be transparent to the business layer.
"""

With the second prompt, the AI knows you already have Redis, which version, what the client is called, and which architectural pattern to respect. Far fewer assumptions to make — and the ones it does make are far more likely to be correct.

The practical rule: before asking for help with production code, ask yourself what a new colleague would need to know to help you without making mistakes. That's exactly what the AI needs.

What the AI can never know

There are things that won't be in any LLM's training context, no matter when it was trained:

Your team's specific conventions
Known bugs in your internal services
The architectural decisions you made two years ago and why
The business context behind why something works "strangely"
The implicit dependencies between modules that nobody ever documented

For these things, AI is a starting point, not an endpoint. It can generate the structure, give you the general pattern, save you the boilerplate. The adjustment to your project's context — that part is yours.

This isn't a criticism of AI. It's the nature of the problem. A senior developer joining your team also doesn't know any of this on day one. The difference is that the human can ask proactively and learn over time. The AI only knows what you show it in the current context window.

You now have the full map of why AI fails and how to catch it before it reaches production. The next step is putting this into practice — and for that, you need the tools. In the next tutorial, we install and configure opencode, the agent we'll use for the rest of the course, and run the first real AI-assisted coding session on an actual project.

Never stop coding!

Insert Mode in depth: more than you think

Javi Palacios — Wed, 29 Jul 2026 09:54:53 +0000

After the previous tutorial, you might have the impression that Insert mode is the poor relation of Vim. Normal mode has the grammar, the operators, the . command. Insert mode is where you... type. Like in any other editor.

And that's partially true. But there's a real difference between someone who uses Insert mode the way they'd use VS Code and someone who understands how it actually works. That difference is what determines whether your edits are precise, composable, and repeatable with . — or a mess of keystrokes that "kind of work."

This tutorial is the bridge between "I can survive in Vim" and "I'm starting to feel at home."

Nine ways to enter Insert mode

The most familiar is i. But Vim has nine — and each one exists for a reason.

The basics: where to land the cursor

Command	Where it starts inserting
`i`	Before the cursor (the default)
`a`	After the cursor (append)
`I`	At the start of the line (first non-blank character)
`A`	At the end of the line
`o`	Opens a new line below and enters Insert mode
`O`	Opens a new line above and enters Insert mode

The difference between i and a seems minimal — one character apart — but it matters. If the cursor is on the f in foo and you want to type something before it, use i. If you want to type after the whole word foo, navigate to the o and use a. In practice, a comes up a lot when adding something to the end of an expression.

A deserves a special mention: jumping to the end of the line and entering Insert mode is so common it has its own key. The sequence $a works, but A is a single command.

And o and O are hidden gems. Opening a new line and entering Insert mode at the same time is what you do 90% of the time when writing new code. In VS Code you'd press End + Enter. In Vim it's o. One character.

The change variants: delete and enter

Command	What it does
`s`	Deletes the character under the cursor and enters Insert
`S`	Deletes the entire line and enters Insert
`cw`	Deletes the word and enters Insert mode

You saw s and S briefly in the previous tutorial as shortcuts for cl and cc. The key insight is that they're not just shortcuts — they're the semantic way of saying "replace this." s means "substitute this character," S means "substitute this line."

cw isn't really an "entry" command on its own — it's the c operator with the w motion. But it's so common it belongs on this list. You'll find that c followed by any motion is the dominant pattern for editing existing text: ce, c$, c^, ciw (more on text objects in future tutorials).

Inside Insert mode: it's not a dead zone

Once you're in Insert mode, most people just type and press Esc. But there are shortcuts that work inside Insert mode that are worth their weight in gold:

Deleting without leaving

Shortcut	What it does
`Ctrl+h`	Delete the previous character (same as `Backspace`)
`Ctrl+w`	Delete the previous word (very useful when you mistype)
`Ctrl+u`	Delete everything you've typed on the current line

Ctrl+w is the one I use most. You type calculate_totlll and instead of mashing Backspace three times, Ctrl+w wipes the whole word at once. It'll be in your muscle memory within three days.

Ctrl+u looks aggressive, but it's perfect when you've completely gone off the rails and want to restart the line from scratch without leaving Insert mode.

The `Ctrl+o` trick

This one is the most interesting. Ctrl+o momentarily drops you into Normal mode, executes a single command, and returns to Insert mode.

" You're typing, cursor is in the middle of a line
" You want to jump to the start of the line without leaving Insert mode
Ctrl+o + ^    " → goes to first non-blank and returns to Insert mode
Ctrl+o + $    " → goes to end of line and returns to Insert mode
Ctrl+o + dw   " → deletes a word and returns to Insert mode

Don't obsess over Ctrl+o at the beginning. But once you've been using Vim for weeks and hit that situation where you need to do something quick without leaving Insert mode, you'll know it's there.

Native autocomplete

Vim has native autocomplete inside Insert mode, with no plugins:

Shortcut	What it does
`Ctrl+n`	Next suggestion — based on words in the buffer
`Ctrl+p`	Previous suggestion
`Ctrl+x Ctrl+f`	Autocomplete file paths
`Ctrl+x Ctrl+l`	Autocomplete entire lines from the buffer

The Ctrl+n / Ctrl+p autocomplete looks at all words across your open buffers. It's not the smart LSP autocomplete — but it works with zero configuration, even with vanilla Vim, even on a remote SSH server with no internet.

LazyVim already ships with a more powerful autocomplete plugin (nvim-cmp), so in your current setup you probably won't need Ctrl+n daily. But knowing it exists saves you the day you're on a bare remote server with unconfigured vim.

The golden rule of Insert mode

Here's the difference between someone who uses Vim and someone who uses it well:

Enter Insert mode to make ONE logical change. Then leave.

Not: i, type three words, delete two, rewrite, add a parenthesis, remove the parenthesis...

Yes: i, type the word, Esc. a, add the parenthesis, Esc.

Why? Because the . command replays the entire last change. If you enter Insert mode, do ten different things, and leave — . will replay all that chaos. If you make one clean change and leave, . will replay exactly that.

The granularity of your change is what makes . a surgical editing tool or a confetti cannon.

" ✅ Clean, repeatable change
cw                " change one word
newName           " type the replacement
Esc               " leave Insert mode → one change registered
w                 " move to the next occurrence
.                 " repeat exactly the same thing

" ❌ Entangled change, hard to repeat
i
first this then that and delete and rewrite Esc

This also applies to o and O. If you open a new line, write what you need, and leave — that's a repeatable change. If you open a new line and start reorganizing the entire function logic... it's not.

Arrow keys in Insert mode (and why not to use them)

Technically you can use arrow keys inside Insert mode to navigate. Vim allows it.

Don't.

The issue isn't that it's "wrong." It's that it costs time and messes up the cursor position for the . command. Every time you move with arrows inside Insert mode, you're in "I don't know exactly what change I'm making" territory. Leave to Normal mode, navigate with hjkl or word movements, come back to the exact spot, enter Insert mode.

This sounds rigid at first. Two weeks in, you won't even think about it.

Key concepts from this lesson

Nine Insert mode entries: i, a, I, A, o, O, s, S, c<motion>
o and O open a new line and enter Insert — the most common when writing code
Ctrl+w deletes the previous word without leaving Insert mode
Ctrl+o executes one Normal mode command momentarily and returns to Insert
Native autocomplete: Ctrl+n / Ctrl+p with no plugins
The golden rule: one logical change per Insert session → . works beautifully

You now have the two core pieces of Vim editing: Normal mode and Insert mode, and how to move between them deliberately. The next step is Visual mode — explicitly selecting text to operate on, including the block visual mode (Ctrl+v) that's one of those features that makes people ask "wait, a text editor can do that?"

Never stop coding!

while loops in Python: repetition with a condition

Javi Palacios — Wed, 15 Jul 2026 08:05:48 +0000

Picture this: you ask the user to type a number between 1 and 10. You write the input, check with an if whether it's in range, and if it isn't... what do you do? Copy and paste the input five times and hope they get it right by the third try? No. What you need is a loop.

Loops are the solution when you need to repeat something without knowing exactly how many times. They're not the last tool you'll learn, but they're one of the most important. And in Python, the most fundamental one is while.

What is a while loop?

A while loop executes a block of code as long as a condition is true. When the condition becomes false, the loop stops. If the condition was already false from the start, the block never runs at all.

The structure is intentionally similar to if:

while condition:
    # This code repeats as long as the condition is True
    do_something()

Same colon. Same mandatory indentation. The difference is that instead of running once, the block keeps cycling until the condition is no longer met.

A concrete example: counting from 1 to 5.

counter = 1

while counter <= 5:
    print(counter)   # Print current count
    counter += 1     # Increment — or we'll be here forever

Every time Python reaches the end of the block, it goes back to the while header and re-evaluates the condition. When counter hits 6, 6 <= 5 is False and the loop ends.

There are three components that almost always appear together in a while:

Initialization — counter = 1 (before the loop)
Condition — counter <= 5 (in the header)
Update — counter += 1 (inside the loop)

Forget the third one and you have a problem. A pretty famous one.

The infinite loop: it's not a myth

If your while condition never becomes False, the loop doesn't stop. Ever. Your program stays stuck running that block forever — or until you kill it with Ctrl+C.

# ⚠️ Infinite loop — don't run this unless you enjoy Ctrl+C
x = 1
while x > 0:
    print(x)
    x += 1   # x keeps growing, condition never becomes False

Feeling a slight sense of dread? Good. That means you already understand why updating the control variable matters.

Infinite loops aren't always accidental. Sometimes you use them on purpose — more on that in a moment. But when it's not intentional, they usually come from one of these:

You forgot to update the control variable
You're updating it in the wrong direction
The exit condition is impossible to reach with your logic

The quickest way out in the terminal is Ctrl+C. And whenever your program seems frozen... there's probably a while True hiding somewhere.

break: exit on your terms

Sometimes you need to leave the loop before the condition goes false. That's what break is for: it stops the while immediately and jumps to whatever code comes after the loop.

number = 1

while number <= 10:
    if number == 6:
        break   # Exit loop immediately when we hit 6
    print(number)
    number += 1

print("Loop ended")

1
2
3
4
5
Loop ended

break really shines in the while True pattern, where the loop is designed to run indefinitely and the exit condition lives inside the block:

while True:
    answer = input("Do you want to continue? (y/n) ")
    if answer == "n":
        break   # The only way out
    print("Continuing...")

print("Program ended")

This pattern — while True with an inner break — is completely legitimate and very common for menus, games, or anything that keeps going until the user decides to stop.

continue: skip one iteration

continue is break's smaller sibling. Instead of exiting the loop, it jumps back to the start of the next iteration — re-evaluates the condition and picks up from there if it's still true.

number = 0

while number < 10:
    number += 1
    if number % 2 == 0:
        continue   # Skip even numbers
    print(number)

When number is even, continue sends Python straight back to the while header without executing print. Only the odd numbers make it through.

A warning about continue: make sure the variable update happens before the continue. Look at what happens when it doesn't:

# ⚠️ Infinite loop — number never increments when it's even
number = 0
while number < 10:
    if number % 2 == 0:
        continue   # Jumps back before number += 1... forever
    number += 1
    print(number)

When number is 0 (even), continue fires before number += 1 has a chance to run. Next iteration, number is still 0. And the next. And the next. Instant infinite loop, even though it doesn't look like one at first glance.

Real-world use cases

while shines in situations where you don't know in advance how many repetitions you'll need. A few common patterns:

Validating user input

while True:
    age = input("Enter your age: ")
    if age.isdigit() and int(age) >= 0:
        age = int(age)
        break   # Valid input, exit loop
    print("Please enter a valid number.")

print(f"Your age is {age}.")

The loop keeps asking until the user gives something valid. Doesn't matter how many attempts it takes.

Counter with a business condition

attempts = 0
max_attempts = 3
correct_password = "python123"

while attempts < max_attempts:
    password = input("Enter your password: ")
    if password == correct_password:
        print("Access granted.")
        break
    attempts += 1
    remaining = max_attempts - attempts
    if remaining > 0:
        print(f"Wrong password. You have {remaining} attempts left.")

if attempts == max_attempts:
    print("Too many failed attempts. Account locked.")

This is the kind of logic behind any login form. The while controls the attempts; the break exits on success; the final if handles total failure.

Guessing game

import random

secret_number = random.randint(1, 100)  # Random number between 1 and 100
attempts = 0

print("Guess the number between 1 and 100.")

while True:
    try:
        guess = int(input("Your guess: "))
    except ValueError:
        print("That's not a number.")
        continue

    attempts += 1

    if guess < secret_number:
        print("Too low.")
    elif guess > secret_number:
        print("Too high.")
    else:
        print(f"Correct! You got it in {attempts} attempts.")
        break

Here the while True has no explicit exit condition in the header — the only way out is the break inside the else. Until the user guesses the number, the game keeps going.

while vs for: when to use each

If you've used other languages, you're probably already wondering when to pick while and when to pick for. Spoiler: you'll learn for loops in the next tutorial, and they're the preferred choice whenever you know how many iterations you want.

The rule is straightforward:

while: when the stopping condition depends on something that can change unpredictably (user input, network data, game state...)
for: when you're iterating over a sequence of known length (a list, a range of numbers, a file...)

If you can phrase it as "repeat this N times" or "go through this list", use for. If you're thinking "keep doing this until something happens", use while.

You now know how to make Python both make decisions and repeat code in a controlled way. The natural next step is the for loop — more predictable, more expressive for most everyday iteration, and the one you'll reach for most often in real Python code. You'll also meet range(), which turns numbers into iterable sequences without having to manage counters by hand.

Never stop coding!

💡 Challenge: Write a guessing game where the user has exactly 5 attempts to guess a number between 1 and 20. After each failed attempt, tell them whether their guess is too high or too low. When the 5 attempts are up without success, reveal the secret number. Bonus: track how many attempts they used when they win, and congratulate them with a different message depending on whether they got it in 1, 2–3, or 4–5 attempts.

Interactive containers and exec: get inside, run commands, get out

Javi Palacios — Tue, 14 Jul 2026 12:02:36 +0000

Up until now, you've been treating containers like vending machines: put in a coin, take the snack, walk away. That's fine for learning the basics, but the moment something breaks in a real environment — and it will — you're going to need to open the machine and look inside.

That's what docker exec and interactive mode are for. And once you're comfortable with them, you'll realize they're probably the commands you'll reach for most.

Interactive mode: what `-it` actually means

When you see docker run -it, those two letters aren't a typo or a habit. They're two separate flags:

-i (interactive): keeps stdin open, even if you're not attached to it
-t (tty): allocates a pseudo-terminal so the session behaves like a real shell

On their own, neither does much. Together, they give you something that looks, feels, and behaves like a proper terminal session inside the container. Without them, the process either starts and immediately exits, or sits waiting for input you can't give it.

# With -it: you get an interactive shell
docker run -it ubuntu bash

root@7a2f1d3c9e4b:/#

You're in. That thing before /# is the container ID. Now you can run anything:

root@7a2f1d3c9e4b:/# ls /etc
root@7a2f1d3c9e4b:/# cat /etc/os-release
root@7a2f1d3c9e4b:/# apt-get update
root@7a2f1d3c9e4b:/# exit

When you type exit, the main process of the container — bash, in this case — terminates. The container stops. It doesn't disappear, but it's no longer running.

This is the key mental model: the container's lifecycle is tied to its main process. When bash exits, the container stops. This feels obvious in retrospect, but it trips people up the first few times.

Detached mode: the `-d` you already know

The opposite of interactive mode is detached mode (-d). The container starts in the background and you get the control back immediately. Perfect for services that are supposed to run indefinitely: web servers, databases, message queues.

# Without -d: process stays in the foreground, locks your terminal
docker run nginx

# With -d: starts in the background, returns control
docker run -d --name my-nginx nginx

3f4e5d6c7b8a9e1f2d3c4b5a6e7f8d9c

That hash is the full container ID. Your terminal is free. The container is running, serving HTTP on its internal port 80 — though nobody outside Docker can reach it yet. That's what port mapping is for, and we'll get there next lesson.

To verify it's running:

docker ps

CONTAINER ID   IMAGE   COMMAND                  CREATED         STATUS        PORTS   NAMES
3f4e5d6c7b8a   nginx   "/docker-entrypoint.…"   3 seconds ago   Up 3 seconds   80/tcp  my-nginx

`docker exec`: get inside a running container

Here's the one you'll use most. docker exec runs an additional command inside an already-running container, without stopping or restarting it.

# Open a bash shell in the already-running my-nginx container
docker exec -it my-nginx bash

root@3f4e5d6c7b8a:/#

The difference from docker run -it is worth making explicit:

docker run -it creates a new container and drops you inside it
docker exec -it enters an existing container that's already running

When you exit from a docker exec session, the container keeps running. The main process — Nginx, in this case — hasn't been touched. You just closed the extra shell you'd opened on the side.

Common exec patterns

# Inspect Nginx's config file
docker exec -it my-nginx cat /etc/nginx/nginx.conf

# Open a bash shell to poke around
docker exec -it my-nginx bash

# Some containers don't have bash — sh is always there
docker exec -it my-alpine sh

# Check the environment variables of the running process
docker exec my-nginx env

# See what processes are running inside
docker exec my-nginx ps aux

# Install something for a one-off debugging session
docker exec -it my-nginx bash -c "apt-get update && apt-get install -y curl"

⚠️ Anything you install inside a running container with exec disappears when the container is removed. If you need something to be there permanently, it goes in the Dockerfile. exec is for inspection and debugging only.

`exec` without `-it`

You don't always need the interactive flags. If you just want to run a command and see the output, skip them:

# Run a command and see the output directly
docker exec my-nginx nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Without -it, the command runs, prints its output, and exits. No interactive shell, no pseudo-terminal. This is the form you'd use in scripts or CI pipelines.

The Alpine trap: bash vs sh

This one will catch you off guard eventually. Not all images have bash. Alpine-based images — which are wildly popular because of their tiny size — ship with sh only:

# ❌ This fails on an Alpine image
docker exec -it my-alpine-container bash

OCI runtime exec failed: exec: "bash": executable file not found in the PATH

# ✅ Use sh instead
docker exec -it my-alpine-container sh

If you genuinely need bash in Alpine for something:

docker exec -it my-alpine-container sh -c "apk add bash && bash"

Honestly though, sh covers 99% of what you'll need during an inspection session.

Copying files with `docker cp`

Sometimes you don't need to enter the container — you just need to get a file out (or put one in). docker cp copies files between the host filesystem and a container's filesystem.

From container to host

# Copy Nginx's config file out of the container to your local machine
docker cp my-nginx:/etc/nginx/nginx.conf ./nginx.conf

Useful for: grabbing a config you want to inspect and edit locally, pulling out logs generated inside the container, extracting build artifacts.

From host to container

# Copy a local file into the running container
docker cp ./my-config.conf my-nginx:/etc/nginx/conf.d/custom.conf

And then reload without restarting the container:

docker exec my-nginx nginx -s reload

`docker cp` vs volumes

docker cp is a one-off tool — great for debugging, for pulling a file out of a live container, for quick one-time injections. For ongoing file sync between host and container (like your application source code during development), you want volumes. Volumes are the right mechanism for that, and we'll cover them later in the course.

Think of docker cp as the Swiss Army knife. Volumes are the power tools.

Seeing what's happening: logs and inspect

Two more commands that pair naturally with exec:

`docker logs`

# See all logs from the container
docker logs my-nginx

# Follow logs in real time (like tail -f)
docker logs -f my-nginx

# Show only the last 50 lines
docker logs --tail 50 my-nginx

# Add timestamps
docker logs --timestamps my-nginx

`docker inspect`

While logs tells you what's coming out, inspect tells you everything about how the container is configured: environment variables, port mappings, mounted volumes, the network it's connected to, the image it came from:

docker inspect my-nginx

It returns a large JSON blob. Use jq to extract what you need:

# Check environment variables
docker inspect my-nginx | jq '.[0].Config.Env'

# Check the image ID
docker inspect my-nginx | jq '.[0].Image'

# Check the container's current state
docker inspect my-nginx | jq '.[0].State'

A typical debugging workflow

Here's what all of this looks like in practice when something's broken:

# 1. Container is running but something's wrong
docker ps
docker logs --tail 100 -f my-app

# 2. Logs aren't enough — enter the container to inspect
docker exec -it my-app bash

# 3. Inside the container, investigate
root@abc123:/# ls /var/log/
root@abc123:/# cat /var/log/app.log
root@abc123:/# env | grep DATABASE

# 4. Found a config file worth looking at — exit and pull it out
root@abc123:/# exit
docker cp my-app:/app/config.json ./config.json

# 5. Edit it locally, push it back in
docker cp ./config.json my-app:/app/config.json

# 6. Reload the process without restarting the container (if the app supports it)
docker exec my-app kill -HUP 1

This is what makes Docker genuinely useful for debugging: you can get in, look around, modify, and reload without taking the service down.

With docker exec, -it, and docker cp in your toolkit, you can actually interact with your containers rather than just launching them and hoping for the best. The ability to step inside a running container and see exactly what's happening is what separates someone who "uses Docker" from someone who understands it.

Next up: port mapping — how to make a service running inside a container accessible from your browser or from other processes outside Docker. This is where containers start feeling truly useful for building real applications.

Never stop coding!

💡 Challenge: Start an Nginx container in detached mode. Use docker exec to open a bash shell inside it. Copy /etc/nginx/nginx.conf to your machine with docker cp. Change worker_processes auto; to worker_processes 2;, push the file back into the container, and reload with docker exec my-nginx nginx -s reload. Verify the configuration is valid using docker exec my-nginx nginx -t.

Cherry-picking commits in Git

Javi Palacios — Mon, 13 Jul 2026 11:34:46 +0000

Production is down. There's a null pointer exception in the payment service and your on-call rotation landed on a Tuesday. You know exactly where the fix is: that commit from three days ago on feature/payments, the one called "Fix null pointer in payment service." The problem? That branch is a warzone — an unfinished refactor, a half-baked API that breaks half the existing code, and at least two commits named "wip" (there are always at least two commits named "wip"). Merging that branch into main would be like performing surgery by dropping a bowling ball on the patient.

You don't need the whole branch. You need that one commit.

That's exactly what git cherry-pick is for.

What is cherry-pick?

Think of your Git history as a playlist. Branches are playlists, commits are individual tracks. A merge is like saying "add this entire album to my playlist." A rebase is like moving your songs so they come after a different album. git cherry-pick is you pulling a single track from someone else's playlist and adding it to yours — without subscribing to their whole discography.

The mechanics: Git takes the diff introduced by that specific commit (what changed between it and its parent), and replays that diff on top of your current branch as a brand-new commit. Same content, different hash. The original commit stays exactly where it was. You just get a copy of the change.

That's worth repeating: the new commit gets a new hash. We'll come back to why that matters.

Basic usage

First, find the hash of the commit you need. Run git log on the source branch:

git log feature/payments --oneline

a3f9c12 Fix null pointer in payment service
b7e4d89 WIP: new payment gateway integration
c2a8f01 Refactor billing module (incomplete)
d6c3b47 Add payment model

There it is — a3f9c12. Switch to your target branch and apply it:

git switch main
git cherry-pick a3f9c12

[main 9b1d4e3] Fix null pointer in payment service
 Date: Mon Apr 14 18:32:01 2026 +0200
 1 file changed, 3 insertions(+), 1 deletion(-)

That's it. The fix is in main. The other fourteen commits are still sitting on feature/payments, waiting to be ready. Production breathes again.

Cherry-picking multiple commits

Sometimes one commit isn't enough. You have two options.

Individual commits

Pass multiple hashes in the order you want them applied:

git cherry-pick a3f9c12 d6c3b47 e1f2a03

Git applies them one by one, in that order. If any of them causes a conflict, it stops and waits for you to sort it out before continuing.

A range of commits

If the commits you need are consecutive, use range syntax:

git cherry-pick a3f9c12..e1f2a03

⚠️ Watch out: this syntax is exclusive on the left. a3f9c12..e1f2a03 applies every commit after a3f9c12 up to and including e1f2a03. If you also want a3f9c12 itself, use the ^ suffix:

git cherry-pick a3f9c12^..e1f2a03

This catches everyone exactly once. File it under "Git syntax that looks like line noise but actually makes sense once you've been burned by it."

Useful flags

`-n` / `--no-commit`: stage without committing

git cherry-pick -n a3f9c12

Git applies the changes to the staging area but doesn't create a commit. Useful when you want to combine changes from multiple commits into a single one, or when you want to inspect what's about to happen before pulling the trigger:

git cherry-pick -n a3f9c12 d6c3b47
git status              # review staged changes
git commit -m "Apply payment fixes from feature branch"

`-e` / `--edit`: edit the message before committing

git cherry-pick -e a3f9c12

Opens your editor with the original commit message so you can modify it. Handy when the original said "fix" and you want something that actually describes what was fixed.

`-x`: record where the commit came from

git cherry-pick -x a3f9c12

Appends a line to the commit message pointing back to the original:

Fix null pointer in payment service

(cherry picked from commit a3f9c12b3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8)

Free traceability. Six months from now, when someone's auditing release/1.x and wondering why a commit clearly born on a feature branch is sitting there, the message explains itself. In projects with multiple maintainers or multiple active release branches, -x is effectively mandatory. Use it.

Handling conflicts

Cherry-pick isn't always painless. If the changes you're bringing in touch the same lines that have changed in the target branch since the original commit was made, you'll get a conflict. Here's where things get fun (and by "fun" I mean mildly annoying, but entirely manageable).

When Git hits a conflict mid-cherry-pick, it stops and tells you:

error: could not apply a3f9c12... Fix null pointer in payment service
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

The resolution flow is the same as merge or rebase conflicts:

# 1. Open the conflicting files, resolve manually
# (look for <<<<<<< / ======= / >>>>>>> markers and choose what stays)

# 2. Mark the conflict as resolved
git add src/services/payment.ts

# 3. Continue
git cherry-pick --continue

If the commit you're trying to apply already exists in the target branch (maybe it was merged in earlier), Git might try to apply an empty diff. In that case:

git cherry-pick --skip   # skip this commit and continue with the rest

And if you want to back out entirely and pretend this never happened:

git cherry-pick --abort  # back to square one, no harm done

Don't stress about conflicts — they're unavoidable when you're moving code between branches with diverged histories. Resolve them carefully, verify the result compiles and passes tests, then carry on.

Real-world scenarios

Backporting a hotfix to release branches

You maintain v1.x and v2.x in production. A security vulnerability surfaces and you fix it on main. Both versions need the patch, but you absolutely don't want to push all of main into either release branch:

# Fix is on main as commit f4e3d2c
git switch release/1.x
git cherry-pick -x f4e3d2c

git switch release/2.x
git cherry-pick -x f4e3d2c

The -x flag leaves a paper trail in both branches. This is backporting — carrying fixes backward in time without merging entire version lines. Cherry-pick is the standard tool for it, and it handles this use case extremely well.

Rescuing commits from a dead branch

You've been on a refactoring branch for weeks. The scope ballooned, priorities shifted, and the branch isn't going anywhere. But it has two commits — utility functions, an HTTP client abstraction — that you genuinely want to keep. Those commits deserve better than dying with the branch.

git log feature/big-refactor --oneline | head -20

7a9b1c2 Add generic retry helper
8b0c2d3 Extract HTTP client abstraction
c1d3e4f Refactor entire codebase (never mind)
...

git switch main
git cherry-pick 7a9b1c2 8b0c2d3

The branch closes. The useful work survives. Everything else disappears without drama. If you're like me when I started, you probably assumed losing a branch meant losing everything in it — cherry-pick makes it easy to be selective about what's worth saving.

When NOT to use cherry-pick

Cherry-pick is sharp, precise, and genuinely useful — which makes it tempting to reach for it in situations where it's the wrong tool. Using it wrong leaves you with a duplicate-commit-infested history, perpetual conflicts, and teammates giving you looks in standup.

Don't use cherry-pick when you need a full merge or rebase.

If a feature branch is done and ready to integrate, use git merge or git rebase. Cherry-picking commit by commit is slow, error-prone, and destroys the natural traceability of your history:

# ❌ Pulling in an entire feature one commit at a time
git cherry-pick a1b2c3d e2f3a4b f3a4b5c g4b5c6d h5c6d7e

# ✅ Integrating the feature properly
git merge feature/my-feature
# or
git rebase feature/my-feature

Don't use cherry-pick as a branch synchronization strategy. If you find yourself cherry-picking the same commits across three different branches on a regular basis, you don't have a Git problem — you have a branching strategy problem. That's a different conversation.

The duplicate hash problem. When you cherry-pick a commit, Git creates a new commit with the same content but a different hash. If you later merge the original branch, Git sees those changes as new and tries to apply them again — leading to conflicts or outright duplicates. The longer those branches coexist, the worse this gets. The rule is simple: use cherry-pick for specific, one-off situations (hotfixes, rescues, backports). Don't make it your routine synchronization mechanism.

Cherry-pick is the scalpel of Git: precise, effective, and the wrong choice when what you actually need is a shovel. For hotfixes, backports, and rescuing useful work from abandoned branches, nothing beats it. For integrating complete features, merge and rebase do the job with far less collateral damage.

In the next tutorial we'll look at git reflog — Git's internal diary that records every movement of every reference, including ones you've deleted. If you've ever reset --hard to the wrong commit, deleted a branch by accident, or stared at an empty working tree wondering what you just did, reflog is your safety net. We'll cover how to read it, how to navigate it, and how to recover work that feels permanently gone.

Never stop coding!

Interactive Rebase in Git: Edit Your History Like a Pro

Javi Palacios — Sat, 11 Jul 2026 22:15:23 +0000

You've been working on a feature for two days. Twelve commits. One says "fix", another "more fixes", one says "ok now it works", and three in a row say "wip". When you open the pull request, your history looks like a novelist's rough draft, not the work of a professional.

You can clean that up before anyone sees it.

git rebase -i — interactive rebase — gives you full control over your commits: you can reorder them, combine them, rename them, split them, or delete them entirely. All before they land in the shared history. It's like having editorial rights before publishing.

What is interactive rebase?

Interactive rebase is git rebase with the -i flag (for interactive). Instead of replaying commits automatically, Git opens an editor with a list of your commits and lets you decide what to do with each one.

The most common invocation:

git rebase -i HEAD~n

Where n is how many commits back you want to review. To edit the last five:

git rebase -i HEAD~5

Git will open your configured editor (vim, nano, VS Code, whatever you have) with something like this:

pick a1b2c3d Add login form
pick b2c3d4e Add password validation
pick c3d4e5f fix
pick d4e5f6a wip
pick e5f6a7b ok now it works
pick f6a7b8c Add remember me option
pick g7b8c9d fix typo
pick h8c9d0e tests
pick i9d0e1f more fixes
pick j0e1f2a final wip
pick k1f2a3b Add logout button

# Rebase 9f8e7d6..k1f2a3b onto 9f8e7d6 (11 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, and meld into previous commit
# f, fixup <commit> = like "squash" but keep only the previous commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# ...

The list shows commits oldest to newest — the opposite of git log. This trips everyone up the first few times. Yes, it's counterintuitive. No, there's nothing you can do about it.

The main operations

Each line starts with an action (defaulting to pick) followed by the hash and commit message. You change the action in the editor, save, close, and Git does the work.

pick: keep as-is

pick a1b2c3d Add login form

Leave it alone. The commit stays exactly as it is. The default action.

reword: change only the message

reword c3d4e5f fix

Git applies the commit but pauses to let you edit the message. The content doesn't change, only the text. Perfect for those "fix" or "wip" messages that scream "I had no idea what I was doing" in production history.

squash: combine with the previous commit

pick a1b2c3d Add login form
squash b2c3d4e Add password validation

Git combines b2c3d4e into a1b2c3d and opens an editor for you to write the final commit message. You can keep both messages, discard one, or write a new one from scratch.

fixup: combine and discard the message

pick a1b2c3d Add login form
fixup c3d4e5f fix
fixup d4e5f6a wip

Like squash, but automatically discards the absorbed commit's message. It disappears without a trace, no editor, no questions asked. It's the mode for: "I want this change to exist, but I don't want anyone to know it took me three attempts."

drop: delete the commit

drop d4e5f6a wip

The commit and all its changes vanish. Use with care — the code it contains is gone. If in doubt, use squash or fixup instead.

edit: stop to amend

edit b2c3d4e Add password validation

Git applies the commit and pauses so you can modify it: add forgotten files, change code, or even split it into multiple commits. When you're done:

git rebase --continue

A complete example

Start with this disaster:

pick a1b2c3d Add login form
pick b2c3d4e fix
pick c3d4e5f wip
pick d4e5f6a Add password validation
pick e5f6a7b fix typo
pick f6a7b8c Add remember me option

What we want:

Combine b2c3d4e (fix) into a1b2c3d (login form)
Combine c3d4e5f (wip) into the login form as well
Give e5f6a7b (fix typo) a proper message
Leave the rest alone

Edit the file:

pick a1b2c3d Add login form
fixup b2c3d4e fix
fixup c3d4e5f wip
pick d4e5f6a Add password validation
reword e5f6a7b fix typo
pick f6a7b8c Add remember me option

Save and close. Git:

Applies a1b2c3d
Silently absorbs b2c3d4e and c3d4e5f
Applies d4e5f6a
Applies e5f6a7b and opens the editor — you write "Fix email validation regex"
Applies f6a7b8c

Result:

* f6a7b8c Add remember me option
* e5f6a7b Fix email validation regex
* d4e5f6a Add password validation
* a1b2c3d Add login form

Four clean commits where there were six. The history now tells what you did, not how many tries it took.

Reordering commits

Interactive rebase also lets you change the order. Just move the lines in the editor:

# Original
pick a1b2c3d Add login form
pick d4e5f6a Add password validation
pick f6a7b8c Add remember me option

# Reordered: password validation before the form
pick d4e5f6a Add password validation
pick a1b2c3d Add login form
pick f6a7b8c Add remember me option

Keep in mind that if commits depend on each other (the second one modifies a file the first one creates), reordering them can cause conflicts. Git will let you know if that happens.

Splitting a commit into multiple

Sometimes the opposite problem: a monolithic commit that mixes too many things. The edit mode lets you break it apart:

git rebase -i HEAD~3
# Mark the commit you want to split as: edit

When Git stops at that commit:

# Undo the commit but keep the changes in the working directory
git reset HEAD^

# Now commit in logical chunks
git add src/auth/login.ts
git commit -m "Add login form component"

git add src/auth/validation.ts
git commit -m "Add email and password validation"

# Continue the rebase
git rebase --continue

Where there was one "Add auth stuff" commit, there are now two specific, focused commits.

Autosquash: automating the cleanup

If you already know a commit is going to be a fix for a previous one, you can create it with a special format from the start:

# Create a commit that will be auto-squashed onto abc123
git commit --fixup abc123

# Or onto the last commit
git commit --fixup HEAD

This creates a commit with the message fixup! Add login form. When you later run interactive rebase with --autosquash:

git rebase -i --autosquash HEAD~5

Git automatically moves the fixup! commits next to their target and assigns them the fixup action. You just confirm the order and close the editor.

It's the most efficient workflow if you have the discipline to use it from the start.

When to use interactive rebase

Interactive rebase is your pre-PR tool. The question to ask yourself: does this history help anyone who comes after me?

Do you have "wip", "fix", "temp", "asdf" commits? → fixup or squash
Are your commit messages vague or misleading? → reword
Does one commit mix unrelated things? → edit + reset + re-commit in pieces
Are commits in the wrong logical order? → reorder the lines

What you don't want to do is use interactive rebase on commits you've already pushed to a shared branch. The golden rule of rebase applies here the same as anywhere: branches that are only yours, yes; branches others have cloned, never.

Interactive rebase is one of those tools that feels intimidating at first — you open the editor, see a list of cryptic commands, and think "I'm going to break something here." But with a bit of practice it becomes a habit. A clean history isn't vanity: it's documentation. It's the context someone is going to need six months from now to understand why the code is the way it is.

In the next lesson we'll look at cherry-pick: how to take a specific commit from any branch and apply it to another without merging everything. It's the perfect tool for when you have a critical fix buried in a feature branch and need to get it to production now.

Never stop coding!

AI for Programming: The Paradigm Shift

Javi Palacios — Sat, 11 Jul 2026 12:47:02 +0000

Picture this: it's 2019. You're a mid-level developer. You spend your mornings writing boilerplate, your afternoons debugging stack traces, and your evenings on Stack Overflow trying to remember the exact syntax for a thing you've done a dozen times before. That was the job. Nobody thought it was weird — it was just how programming worked.

Now it's 2026. The boilerplate is gone in thirty seconds. Stack traces get explained in plain English. That CRUD endpoint you used to spend a morning on? Twenty minutes with good context and a decent prompt. The job hasn't disappeared — it's been compressed. And that compression creates a gap between people who adapted and people who are still typing like it's 2019.

This tutorial is about that gap. Not the tools — we'll get to those. The mental model. Because without the right mental model, even the best tools become a crutch instead of a multiplier.

The old way vs the new way

Let's be concrete about what changed, because "AI changes everything" is meaningless without examples.

The 2019 workflow, if you were building a REST endpoint:

1. Recall the framework syntax (or search for it)
2. Type the boilerplate — route definition, middleware, validation
3. Write the business logic
4. Write the error handling
5. Write the tests (if you wrote tests)
6. Document it (if you documented)
7. Realize you missed an edge case, loop back to 3

The 2026 workflow:

1. Describe the intent clearly to the AI
2. Review what it generates — actually understand it
3. Test it against your real requirements
4. Adjust and verify

The bottleneck shifted. Before, it was typing and recall. Now it's clarity of specification. If you can't explain what you want precisely enough for another intelligent entity to implement it, the AI won't save you — it'll generate something plausible-looking that solves the wrong problem.

That's not a limitation of the AI. That's the job now.

You're becoming an engineering director

Here's the analogy that makes this click for most people.

Imagine you've just been promoted. You used to write code all day. Now you have a team of developers — smart, fast, eager to help — and your job is to direct them effectively. You still need to understand the code deeply: you review it, you spot problems, you make architectural decisions. But you're not the one typing every line.

Working with AI is exactly that dynamic. The AI is the developer. You're the director.

Engineering director without AI:
→ "Why is the auth failing?" → looks through logs → reads code → finds the bug → fixes it

Engineering director with AI:
→ "Why is the auth failing?" → shows logs + relevant code to AI → AI explains root cause → director evaluates → directs the fix

What doesn't change: you still need to understand what the bug is. You still need to evaluate whether the fix makes sense. You still own the decision. The AI accelerates the mechanical parts — reading through 300 lines to find the one that matters, generating the corrected version, suggesting where to add a test.

What changes: the ratio of time spent thinking versus time spent typing shifts dramatically in favor of thinking. And thinking clearly about problems turns out to be the part nobody automated.

The new bottleneck: specification

There's a concept in software engineering called Garbage In, Garbage Out. It was coined for databases, but it describes AI interaction perfectly.

An AI is not a mind reader. It doesn't know your codebase, your team's conventions, your performance requirements, or that you have a legacy service that uses a slightly non-standard error format. It only knows what you put in the context window.

The quality of the output is bounded by the quality of the input. Always.

Watch how different these prompts are:

❌ Weak specification:
"Write a function to validate email addresses."

✅ Strong specification:
"Write a TypeScript function that validates email addresses. It should:
- Return a boolean
- Follow RFC 5322 (standard format, no exotic edge cases)
- Reject addresses over 254 characters (per spec)
- Reject addresses with consecutive dots in the local part
- NOT use external libraries — just regex and length check

We're on Node.js 22, TypeScript 5.4 strict mode.
The function will be called thousands of times per second in a hot path,
so avoid any allocations we don't need."

The first prompt gets you a function. The second gets you the function you actually need. The difference isn't the AI's capability — it's your ability to say what you want.

This is the skill that compounds. The developer who can write the second prompt consistently will extract ten times more value from AI than someone who writes the first one, regardless of which model they use.

Delegation without abdication

Here's where a lot of developers stumble: they treat AI as either a magic oracle they trust blindly, or a toy they use for trivial things and never for anything real. Both are wrong.

The right mental model is delegation with ownership.

When you delegate to a colleague, you don't stop being responsible for the outcome. You describe what you need, you check the work, you integrate it, you own it. Delegating doesn't mean disappearing from the loop.

Same with AI. The rule that matters:

Never merge AI code you don't understand.

Not "review it quickly." Not "it looks right." Understand it. If you can't explain in plain English what a piece of code does and why it's correct, you haven't reviewed it — you've rubber-stamped it. And when it breaks in production at 3 AM, "the AI wrote it" is not a defense.

This is especially important for developers early in their career. The paradox is brutal: AI helps the most with the mechanical parts of coding, which is exactly the part that builds foundational understanding when you're learning. If you skip the understanding because "the AI already did it," you build speed without foundations. That works until it doesn't, and when it stops working, it stops working hard.

What's worth delegating (and what isn't)

Not all tasks are equal. Here's the practical breakdown after two years of industry data:

High-value delegation

Boilerplate and scaffolding: This is the clearest win. Setting up a new service, creating data transfer objects, writing CRUD endpoints, configuring test infrastructure — tasks that are repetitive and well-defined. AI does these well because there's a massive amount of training data showing exactly how they should look.

Explaining unfamiliar code: You join a new project. There's a 200-line function with no comments, written two years ago, by someone who left the company. Give it to the AI: "explain what this function does, what it assumes about its inputs, and what could go wrong." You'll understand it in two minutes instead of twenty.

Writing tests: Counterintuitive for many people, but AI is genuinely good at this. Give it a function, ask for edge cases, ask for tests that cover those cases. The output quality is high because tests have structure — arrange, act, assert — and that structure is exactly the kind of pattern AI learns well. You still verify that the tests make sense, but the mechanical part of writing them is delegated.

Documentation: Explaining what code does in prose is exactly what a next-word prediction machine optimized on human writing should be good at. It is.

Debugging stack traces: "Here's the error, here's the relevant code, here's the context." This is the exact kind of "given all this information, predict what's wrong" task where large context windows shine.

Low-value or risky delegation

Security-critical code: Authentication logic, authorization checks, cryptographic operations, input sanitization against injection attacks. The AI knows the patterns, but the stakes of getting them wrong are severe enough that you need deep personal understanding of every line. Use AI as a starting point or reviewer, never as the sole author.

Complex algorithms: Sorting, graph traversal, optimization problems — AI can produce code that looks correct and has subtle off-by-one errors. Correctness here requires proof, not confidence. Always verify independently.

Domain-specific business logic: AI doesn't know that in your company, "active" users are those who logged in within 90 days, or that your pricing model has seven edge cases inherited from a 2017 migration. It will make assumptions. Some will be right. You need to catch the ones that aren't.

Novel architecture decisions: Should this be synchronous or async? One service or two? Event-driven or request-response? These decisions require understanding your specific system's constraints — load, latency requirements, team size, operational complexity. AI gives you options and trade-offs, which is valuable input. But it can't make the decision for you, because it doesn't know what you're optimizing for.

The verification mindset

Let's talk about the daily habit that separates effective AI users from dangerous ones.

Every piece of AI-generated code goes through the same checklist before it enters your codebase:

1. Run it — does it actually execute without errors?
2. Test it — does it handle the edge cases you care about?
3. Read it — do you understand every line? Could you rewrite it from scratch?
4. Question it — are there assumptions that might not hold?
5. Own it — can you defend this code in a code review?

Step 3 is where most people skip. "It works" and "I understand why it works" are different statements. Both matter. The first gets it past testing. The second gets it past production incidents.

The habit sounds slow. In practice, it takes maybe two minutes for a typical function. And it saves you the debugging session that takes three hours, the production fix that wakes you up at 2 AM, and the six-month accumulation of code you're afraid to touch because nobody knows how it works.

A note on junior developers

I want to be direct about something the hype glosses over.

If you're early in your career, AI is both your biggest advantage and your biggest risk. The advantage: you can produce at a level above your experience, which opens doors that used to take years to open. The risk: you can ship code you don't understand, build a track record on borrowed foundations, and hit a wall when you need to debug something deep.

The differentiator is the understanding habit. Use AI to go faster — absolutely. But make sure "faster" means "less time on the mechanical parts" and not "less time understanding." Your 10-years-from-now self will have the foundations or won't. The choice happens now, in how you use the tool.

You now have the mental model. You know why specification matters, what's worth delegating, and how verification fits into the workflow. In the next tutorial, we get concrete about a specific failure mode: AI hallucinations — how to detect them, when to trust AI, and the practical toolkit for not getting burned. Because knowing the theory of verification is one thing. Knowing what hallucinations look like in the wild is another.

Never stop coding!

How LLMs Work (Without the Math)

Javi Palacios — Fri, 10 Jul 2026 12:13:08 +0000

In the previous tutorial, we said LLMs "predict text." And you probably thought: "okay, but that doesn't actually tell me anything useful." Fair. We need to go one level deeper — not down to the math level, but to the level of what's actually happening, because that directly explains why AI sometimes invents functions that don't exist, why the same prompt can give different answers, and why giving it more context makes a massive difference.

This tutorial is arguably the most important one in this module. Not because of what you'll learn to do, but because of the mental model you'll build. And that mental model, I promise, will save you hours of frustration.

The next-word prediction machine

Here's the uncomfortable truth: an LLM doesn't "understand" anything. It has no opinions of its own, no lived experience, no intuition. What it has is something stranger and, in a way, more impressive: it's read absurd quantities of text and learned, statistically, what words tend to follow other words.

The task during training was brutal in its simplicity:

Training text:  "The cat sat on the..."
Objective:       Predict "roof"

Multiply that by trillions of examples, over weeks, across thousands of GPUs. The result is a model that, given any fragment of text, can predict with surprising accuracy what comes next.

And here's the magic nobody expected: predicting the next word well requires understanding an enormous amount about the world. To predict that after "The president signed the..." comes something related to legislation or agreements, the model has to have learned what a president is, what they do, in what contexts they act. Not as an abstract concept — as a statistical pattern extracted from millions of texts.

Is that "understanding"? Philosophers have been arguing about it for years. For us as developers, the practical answer is: it doesn't matter. What matters is that the emergent behavior is useful, and knowing its origin makes us use it better.

The intern who has read all of Stack Overflow

The most useful analogy I know for an LLM is this:

Imagine an extraordinarily well-read intern. They've read the complete documentation for Python, Node.js, Rust, and 50 other languages. They've processed millions of Stack Overflow posts. They've seen tens of thousands of GitHub repositories. They've read technical articles, blog posts, programming books. All of that is in there, compressed somehow.

But there are things that intern simply cannot do:

What they can do:
✅ Synthesize information from multiple sources quickly
✅ Write coherent, structured code
✅ Explain concepts at different levels of detail
✅ Generate tests, docs, and boilerplate at high speed
✅ Recognize patterns and suggest improvements

What they can't do:
❌ Look up new information (unless given tools to do so)
❌ Remember what you talked about yesterday
❌ Know with certainty whether what they're saying is correct
❌ Access your codebase (unless you show it to them)
❌ Know anything that happened after their training cutoff

That last point — the training cutoff — matters. The model doesn't know what happened after they closed the data tap. If a library's API changed six months ago, the LLM might give you the old syntax with total confidence. It's not lying: it genuinely doesn't know.

Why AI says nonsense with absolute confidence

This is what's called hallucination, and understanding why it happens is fundamental to not falling into the trap.

The model generates text by predicting the next word. At no point does it have access to a mechanism that says "wait, is this actually true?" There's no query to a facts database. No verification module. There's statistical prediction, and that's it.

So when you ask about a Python function that doesn't exist:

# Prompt: "How do I use python.utils.magic_sort()?"
# AI response:
import python.utils

result = python.utils.magic_sort(my_list, reverse=True, stable=True)
# The stable parameter ensures equal elements maintain their relative order

The AI didn't look up magic_sort anywhere. It generated text that sounds like the correct answer to that question, based on how answers about Python functions tend to look. The name, the parameters, the explanation — all of it has the right shape. It just doesn't exist.

This isn't a bug they're going to fix. It's a direct consequence of how these models work. That's why verification isn't optional — it's part of the workflow.

Warning signs you should learn to recognize

Over time, you develop a nose for this. In the meantime, here are the most common signals:

Overly confident response about a very specific or poorly-documented topic
Function names that "sound right" but that you don't recognize
Specific library versions or release dates with no source
Code that has the right shape but throws AttributeError or ModuleNotFoundError when you run it
Explanations that shift when you repeat the question with slight variations

The golden rule: treat AI output like code from a colleague who's very smart but works in a rush. Review before you trust, always.

Context is your superpower

Here's the variable you control the most and that makes the biggest difference: the context you give the model.

The LLM has no memory between sessions (unless you explicitly provide it). Every conversation starts from zero. The only thing it knows about you, your project, and your problem is what's inside the current context window.

The context window is the amount of text the model can "see" at once. Claude Sonnet, for example, has a 200,000-token window — enough for a medium-sized complete codebase. This is enormous and relatively recent: two years ago, windows were 8,000 tokens and you had to manually manage what to include.

What does this mean for you in practice?

❌ Weak prompt:
"My code doesn't work, help me"

✅ Context-rich prompt:
"I have this Python function that should parse dates in ISO 8601 format,
but it fails when the string includes a timezone offset (e.g., 2026-03-07T10:30:00+01:00).
Here's the code: [code]
And here's the error: [error]
I'm using Python 3.12 with dateutil 2.9.0"

The difference in response quality is enormous. Not because the model got smarter — but because it has the information it needs to predict relevant answers.

Temperature: why the same question gives different answers

If you've ever asked the same thing twice and gotten different answers, that's not a bug. It's by design.

When the model predicts the next word, it doesn't always pick the most probable one. There's a parameter called temperature that controls how much randomness gets injected into that choice. With high temperature (more creative), it might pick less probable words. With low temperature (more deterministic), it almost always picks the most probable one.

Temperature 0.0  → very deterministic, consistent responses
Temperature 0.5  → balance between creativity and consistency
Temperature 1.0  → more variation, more creative, more erratic

For code, you generally want low temperature: you want the model to give you the most probable solution, not to experiment. For brainstorming or idea generation, a bit more temperature helps break out of familiar patterns.

opencode manages this automatically based on task type, but it's good to know the concept exists — especially when you notice the AI being "more conservative" or "more creative" depending on context.

Newer doesn't always mean better (for you)

One last expectation-breaker: just because a new model came out doesn't mean you should immediately switch to it for everything.

Models are optimized for different objectives. A very new model might be better at mathematical reasoning but worse at following complex instructions. Or it might have a smaller context window. Or it might be significantly slower or more expensive.

Model choice should be pragmatic:

Task	Priority
Full codebase analysis	Large context window
Repetitive code generation	Speed and cost
Architecture design	Reasoning capability
Quick, simple answers	Any lightweight model

opencode lets you specify the model per session. In practice, Claude Sonnet is an excellent starting point for most development tasks — a good balance of quality, speed, and cost. We'll go deeper on this when we look at the model landscape in tutorial 5.

With this mental model in place, you can start working with AI more intelligently: you know why verification matters, you know why context is everything, and you know that hallucinations aren't dark magic — they're statistical prediction applied confidently. In the next tutorial, we go to the next level: the paradigm shift of going from writing code to directing an AI — and why the ability to specify clearly becomes the most valuable skill you can develop.

Never stop coding!

Normal Mode: The Power of Vim

Javi Palacios — Thu, 09 Jul 2026 10:45:57 +0000

Every new Vim user makes the same mistake: they treat Normal mode as an inconvenience — that awkward state you have to pass through to get to Insert mode, where the "real work" happens. They tap i, type a word, tap Esc, tap i again, type another word. Normal mode is just the lobby.

Here's the thing: Normal mode is not the lobby. It's the whole building.

In VS Code or Sublime, you spend 80% of your time navigating: moving the cursor, selecting text, deleting words, jumping between lines. The keyboard handles maybe 20% of that; the mouse handles the rest. Vim flips this completely. Normal mode gives you a vocabulary of precise, composable movements and operations — and once you're fluent, you'll navigate and edit without ever lifting your hands from the keyboard.

This tutorial is where Vim starts to click.

Moving faster than one character at a time

hjkl got you into the game. Now it's time to actually play.

Word movements

Instead of pressing l seventeen times to get to the word you want, Vim lets you jump by word:

w — jump to the start of the next word
b — jump back to the start of the previous word
e — jump to the end of the current (or next) word

These three form a triangle. w and b are opposites; e gets you to the last character of a word. In practice you'll use w and b constantly, and e when you need to land precisely on the final character.

The quick brown fox jumps over the lazy dog
^   ^     ^     ^   ^     ^    ^   ^    ^
                              w movements (one per press)

There's also the uppercase variants: W, B, E. These do the same thing, but they define "word" differently — they skip over punctuation and treat user_name, foo.bar, and http://example.com as single words. The lowercase w would stop at every underscore and dot.

" Cursor on 'u' in user_name
w    " → stops at '_' (between user and name)
W    " → skips to next whitespace-separated chunk

Rule of thumb: use lowercase when you care about punctuation boundaries, uppercase when you want to jump over the whole "thing."

Line movements

Getting around within a line:

0 — go to the absolute start of the line (column 1)
^ — go to the first non-blank character (ignores indentation)
$ — go to the end of the line
g_ — go to the last non-blank character (ignores trailing spaces)

You'll use ^ and $ far more than 0 and g_. Code has indentation; ^ puts you at the actual first character of the code, not at column 1.

File movements

gg — jump to the first line of the file
G — jump to the last line of the file
5G or :5 — jump to line 5 (replace 5 with any number)
Ctrl+d — scroll half a page down (d for down)
Ctrl+u — scroll half a page up (u for up)
Ctrl+f — full page forward
Ctrl+b — full page back

The Ctrl+d / Ctrl+u pair deserves a special mention. Once these are in your muscle memory, you'll browse through files at a completely different speed. Down, down, down, up — no more dragging a scrollbar with the mouse.

The Vim grammar: operator + motion

This is the part where it all clicks. Stay with me.

Every command in Vim follows a simple grammar:

[count] operator motion

count (optional): how many times to apply
operator: what to do (d for delete, c for change, y for yank/copy)
motion: where to do it (w for word, $ for end of line, j for down)

You already know several motions: w, b, e, $, 0, G. The moment you learn even one operator, you can combine it with every motion you know.

The operators

Operator	What it does
`d`	Delete (and put in clipboard — it's actually "cut")
`c`	Change (delete and immediately enter Insert mode)
`y`	Yank (copy to clipboard without deleting)
`p`	Put (paste — after cursor by default)
`P`	Put before the cursor

Combining them

dw    " delete from cursor to start of next word
db    " delete from cursor back to start of current word
d$    " delete from cursor to end of line
d0    " delete from cursor to start of line
dG    " delete from cursor to end of file
d5j   " delete current line + 5 lines below (6 total)

cw    " change word (delete word, enter Insert mode)
c$    " change to end of line
c^    " change from start of code to cursor

yw    " yank (copy) one word
y$    " yank to end of line
yy    " yank entire line (special case — doubled operator = full line)

That last one is worth dwelling on: doubling an operator applies it to the whole line. dd deletes the current line. yy yanks it. cc changes it. You'll use dd and yy constantly.

A concrete example

Say you're editing this Python function and want to rename calculate_total:

def calculate_total(items):
    return sum(item.price for item in items)

Position your cursor on the c of calculate_total. Now:

cw    " deletes 'calculate_total' and drops you into Insert mode

Type compute_sum, press Esc. Done. Two keystrokes to delete the word, type the replacement, exit Insert mode.

Without Vim: click at the start of the word, click-drag to the end, type the replacement. Five gestures, two of which require the mouse.

The dot command: the most powerful key in Vim

Once you've made a change, you can repeat it instantly: press . (dot).

The . command replays the last change you made — whatever it was. Added async before a function? Press . to add it to the next one. Deleted a line with dd? Press . to delete the next line. Changed a word with cw? Press . to change the next word the same way.

cw    " change current word, type 'newName', press Esc
w     " move to next occurrence
.     " repeat: change that word to 'newName' too
w
.     " and again

This is how Vim users do what looks like multiple-cursor editing without actually using multiple cursors. Find the pattern, make the change once, then . your way through the file.

Don't underestimate .. Experienced Vim users think about their edits in terms of "how do I make this change once, repeatably?"

Counts: do it N times

Any command can be prefixed with a number to repeat it:

3w      " move forward 3 words
5j      " move down 5 lines
3dd     " delete 3 lines
2p      " paste twice
10G     " go to line 10

Counts plus operators plus motions give you a genuinely expressive system. d3w means "delete 3 words." y5j means "yank current line plus 5 below." You're not memorizing a list of commands; you're speaking a language.

A few essential shortcuts

Some combinations appear so often they've earned their own single keys:

Shortcut	Equivalent	What it does
`D`	`d$`	Delete to end of line
`C`	`c$`	Change to end of line
`Y`	`yy`	Yank entire line
`x`	`dl`	Delete character under cursor
`s`	`cl`	Substitute character (delete + Insert mode)
`S`	`cc`	Substitute entire line

These aren't exceptions to the grammar — they're just common abbreviations. Learn them as shortcuts, not as separate rules.

Practical exercise

Open any code file you've been working on and spend five minutes on this:

Navigate to a function or method name using w and b only — no arrow keys
Use cw to rename it, type the new name, press Esc
Press gg to go to the top of the file
Press G to go to the bottom
Use 10G (or whatever line number makes sense) to jump somewhere in the middle
Delete three lines with 3dd
Paste them back with p
Find another word you want to delete and use dw
Press u to undo
Press . — notice what happens

If you feel slightly overwhelmed at this point, that's completely normal. For now, don't stress about memorizing every combination — focus on the grammar: operator + motion. Once that's in your head, the rest follows naturally.

Key concepts from this lesson

Word movements: w / b / e jump by word; W / B / E jump by WORD (ignoring punctuation)
Line movements: ^ → first non-blank, $ → end of line
File movements: gg → top, G → bottom, Ctrl+d / Ctrl+u → scroll
The grammar: [count] operator motion — d3w, c$, y5j
Operators: d (delete/cut), c (change), y (yank/copy), p (put/paste)
Doubled operators = whole line: dd, yy, cc
. repeats the last change — use it constantly
Counts multiply any command: 3dd, 5j, 2p

You now understand what makes Vim fundamentally different from every editor you've used before. It's not the number of shortcuts — it's the grammar. Operators combine with motions, counts scale them, and . repeats them. You're not memorizing; you're composing.

The next step is understanding the other side of the grammar: Insert mode in depth. There's more there than just "press i and type" — Vim has a set of powerful ways to enter and exit Insert mode that will make your edits more precise and your . repetitions more effective.

Never stop coding!

DEV Community: Javi Palacios

Docker port mapping: connect your containers to the outside world

Containers live in their own network bubble

Publishing ports with -p

Syntax variants

Multiple ports

Checking active port mappings

Inspecting the network with docker inspect

Multiple containers on the same host

What if containers need to talk to each other?

Finding bugs with git bisect

How binary search works here

Basic usage

Using references instead of hashes

Automating bisect with a script

Checking bisect progress

When bisect isn't the right tool

Recovering lost work with git reflog

What is the reflog

Viewing the reflog

Recovering commits lost after a reset

Restore the full state

Create a branch from that point (the cautious route)

Recovering a deleted branch

Recovering from a bad rebase

The ORIG_HEAD trick

Finding a commit by its content

Practical cases

"I dropped the wrong stash"

"I just force-pushed to main"

AI Limitations and How to Detect Hallucinations

Why AI lies with such conviction

The three types of AI error

Invented information

Outdated information

Context blindness

The warning signs to learn

The verification checklist

The "show me the documentation" tactic

How to compensate for context blindness

What the AI can never know

Insert Mode in depth: more than you think

Nine ways to enter Insert mode

The basics: where to land the cursor

The change variants: delete and enter

Inside Insert mode: it's not a dead zone

Deleting without leaving

The Ctrl+o trick

Native autocomplete

The golden rule of Insert mode

Arrow keys in Insert mode (and why not to use them)

Key concepts from this lesson

while loops in Python: repetition with a condition

What is a while loop?

The infinite loop: it's not a myth

break: exit on your terms

continue: skip one iteration

Real-world use cases

Validating user input

Counter with a business condition

Guessing game

while vs for: when to use each

Interactive containers and exec: get inside, run commands, get out

Interactive mode: what -it actually means

Detached mode: the -d you already know

docker exec: get inside a running container

Common exec patterns

exec without -it

The Alpine trap: bash vs sh

Copying files with docker cp

From container to host

From host to container

docker cp vs volumes

Seeing what's happening: logs and inspect

docker logs

docker inspect

A typical debugging workflow

Cherry-picking commits in Git

What is cherry-pick?

Basic usage

Publishing ports with `-p`

Inspecting the network with `docker inspect`

The `Ctrl+o` trick

Interactive mode: what `-it` actually means

Detached mode: the `-d` you already know

`docker exec`: get inside a running container

`exec` without `-it`

Copying files with `docker cp`

`docker cp` vs volumes

`docker logs`

`docker inspect`

`-n` / `--no-commit`: stage without committing

`-e` / `--edit`: edit the message before committing

`-x`: record where the commit came from